If you ask 10 people what the perfect spec format is for software, you'll get 10 different answers. That's because specs need to adapt to the needs, skill-sets, and abilities of a team.

Instead of giving you a prescription, this article is intended to give the fundamentals to know and the mindset you should have when delivering specs, requirements, or designs to your developer(s). Examples are provided at the end of this article.


  • Keep it simple.
  • What you draw is what you get, and code costs 10x what design does.
  • Deliver things in a clear, development-friendly way.

Keep it simple:
Scrap the 30 page spec document. It will take someone far too long to understand what it is you want to build and what it is that's most important. If everything is important, nothing is important. 

The point of specs is to get what's in your head out and into the understandings of a developer (or team) as quickly and clearly as possible.

If you're starting to work on a new app, what is the most important thing the app needs to do? Is this explained clearly? What are the most important 2-3 things?

Explain the goals of your app in as few pages/words/visuals as possible. This will force you to get to what matters most, first. 

What you draw is what you get, and code costs 10x what design does:
As a rule of thumb, assume the time spent coding something will be at least 10x the time spent designing it. So, get things right and clear in the design phase of a project.

Design will not improve as you move it to Code. If you're working with a skilled developer, the coded result of an app should look exactly like your original designs, down to the pixel.

Turtle doesn't want customers to learn design mistakes in code (like text being too small or the wrong icons being used). Certain mistakes can only be discovered once you're clicking or tapping a real app, but many more mistakes can be fixed in the (much cheaper) design phase.

Deliver things in a clear, development-friendly way.
Designs should get delivered to developers through modern design software like Sketch, Figma, or Photoshop.

Keep in mind: developers may not have the same design software as your designer installed or licensed. Tools like Zeplin or Avocode let you upload designs in any format and share them in a way that's easy for developers to absorb.

If pixel-perfect design is not important for your current stage of development (i.e. you're building a rough prototype), you can use design frameworks like Material UI or Semantic UI. These are a great option for prototyping as someone else has taken the time to figure out what each pixel should look like and the visual code is already made available for developers. Using UI frameworks results in significant development cost reduction.


Turtle wants you to make things easy and clear for developers and so should you. Easy to follow specs and designs help companies make the most of their spend on Turtle and help make sure developers are happy with their work. If developers are happy, they stick around with Turtle. 

Follow the principles of Skateboarding, that is: instead of a laundry list of features, start with the most minimal solution to get your product's users from A to B, and then only iterate on it once a rough version is complete. You'll make better decisions as you make progress, as those decisions will be informed by real product use. Read more about Skateboarding (and how it can relate to budgeting) here.

Remember the 10x rule of software dev. If you spend 1 hour ideating/white-boarding something with cofounders, it will take a designer at least 10 hours to make those ideas into a development-ready screen, and it will take a developer at least 100 hours to turn that design into code. This is a rule of thumb, but we've found it incredibly accurate over and over again. Read more about the 10x rule of software dev here.

Clean designs of what you want to build, in pure design, clickable prototype, or video format, paired with a call, will go far further than what long, text based spec documents can achieve. These documents may be necessary for a fixed-price agency to work from, but if you're working with Turtlers or even your own developers, working on the most important thing at any given point in time is all that matters.

Here is an example of a clickable prototype, built using InvisionApp. Developers love being able to see and click around what they'll be building before they start. It helps them fully understand your product.

Here is an example of designs provided in .Sketch design format for a real Turtle project. The iPhone app of these designs was built in less than 100 hours, which is incredibly low for a usable product. This low cost was achieved because the designs were so clear.
please note: Invision clickable prototypes were also provided, and the designer + customer + devs spent time over a call to understand the goals of the app.

If you'd like to learn more about product management beyond the process of making specs/designs that are developer friendly, Turtle's remote PM course has been made available for all to view. Access it here: https://www.turtle.ai/rpm

Did this answer your question?