In this guide
The lowest number in an app proposal may cover the smallest scope. The largest number may include work you do not need yet. Before choosing, compare what each developer is committing to deliver, how it will be checked, and what you will need to manage after launch.
Send the same brief to each builder. When a proposal arrives, use the questions below to clarify differences. A missing detail is a question to resolve, not proof that a developer is unreliable.
Key takeaways
Compare the same user journey
Imagine you are commissioning a paid resource library.
Ask these questions for every proposal
Keep the answers alongside the proposal so you can compare them without relying on memory.
Make running costs visible
A fixed build fee does not mean the product has no running costs.
Understand the change process and timeline
Ask how a new requirement becomes a change request.
Compare the same user journey
Imagine you are commissioning a paid resource library. One quote includes a checkout and access to files. Another also includes password recovery, failed-payment handling, a way to update resources, and an administrator who can help a member with access. Those are different commitments even if both say ‘membership app’.
Write out the main journey and mark whether each proposal includes every necessary step. Ask about failure cases as well as successful ones. Confirm which parts you will manage manually at first and whether that is acceptable for your initial audience.
Ask these questions for every proposal
Keep the answers alongside the proposal so you can compare them without relying on memory.
- Scope: Which customer and admin workflows are included, and what is explicitly excluded?
- Design: Which screens will I review, when will I review them, and how are revisions handled?
- Testing: Which devices and core journeys will be checked, and what counts as accepted work?
- Release: Does delivery mean a working preview, a live web product, or an iOS submission?
- Ownership: Which repository, domain, hosting, and service accounts will I control?
- Costs: What is the project fee, what can change it, and which recurring services will I pay for?
- Support: What is covered after launch, for how long, and how are new features quoted?
Make running costs visible
A fixed build fee does not mean the product has no running costs. Ask for the services the proposed product uses and who pays each provider. Request links to current plans, the usage assumptions behind estimates, and any limits worth monitoring.
For example, a file-heavy resource library and a text-only client portal may have different storage needs. An AI feature may introduce usage costs that grow with requests. You do not need a perfect forecast, but you do need to know which assumptions could change your bill.
Understand the change process and timeline
Ask how a new requirement becomes a change request. A useful process explains the extra work, its effect on price and timing, and how you approve it before development continues. Put decisions in writing so neither side relies on a different recollection of a call.
Separate build time from dependencies. Content preparation, account access, feedback, and external reviews may affect release. For an iPhone app, clarify whether the milestone is a TestFlight build, an App Store submission, or an approved release. These are different points in the process.
Choose the proposal you can explain back
Before signing, try explaining the proposal in a few sentences: what will exist, what you will pay, what you must supply, and what happens after handover. If you cannot explain a material part, ask for clarification rather than filling the gap with an assumption.
Build with Kat uses a written scope and a project-specific fixed quote. The free scoping call is a chance to discuss whether a focused build suits your idea and what the proposal should cover.
Related app guides
Ready to build?
Ready to scope your first version?
Bring the idea, audience, and current workaround. I will help decide what belongs in version one, what should wait, and whether a fixed-price build makes sense.
See app build options