Hourly or Fixed Bid? How to Structure Your App Development Engagement
This is the sixth post in a series adapted from my guide, Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. Each entry takes one slice of the guide and turns it into something you can read in ten minutes.
Once you've found a developer you want to work with, the next decision is how to structure the engagement. Specifically: are you paying by the hour, or paying a fixed price for a defined scope of work?
Most clients assume fixed bid is safer because the number is agreed in advance. In practice, for most projects, hourly is the healthier contract type. It aligns incentives and keeps the conversation honest about what's actually being built.
That's not always the case. Both models make sense in the right situations, and a well-structured engagement often combines them. This post explains what each model actually means in practice and how to think about which one fits yours.
How hourly billing works
You pay for the developer's time at an agreed rate. The total cost depends on how long the work takes.
The appeal is straightforward: you're not committing to a number before you fully understand what you're building. If the scope turns out to be simpler than expected, you pay less. If you want to change direction mid-project, you can without a contractual renegotiation. And because both parties are working from the same live picture of hours spent, the conversation about what's being built tends to stay honest.
This is why hourly suits most projects. Development, especially in early stages, involves discovery. You learn things as you go: about what users actually need, about technical constraints you didn't anticipate, about features that don't work the way you imagined. Hourly billing accommodates that reality rather than fighting it.
The discipline hourly requires is attention. Someone needs to be tracking the hours, reviewing them regularly, and raising a flag when the project is running ahead of the estimate. That responsibility is shared between you and the developer. A good hourly developer gives you detailed time logs and flags concerns before they become billing surprises. Your job is to read them and ask questions.
How fixed-bid billing works
You agree on a defined scope and a single price for that scope. The developer delivers what was agreed; you pay what was agreed.
In practice, fixed-bid projects are always milestone-based. That's simply how you structure the work and how the developer gets paid along the way: a portion at the start, further payments tied to defined deliverables (designs approved, initial build complete, testing done), and a final payment at delivery. The milestones also give you natural checkpoints to review the work before the next phase begins.
Fixed bid works well when the scope is genuinely clear before work begins. That means detailed designs, a specific feature list, and agreed acceptance criteria. When those conditions exist, a fixed price gives you cost certainty and gives the developer a clear target. The model rewards efficiency: a developer who finishes under their estimated hours earns a better effective rate, and you pay no more than agreed.
The risk is that fixed bid only works cleanly on what was defined. Scope changes mid-project mean renegotiation, which is fine when both parties expect it but creates friction when the client assumed the original price covered everything. For projects where the direction is likely to evolve, that friction adds up.
Hybrid approach worth considering
For many engagements, the right answer isn't one model or the other but a deliberate combination of both.
Concrete, well-defined deliverables work well on fixed bid: a specific set of screens, a defined feature, a particular integration. Both parties know exactly what's being built and can agree on a price before the work begins.
Everything else works better hourly: iterative work where the outcome isn't fully defined yet, maintenance and bug fixes, onsulting and review, and any work that's inherently ad hoc. These activities don't have a clean scope to price against, and trying to force them into a fixed bid produces either inflated estimates (to cover the uncertainty) or low-quality work (cut to hit the price).
A thoughtfully structured engagement often looks like this in practice: fixed bid for the initial defined build, hourly for everything before it (discovery, design iteration, scoping) and everything after it (maintenance, feature additions, support). The fixed bid covers the part where you both know what you're building. The hourly covers the parts where you're still figuring it out, or where the work is ongoing and variable by nature.
How to choose
A few questions that point toward an answer.
How well defined is the scope? Detailed designs, a specific feature list, and agreed acceptance criteria point toward fixed bid. Anything more exploratory points toward hourly.
Is this a one-time build or an ongoing relationship? A standalone project with a clear endpoint suits fixed bid. An ongoing engagement with evolving priorities suits hourly, possibly with fixed-bid blocks for specific deliverables as they're defined.
How much do you trust the developer's estimate? Fixed bid shifts the estimation risk onto the developer. They price in a buffer to cover that risk, which is appropriate. Hourly makes the estimate a working target rather than a hard ceiling, which requires more discipline on both sides but tends to produce a more honest number.
What happens after launch? If you expect to need the developer for maintenance, improvements, or support, establish what that looks like before you sign the initial contract. Most post-launch work is poorly suited to fixed bid and works better on retainer or hourly.
The conversation to have before you sign anything
Whatever model you agree on, ask the developer to walk you through what happens when something changes. What's the process for adding a feature? What if a deliverable needs more revision than expected? What's the post-launch support arrangement?
A developer who has clear, practiced answers to these questions has managed projects before and thought about how to handle the inevitable complications fairly. A developer who hasn't considered it is going to be figuring it out under pressure at the worst possible moment.
The next post in the series gets into what you should own at the end of a project: accounts, code, and the assets most clients don't know to ask for until they need them.
This post is adapted from Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. If you'd rather just talk it through, reach me at scott@appswage.com.