You need a written document that says what problem you are solving, who has it, what the first version does, what it deliberately does not do, and what you already know from talking to real people. Without it you are asking a developer to make your product decisions for you, and they will, because they have no other option.

I built that document for my own app idea before I built this company. When I finished it I thought: if founders had this when they went to an agency, or hired a designer, or hired an engineer, their lives would be so much better, and they would not waste as much money. That thought is why Up Coast exists.

What goes in the document

I call it a strategy package. The shape is simple, and none of it needs technical knowledge:

• Overview and goals. What this is and what it is for.
• The customer problems, with the evidence. What people actually told you, not what you assume.
• Who it is for, described by behaviour.
• What the first version does, feature by feature, at a level someone could build from.
• Out of scope, in writing. This one saves the most money.
• Open questions, the things you know you have not answered.

Leave out financial projections and user-growth predictions. They set false expectations and nobody can hold you to a number you invented.

That document also becomes the basis of a product requirements document, which is the version the engineering work is built from.

What a good developer does with it

They ask about your users and your problem before they ask about your features. Then they tell you where your plan is expensive, where it is unclear, and what they would do differently.

If someone quotes you a price and a date without asking a single question about the people who will use this, that is your answer about the fit.

Ask for sizes, not dates

Go through your feature list and ask them to size each item as small, medium, large or extra large. Say it plainly: I know you cannot be precise yet, because you need to get in and do the feasibility work, but give me an idea of how big each of these is.

Sizes are honest, dates are a promise nobody can keep, and sizes let you cut before you pay rather than after.

Write acceptance criteria for anything you care about

For each feature, write the checkboxes that mean it is done. Whoever tests the work, including you, should be able to walk through them one at a time. It is the cheapest way to avoid "that is not what I meant" at the end.

Sort out the boring things in writing

Who owns the code. Whether it is fixed scope or hourly. What happens when scope changes, and what a change costs. What handover includes: the repository, the accounts, the store listings, the credentials. Who can deploy. What happens if you stop working together.

These matter more than first-time founders expect, and they are much easier to agree before the work than during it.

What to expect of yourself

Understand what you are being given well enough to evaluate it. If someone hands you a plan, you should be able to read it and tell whether they stayed in the problem space or jumped to a solution, and whether they did research or just tried to prove their own assumptions.

Also, calibrate. The most common source of friction is that a change you think is 10 or 20 minutes is two days of doing it properly. Expectations get wildly out of proportion, and that is where the resentment on both sides comes from.

One thing not to do

Do not generate your requirements from an AI that never spoke to a user. I have watched a tool take an idea and print a confident product requirements document, and my reaction was: you are making this up, there is no research here. The document is only worth what the research behind it is worth.

Keep reading

What Happens When You Hire a Developer Without a Strategy

How Do I Protect My App Idea When Talking to Developers?

How Long Does It Take to Build an App, and Why Most Estimates Are Wrong

Learn this with me

From Passion to Product is my free six-week live course, and the thing you walk out with is the document this article describes. Class 7 is where your scope and priorities get written down and class 8 is where the technical decisions and the PRD do, which together are the state you want to be in before you pay anyone.

Six weeks, live, no coding needed.

If you are hiring because your team does not have these skills, I also teach them to teams directly, from a one day workshop up to the full six weeks.

Join the waitlist, get the workbook, or look at the team programs.