Fixed price vs hourly: how should you pay a developer?

Pay a fixed price when the work can be described clearly before it starts, and pay by the hour when it can't. A defined fix, a landing page or a well-specified feature suits a fixed price; investigating an unknown bug or exploring a new idea suits hourly work with a cap. For ongoing changes, a monthly plan is often simpler than either.

This guide explains how each model works, who carries the risk in each, the hybrid arrangements that combine them and what to put in writing so neither side is surprised.

How does each pricing model work?

When is a fixed price the better choice?

A fixed price works when both sides can picture the finished result. Examples:

• Connecting a custom domain and fixing the login redirects that break with it.
• Adding Stripe subscriptions with three named plans.
• Building one well-described screen from a design.

Its strengths are predictability and focus on the outcome. You know the cost before you start, and the developer has every reason to work efficiently.

Its weaknesses show up when the scope is fuzzy. A developer quoting a fixed price on unclear work will add a margin for the unknown, so you may pay more than the hourly cost would have been. And every change you request along the way becomes a negotiation.

When does hourly make more sense?

Hourly works when nobody can know the size of the job until they start:

• "Sometimes users get logged out and we don't know why."
• "We want to see if this idea is even possible with our current setup."
• "The app is slow and we don't know where."

You pay only for the time used, and you can change direction freely. The risk is that there's no ceiling. An investigation can go on for a long time, especially if the developer is learning your codebase from scratch.

How do you make hourly work safer?

1. Agree on a cap, such as a number of hours, before work starts.
2. Ask for a check-in at half the cap: what's been found, what's left, whether to continue.
3. Get time logs that say what each block of hours was spent on.
4. Define a stopping point: "If the cause isn't found by the cap, deliver a written summary of what was ruled out."

Is there a middle ground?

Yes, and it's often the best option for an app with problems you don't fully understand yet:

1. A paid diagnosis first. A short, fixed-price review of the code that ends in a written report.
2. Then a fixed price per fix. Once the problems are known, each one can be quoted clearly.

This puts the unknown part in a small, capped box and the known part under fixed prices. Our guide on what it costs to fix an AI-built app explains why quotes vary so much before a diagnosis.

For bigger projects, milestones do something similar: the project is split into stages, each with its own deliverable and price, and you can stop after any stage.

What about monthly plans and retainers?

When the work never really ends (bug fixes, updates, small features, monitoring), quoting each task separately is slow for everyone. A monthly plan gives you a known cost and someone who already knows the app. Check:

• What's included: fixes only, or new features too?
• How fast they respond, and on which days.
• What happens to unused time: does it roll over or expire?
• How to cancel, and how much notice is needed.

What should be in writing, whatever the model?

1. Scope. What will be delivered, and what's explicitly not included.
2. Acceptance. How you'll both know it's done: "a user can pay and see the Pro badge within a minute".
3. Changes. How new requests are handled: a new quote, added hours or the next milestone.
4. Payment terms. Deposit, payment per milestone, and when invoices are due.
5. Ownership. That the code is assigned to you once paid. Our overview of who owns AI-made code explains why this matters (and why it's worth a lawyer's review).
6. Access and handover. Code in your repository, accounts in your name, and documentation at the end.

What warning signs should you watch for?

• A fixed price given without looking at the code or the design.
• Hourly work with no estimate, no cap and no updates.
• A very low fixed price for work that clearly touches payments or permissions, which often means the cause won't be fixed, only the symptom.
• No written scope at all.

Quick answers

Is fixed price always more expensive? Not always. On clear work it can be cheaper because there's no time spent negotiating. On unclear work it usually includes a margin for risk.

Can I switch models mid-project? Yes, and it's common: start hourly to investigate, then move to fixed prices once the work is defined.

Should I pay everything upfront? For larger work, paying per milestone protects both sides better than paying everything at the start or end.

Which model is best for an AI-built app with bugs? A short paid diagnosis followed by fixed prices per fix, because the problems usually aren't known until someone reads the code.

How does Devonauts charge?

We use the diagnosis-then-fixed-price approach: the App Rescue Audit is $299, fixes found get a fixed price you approve first, and ongoing work runs on monthly plans. See our pricing, maintenance and support and MVP development, or contact us.