Before You Talk to a Developer, Write One Page

Why the first call goes sideways

A founder has an idea, a deadline and a list of features in their head. They send three developers a message that says "I want to build an app like X, but for Y". Three estimates come back, and they cannot be compared, because each developer filled the gaps with their own guesses.

The problem is not the developers. It is that the most important decisions were never written down, so every quote is answering a different question.

One page, written before the first conversation, fixes most of this. It does not need to be technical. It needs to be specific.

What goes on the page

Who it is for

Describe one kind of user, not everyone who might ever use the product. "Owners of small clinics who book appointments by phone" is a user. "Healthcare businesses" is a market.

The one problem it solves

Write the problem in the user's words, in one or two sentences. If it takes a paragraph, there are probably two products in it, and you should pick one to start with.

The first screens

List the few screens a user needs on day one to get from opening the product to the result they came for. Sketches on paper are fine. This is the part that turns a vague idea into something a developer can estimate.

What is out of scope

This is the line most briefs leave out, and it matters most. Write down what the first version will not do: admin dashboards, extra user roles, a second language, a mobile app as well as the web. Saying it early stops it from quietly growing the estimate.

What done looks like

How will you know the first version worked? It might be that a small group of users completes the main task without help, or that you can show it to investors. Whatever it is, write it down, because it decides what gets built first.

Your constraints

Note the things a developer cannot guess: a launch date that cannot move, an existing system it must connect to, where your users are, and any rules about where data must be stored.

What the page gives you

With the same page in front of every developer you speak to, the answers become comparable. You can see who asked good questions, who pushed back on scope, and who simply agreed to everything.

It also makes the first build smaller. A clear "out of scope" line is the cheapest way to keep a first version focused enough to test with real users.

And it saves time in every conversation that follows. Instead of re-explaining the idea, you spend the call on the decisions that actually need a developer's input.

A template you can copy

1. User: who is it for, specifically?

2. Problem: what problem does it solve, in their words?

3. First screens: which screens does the user need on day one?

4. Out of scope: what will the first version not do?

5. Done: how will you know the first version worked?

6. Constraints: dates, systems, locations and data rules.

When we receive a brief like this through our contact form, we reply within one business day with a free scope and estimate, with no obligation. If you have an idea and a page, [send it to us](/contact).