6 Tips on How to Write a Good Project Specification (with Examples)

You might be responsible for a new company’s project or work for your own startup. And you’ve found the best available dev team, who have expertise in your market and desirable technology stack. Most people in your position think that because they have expert developers, they don’t need to worry about preparing a good project specification document.
And it’s not their fault. In fact, our data shows that 9 out of every 10 small businesses and startups don’t know how to write the specification for a project. Often they don’t even know they need to prepare one, or they find some odd and complex project specification examples on the Internet and think “Oh, gosh, that’s not for me. I’ll figure this out; we’ll hire a strong dev team, and they will handle it!”. That’s the way to a low-quality product, delayed deadlines, extra expenses, and an overall shady experience.

On the other hand, if you have a solid project specification, it’s almost guaranteed that you can get a better price for your project from developers than you can without the specs. Why? The clearer the specs, the less risks for your developers during the development process, so they will not include an allowance for that in the estimate.

Yes, you can say that you want to be flexible and have a room for pivot. And you are totally right. But if you want to move quickly, and better understand your product and the problem it solves, you still need to have the spec in place to launch your first version of the product, or a Minimum Viable Product (MVP), really fast and with the highest possible quality and user experience.


To make it even more transparent for you, you should plan to launch your MVP within 4 to 12 weeks (unless the first version of your app or project is really complex). It’s a relatively short time, and once you have your product out there, you can test, experiment, be flexible and pivot in the right direction.

That’s why I decided to discuss this topic in more detail, and put this article together, including a project requirements specification template, so you can be in a better position than the average Joe.vv
You can download the specification template at the end of this article.

1. Specification document should be simple


Nobody needs to write a 20-page specification from scratch. You would spend days and weeks working on it. It’s not a philosophical document; it’s a very clear set of instructions about how your product will work. Use shorter steps and try to write your first version of project specification documentation in one, or max two hours. It should cover the following aspects:

  • Project description
  • List of all the pages/screens with all the features
  • User path
  • Design mockups or wireframes
  • Tech stack related info

The benefit of preparing the specification quickly is that you can share it with your colleagues and your dev team, get a lot of feedback and additional questions, so it will be much easier for you to write the next version, spending the same one to two hours. Usually, the second version of the specification is good enough to start the project, though you might want to go into more detail and iterate more.

Let’s go step by step and I’ll show you what should be in your project specification documentation.

2. Project description


This should be a simple text, around half a page, describing your product. It could be a mobile app, a website, a chatbot, or a complex integrated solution – but you still want to put it all together in half a page. It should describe your project and explain your project objectives. In addition, you can include:

  • Success criteria – how to know if your website or app is doing its job
  • Website/app maintenance if needed and who should do that
  • Project timeline and a deadline
  • Desirable budget

Here is an example we used for the first version of the DevTeamSpace dashboard:

DevTeamSpace dashboard is an automated project reporting dashboard. It notifies dev team’s project manager and developers to post 2-4 lines of text updates on the project progress on daily basis. Once the updates are posted and approved, the dashboard sends automated notifications to the client.

Left side of the dashboard contains the project name, description, client’s name, email, and phone number. Underneath, it displays the dev team and a project manager. Below that, clients can link their project documentation, demos, etc.

On the right side of the screen, we display the overall project progress in percentages, estimated completion date, roadblocks, notes, and daily updates.


DevTeamSpace project reporting dashboard doesn’t have a chat window, so it looks clean and is easy to skim though the daily updates. If the client wants to reply to a daily report, he/she can click the “reply” button under the update and communicate directly with the developers via email, slack or skype.

The dashboard will be deemed successful if we see a significant decrease in questions about progress from the client, and a significant decline in delays due to efficient roadblocks tracking and daily written updates.

As you can see, it’s just half a page, yet it provides enough information and details about the project from a user perspective.

3. List of all the pages/screens with all the features


This might sound complicated, but it’s really simple. You only need to create a tree list of all your pages/screens and features. Here is an example:

  1. Main page
    • Logo
    • Main menu
      1. About
      2. Services
      3. Clients
    • Sign in
    • Gest started
    • Main title of the page
    • Subtitle
    • Button “Get Started”
    • Logos of companies our dev teams have helped
  2. Sign Up Page
  3. Dashboard page

And so on, for every single page. It takes no time to write and creates a super clear structure for your product. If you struggle to create such a list, you probably don’t have a good understanding of your product. And there is no one better than you who should write it. So, if it’s hard for you to write, you should try to really focus on it and do your best. It will not only affect your project specification, but also your overall business understanding and product user experience.

4. User path


This is one of the most important parts of your specification. Here you explain how people use your product. You can make it in Word, PowerPoint, or even just draw it on paper and or flip board. Or you can use tools like iMindMap, Mindmaster, or DriChart. I have no affiliation with these products whatsoever, sharing only for your benefit. This is what the user path could look like:

Please don’t mix it with the user flow. User flow is a result. It shows you how your users go through your site, from page to page, and you can’t control it. It’s statistical information. You can find it in Google Analytics, for example.


The user path is something you design. You implement a certain structure, so people who use your product follow a certain path. It should also include:

  • User roles – what types of roles will your website/app users have (guest, editor, admin, etc.)
  • Feature requirements per user role.

Obviously, you can describe the user roles in a simple text format.
The cost of mistakes here is high. If you don’t plan this part of the specs well, you can end up with very disappointing results after the product is released.

5. Design mockups or wireframes


This part of the specification is the place for creativity. It can be simply structured, or (if you have a designer) you can spend days on it. We are focused on simplicity today, so I would highly recommend you build wireframes. You can draw them on paper, or use simple graphic software, but I highly recommend going with one of the professional tools. Most of them are super affordable and even allow you to build one prototype free of charge. Here are some of the most popular ones:

InVision,, Marvelapp, Pixate, Fluid UI

Keep in mind that if you want to build a custom design, completing this task is a must. On the other hand, if your project is small, you can use a template design. Here are some resources for that:
Design templates for mobile apps: AppDesignVault, CSSAuthor
Design templates for websites: TemplateMonster

6. Tech stack related information

This part is not a requirement, because you can get an advice from your dev team on the best tech stack for your project. But if you have a specific request for a tech stack, make sure to describe it fully. For example:

  • Frontend
    AngularJS, CSS, HTML
  • Backend
    Ruby on Rails, MySQL, AWS
  • Other
    Stripe API for payments


Congratulations on making it this far! The above information could be overkill for a smaller project, or you may want to add extra details for a larger project. Logically, the larger the project, the more important a detailed spec becomes. Overall, when you are drafting your project spec, account for as much of the above list as possible.