Fixed Price or Hourly Rate for a Custom Business System? How Software Projects Are Priced

One developer sends back a single total. Another sends an hourly rate and an estimate of how many hours the job might take. They look like two answers to the same question, but they are two different ways of sharing risk between you and whoever builds your system, and the choice quietly decides who pays when something turns out bigger, smaller or different from what anyone expected. This guide explains how custom software projects are priced, what each model does to your budget and to change requests, and how to pick the one that fits your project. It is about how a price is built, not whether a particular price is fair; for lining up two finished quotes, see how to compare two custom software quotes side by side.

The three pricing models in plain terms

Almost every custom software quote is one of three models, or a mix of them. Knowing which one you are being offered is the first step, because the same headline number means different things under each.

One thing is easy to confuse with a pricing model and is not one: a payment schedule. A fixed price can be paid in instalments tied to milestones, and a phased project can be paid on completion of each phase. Milestones say when you pay; the model says how the total is decided and who carries the risk if it moves. The quote-comparison guide covers how to read payment milestones themselves.

How a fixed price works, and what it assumes

A fixed price is the model most business owners expect: you describe what you need, the supplier writes down what they will build, and the two of you agree one total.

• What you are really buying. A defined scope for an agreed total. The scope is the contract; the price only means something relative to it.
• Where the risk sits. The supplier carries the risk that the work takes longer than estimated. You carry the risk that the scope was written wrongly, because anything outside it is a separate conversation.
• How change requests work. A new feature, or a changed one, is quoted as a change request: its price and effect on the date are agreed before the work starts. That is a good protection, but only if the original scope is specific enough to show what counts as a change.
• What it assumes. That the requirements are understood well enough to be written down. If they are not, the supplier either pads the price to cover uncertainty or quotes low and recovers the difference through change requests.
• What it does not guarantee. A fixed price fixes the cost of the scope, not the quality of the result. What “done” means still needs to be written, which is what acceptance testing before you sign off is for.

How hourly rates work, and what they assume

Under time-and-materials, you pay for the time actually spent, at an agreed hourly or daily rate, plus any agreed costs. The supplier usually gives an estimate, but an estimate is a forecast, not a promise.

• Where the risk sits. With you. If the work takes more hours than estimated, you pay for them. This is fair when the extra time came from discoveries or changes you asked for, and uncomfortable when it came from the supplier simply being slower than expected.
• What it is good at. Work where nobody can yet write a reliable scope: an idea still being shaped, an integration whose behaviour has to be investigated, or small ongoing improvements after launch. Changes cost only the time they take, with no negotiation each time.
• What it needs from you. Regular reviews. A supplier paid for time has no built-in reason to finish sooner, so the discipline comes from you checking progress against the estimate and asking early when the numbers drift.
• How to make it safer. Ask for a written estimate with a range, a report of hours worked at a regular interval, and a cap: a not-to-exceed figure the supplier must raise with you before passing.

Hourly work is not a worse deal than a fixed price. It is a different deal, in which you hold the budget risk and keep the flexibility.

Phased pricing: the middle path

Many projects are neither clear enough for a firm total nor open enough to justify an unlimited meter. A phased price splits the project into stages, each with its own scope and price, agreed before that stage starts.

• A paid discovery stage first. A short, separately priced stage that turns a rough idea into a written scope, screens or a prototype, and a better estimate. The build is then fixed-price or phased, on much firmer ground.
• Then a core release. The smallest version that does the essential job, delivered and tested, so you see real software before committing to the rest.
• Then further phases. Reports, extra modules, integrations or a mobile app, each priced when you are ready for it.

The strength of phasing is that every stage ends with something you can test, and you can stop, change direction or switch supplier between stages with limited loss. The cost is that the final total is not known on day one, and each phase boundary needs a decision from you. It suits larger systems and projects with real unknowns. How long a custom business system takes explains why the same shape appears in the schedule.

What each model does to risk, change requests and budget certainty

