When a studio cannot see the edges of a project, it prices the uncertainty. That is not dishonesty, it is arithmetic: someone has to carry the risk of the thing nobody mentioned, and if it is not defined, it is carried by the number.

Which means a vague brief costs you money twice — once in padding, and again when the estimate turns out to be wrong anyway.

You can remove most of that with one page. Here is what belongs on it.

Six things worth writing down

Who the user is, specifically. Not "businesses". A dispatcher at a logistics company who works a night shift and needs three numbers on one screen. The more specific the person, the fewer wrong assumptions get priced in.

The one job it has to do. If the system did exactly one thing well, what would it be? Everything else is context. Studios that receive a list of forty features and no priority will assume all forty are equally important, and they will not be.

Constraints that are already fixed. Integrations you must support, a compliance regime you operate under, a launch date tied to something real, an existing database, a hosting provider your security team approved. These do more to shape an estimate than the feature list.

What success looks like as a number. Orders processed per hour, hours saved per week, calls avoided, conversion moved by a point. If nobody can name a number, that is worth knowing before the project starts, not after.

What you already have. Designs, a previous version, a spreadsheet the whole company depends on, an API somebody built two years ago. Existing assets can cut a project significantly — or, if they are in bad shape, add to it. Either way the estimate should reflect reality.

A budget range. Yes, really.

Why hiding the budget costs you money

The most common instinct is to withhold the budget so the price is not inflated to match. It usually backfires.

Without a range, a studio guesses at scope. Guess high, and you get a proposal you cannot afford and a wasted round of conversations. Guess low, and you get a stripped proposal that makes them look weak next to someone who guessed better.

Give a range, and the conversation changes into the useful one: here is what fits, here is what does not, and here is what we would do first. You are not revealing your maximum. You are telling them which problem to solve.

If a studio simply expands to fill whatever number you say, you have learned something valuable and cheaply.

What a good response looks like

You can judge a studio by the shape of its reply more reliably than by its portfolio.

  • Assumptions are listed. Every estimate rests on assumptions. Good ones are written down, so you can correct the wrong ones before they cost anything.
  • Risks are named. Especially the ones that belong to you: an integration partner who may not respond, a decision you have not made yet.
  • It is phased. A first release that produces something usable, then the rest. Anyone proposing a single delivery in nine months is asking you to accept all the risk at once.
  • Something has been cut. A studio that agrees to everything has not thought about it. The most useful sentence in a proposal is usually "we would not build this yet, and here is why".
  • The estimate is a range with reasons. A single exact figure for a project that has not started is a marketing number.

Red flags

A quote that arrives within an hour, with no questions asked. A price per screen. Enthusiastic agreement with every idea you floated. No mention of who owns the code and the accounts. No answer to "what happens after launch".

And the quietest one: nobody asked what happens if the project succeeds. Systems that work get used more than planned, and that has consequences worth discussing before, not after.

What we do with a brief

We read it, then we usually ask to cut it. The first conversation is normally about what to leave out of the first release, because that decision affects the budget more than any technology choice.

Then you get a range, the assumptions behind it, and a note on what would make it move in either direction. If we think an existing product would serve you better than a custom build, we say that too — it costs us a project and saves you a year.

If you have a project in mind, a page like the one above is enough to start. Send it over and we will tell you what we would build first.