Fixed price vs hourly: which way should you pay for app development?

The two models in one sentence each

With a fixed price, you and the developer agree what will be built, write it down, and agree one price for it. With hourly billing, sometimes called time and materials, you agree a rate and pay for the hours actually spent, usually with regular reports.

The difference is who carries the risk, and the right one depends on how well you can describe the app today.

Who carries the risk

Every software project has unknowns. The question is who pays when an estimate turns out to be wrong.

Apps that suit a fixed price

Fixed pricing works when the first version can be described as a list of screens, user roles and features. Most first apps fit that: a booking app, an ordering app, a membership app, a directory, a customer portal. The work is real, but it is not research.

It also helps when you have a budget that cannot move, which is true for most founders and small businesses. Knowing the total lets you plan marketing and launch around the app instead of watching an hours report every week.

• You can list the screens and what each user can do.
• You need to know the total before you commit.
• You would rather agree changes one by one than have an open-ended bill.

Work that suits hourly billing

Hourly billing is the better choice when nobody can honestly write the scope yet. That includes products that depend on an experiment working, integrations with systems no one has documented, and long-running development where priorities change every few weeks.

In those cases a fixed price would either be padded heavily to cover the unknowns, or it would lead to arguments about what was in scope. Paying for time, with a cap per month and frequent demos, is fairer to both sides.

How to make a fixed price actually fixed

A fixed price is only as good as the scope behind it. If the scope says "a booking app", every disagreement later is about what that phrase meant. If it lists the screens, the roles and what is excluded, there is very little to argue about.

• A list of screens or a screen count, with what each one does.
• The user roles (customer, staff, admin) and what each can see.
• What is explicitly not included, such as payments, chat or a web dashboard.
• How changes are handled: written down and priced before they are built.
• Who owns the code and the store accounts at the end.

How I price work

My mobile app packages are fixed prices: Launch at $999 for up to 10 screens, Growth at $1,699 for up to 25 screens with its own backend, and Scale at $2,500 for up to 50 screens with an admin dashboard. Custom software is quoted the same way, as a fixed price against a written scope.

If a change comes up during the build, I write down what it adds and what it costs, and nothing is built until you agree. Where a project genuinely cannot be scoped yet, I say so and suggest a short paid discovery or a CTO consulting engagement first, rather than guessing a number.