Put the models side by side and the real difference is who absorbs a surprise.

No row shows a model that is simply cheaper. Each shifts cost and risk to a different place and a different moment, which is why the lowest headline number is not always the lowest final bill.

Which model fits which project

The best model follows from how well you can describe what you need today.

A worked example: one system, three ways of pricing it

The figures here are made up to show the mechanics; they are not Gotka prices. A wholesaler wants a system to take orders and track stock. Three suppliers respond.

• Supplier A quotes a fixed price for a written list: twelve described screens, three reports and a stock import.
• Supplier B quotes time-and-materials at an hourly rate, with an estimate of 280 to 360 hours.
• Supplier C proposes phases: a short discovery stage, then the order and stock core, then reports.

Halfway through, the owner realises the warehouse needs a printed delivery sheet that was never discussed. With Supplier A, that is a change request: the sheet is priced, the owner approves it, the work proceeds, and the original total is untouched. With Supplier B, the sheet is simply built, the hours rise and the bill may end above the top of the estimate. With Supplier C, the sheet goes into the next phase, where it is scoped and priced alongside the reports.

Nobody behaved badly in any version. The owner just learned something late, and each model decided who paid for the lesson and when. If the owner had known about the delivery sheet at the start, all three quotes would have included it, and the comparison would have been much closer.

Questions to ask whichever model you are offered

• Which model is this, exactly? Ask the supplier to state it in the quote: fixed, time-based or phased.
• What is in the scope, and what is out? A fixed price is only as firm as its scope. Ask for the exclusions in writing.
• How are changes priced? Ask for the rate or method, how a change is approved, and who can approve it on your side.
• If it is hourly, is there a cap? And what happens when 80 percent of the budget is used.
• How will I see progress? A demo, a report of hours or a working build at regular points.
• What counts as finished? Agree acceptance criteria before the work starts.
• Who owns what you are paying for? Price does not settle ownership; who owns the source code needs its own answer.

Common mistakes

• Treating the lowest total as the best deal. A low fixed price on a vague scope often grows through change requests; a low hourly estimate often grows through hours.
• Choosing fixed price without a written scope. The certainty exists only on paper if the paper is vague.
• Choosing hourly with no cap and no review. It leaves the whole budget risk with you and nobody watching it.
• Comparing a fixed price with an hourly estimate as if they were the same thing. One is a commitment, the other a forecast.
• Confusing payment milestones with a pricing model. Paying in stages does not make a price phased.
• Changing requirements and then being surprised by the bill. Every model charges for change; they differ only in how and when.
• Skipping discovery on a project with real unknowns. A small paid stage up front is often cheaper than discovering the unknowns mid-build.

Where Gotka Technologies fits

Gotka’s App & System Development service builds web apps, business systems and mobile apps, with indicative starting prices of RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, each confirmed by a written quote once the scope is understood. Those are starting points, not a pricing model, so whichever supplier you ask, including us, ask the written quote to say whether the price is fixed, time-based or phased, and what is excluded. If you are still deciding between building and buying, read off-the-shelf vs custom software, and for the question of who should build it, see freelancer, in-house developer or development company. Whatever is built also needs a reliable place to run, which is where Gotka’s Cloud Hosting comes in.

Key terms used in this guide

• Fixed price: a single agreed total for a defined scope of work.
• Time-and-materials: a billing model where you pay an hourly or daily rate for the time actually spent, plus agreed costs.
• Estimate: the supplier’s forecast of the time or cost, which under time-and-materials is not a commitment.
• Not-to-exceed cap: a limit on time-based billing that the supplier must discuss with you before passing.
• Phased price: a project split into stages, each with its own scope and price agreed before it starts.
• Discovery stage: a short, separately priced stage that turns a rough idea into a written scope and a firmer estimate.
• Change request: a request to add or alter something outside the agreed scope, priced and approved before the work begins.
• Payment milestone: a defined stage that triggers a payment, which sets when you pay rather than how the total is decided.