In this guide
An app development price is meaningful only when you know what it includes. Two proposals for the same idea can cover very different products: one may include a simple customer journey, while another includes administration tools, data migration, and multiple platforms.
Start with a brief that describes the first user and the task they need to complete. Then ask for a written quote against that brief. Build with Kat provides project-specific quotes after scoping rather than publishing a universal price list.
Key takeaways
The workflow matters more than the screen count
A five-screen app can still involve complicated access rules, scheduling conflicts, or payment states.
Platform and integrations change the work
A web product and an iPhone app have different testing and release needs.
Separate the build fee from running costs
A project fee pays for the agreed development work.
Compare proposals against the same checklist
Give each developer the same brief.
The workflow matters more than the screen count
A five-screen app can still involve complicated access rules, scheduling conflicts, or payment states. List what happens when the happy path breaks: an invitation expires, a payment fails, someone cancels, or an administrator needs to correct a record.
For example, a consultant’s client portal might start with invited clients, shared resources, and a progress update. Adding public signup, subscriptions, team permissions, and chat changes the project substantially. Ask the developer to explain those differences in the proposal.
Platform and integrations change the work
A web product and an iPhone app have different testing and release needs. Building both may allow some shared services, but each interface still needs attention. State which platform is required for the first launch and why.
For each integration, specify what it must do. Sending a booking email is different from synchronising availability across several accounts. Existing data also needs attention: where it comes from, how clean it is, and who is responsible for preparing it.
Separate the build fee from running costs
A project fee pays for the agreed development work. Hosting, email delivery, payment processing, third-party subscriptions, and usage-based services can continue after launch. Ask which accounts you will pay directly, and request current provider links and the assumptions behind any estimate.
Ask the developer to describe what would increase those costs, such as more members, more file storage, or more AI requests. Treat an estimate as a planning assumption rather than a guaranteed monthly bill.
Compare proposals against the same checklist
Give each developer the same brief. For every proposal, write down the included workflow, exclusions, design reviews, testing, launch support, ownership, and maintenance terms. Mark anything missing as a question rather than assuming it is included.
A fixed quote needs a clear change process. Confirm how extra work is estimated and approved before it starts. An hourly arrangement needs equally clear reporting and spending limits. The useful question is how each arrangement controls uncertainty in your project.
Reduce scope before reducing quality
If the quote is beyond your budget, ask which part can wait. A smaller first audience, one platform, or a manual administrative step may reduce the initial build. Keep the checks needed for the promised workflow to work reliably.
Bring your brief to a free scoping call with Kat. We can discuss the smallest useful version, confirm whether a focused build fits, and prepare a written quote with a timeline and payment milestones.
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