A Founder's Guide to Reading a Development Proposal

A complete proposal has the same core sections, whoever writes it. Use this table as a map while you read.

Good scope describes what a user can do, not just the names of screens. "Users can sign up with email or Google and reset their password" can be checked. "Authentication module" cannot.

Look for user roles, core flows and admin tools listed separately. Admin panels are easy to forget in a brief and expensive to add later.

For example, ProAnalizy turns medical test results into plain-language explanations. Its main flow can be written as an outcome: a visitor uploads a PDF, JPG or PNG of a lab result and gets an explanation, with no account step. A line like that tells both sides exactly what "done" means.

A clear proposal lists what is not included. Typical exclusions are copywriting, translations, app store submission, third-party subscription fees and hosting after launch.

If there is no exclusions section, ask for one. Everything you assumed was included and was not will come back later as a change request, when you have less room to negotiate.

Translations are a good example of work that hides in a vague line. CarPixly launched in English, German and Russian, and that meant interface strings, error messages, install steps and the FAQ, with buttons sized for longer German labels. A proposal that only says "multilingual" leaves all of that open to interpretation.

You do not need to be an engineer, but after reading the proposal you should be able to answer these questions:

• What will it be built with, and why that stack for your product specifically?
• Who owns the code and the accounts: repository, hosting, domain, app stores, analytics?
• Where will it be hosted, and roughly what will that cost each month after launch?
• Will the code be documented well enough for another developer to take over?
• How does the team handle common security risks, such as those in the OWASP Top 10?

A good agency explains its choices in plain language. "It is what we always use" is not a reason.

On ownership, ask for the repository to live in your organisation's account from day one. Moving it later is possible, as GitHub's guide to transferring a repository shows, but it depends on the other side's goodwill.

A single delivery date tells you very little. Look for milestones with something you can see at each one: approved designs, a working build on a test link, a launch-ready version.

Ask how often you will see progress. Weekly check-ins are a sensible baseline; a single demo at the very end is a risk. At Sakura, clients get builds they can click through every week, so problems surface while they are still cheap to fix.

Check that the timeline includes your own part too. Reviews, feedback rounds and content you need to provide take time, and a plan that ignores them will slip.

Comparing proposals right now? Send us your brief and you will get one written to this standard, so you can put it next to the others.

Check whether the proposal mentions testing, performance and accessibility, or only features. Look for specifics:

• Which browsers and devices are supported?
• What performance should the product reach? Google's Core Web Vitals are a common yardstick: content loads within 2.5 seconds, interactions respond within 200 milliseconds.
• Who tests the product before launch, and how are bugs reported and fixed?
• Is basic accessibility included, such as keyboard use and readable contrast?

If "done" is not defined, the last weeks of the project turn into a debate. A written definition turns them into a checklist.

Confirm exactly what the price covers and how payments are split. A deposit plus payments tied to milestones is standard; 100% up front is not.

Find the change process. It should explain how new requests are estimated and approved before anyone starts on them. Without it, every change becomes a negotiation.

Check the exit terms as well. A fair proposal lets you stop between milestones without paying for work that has not started. For a deeper look at the two main pricing models, see fixed price vs. hourly development.

Many proposals stop at launch day. Ask what happens next: is there a support period for bugs, how long does it last, and how is ongoing work priced?

A launch with no plan for fixes and updates is where a lot of products quietly stall. Every Sakura project includes a defined support window; after that, a monthly support plan covers updates, fixes and new features.

Some problems are visible on the page itself, before any call. Read the proposal once just looking for these:

• A total with no breakdown. You cannot tell what you are paying for, or what to cut if the budget is tight.
• Words that cannot be checked. "Modern", "scalable" and "user-friendly" describe nothing you can test at handover.
• A timeline with one date. Nothing you can see along the way means no early warning when things slip.
• No mention of who owns what. Silence on code and accounts usually means they stay with the agency.
• Everything included, nothing excluded. No real project is that simple, so the exclusions are simply unwritten.

One warning sign is a question to ask. Three or more usually mean the agency has not understood the project well enough to price it.

A proposal is a draft, not a final offer. Good agencies expect questions and update the document; the way they respond is part of your evaluation.

• Ask for a breakdown by phase or flow. It shows where the money goes and gives you options if the total is too high.
• Ask what they would cut first. A thoughtful answer shows they understand which parts of your product matter most.
• Ask to split the project. A first phase with design and a prototype can lower the risk of committing to the whole build at once.
• Ask to rewrite vague lines as outcomes. "Users can export a report as PDF" instead of "reporting module".

If an agency refuses to clarify anything in writing before you sign, it will be even harder to get clarity after.

Put the proposals in a simple table, one column each, and fill in the same rows: scope, exclusions, timeline, milestones, payment schedule, change process, ownership and support after launch.

Empty cells are the most useful result of this exercise. They show where one proposal is silent, and each silence is a question to ask before you compare prices.

Only then compare the totals. If one proposal is much cheaper, look for what it leaves out.

If one is much more expensive, ask what it includes that the others do not. Sometimes the difference is a support period or a design phase you actually need.

Bring these to your last call with the agency. Clear, specific answers mean you are ready to sign.

• What exactly is excluded from this price?
• Who will work on the project day to day?
• What happens if we need to change the scope?
• Who owns the code and every account at the end?
• What support is included after launch?

If you are still choosing between agencies, our guide on how to choose a development agency covers what to check before you even ask for proposals. And when you want a proposal you can hold to this standard, tell us about your project.