Why We Do Not Do Fixed-Price Contracts (and What We Do Instead)

Early on, we did a fixed-price project that went exactly like you would expect. The client wanted a “simple” booking platform. We scoped it, quoted it, signed the contract. Three weeks in, “simple” had grown to include a loyalty points system, SMS reminders, and a multi-location calendar sync. The scope had doubled but the price had not. We had two options: cut corners to stay within budget, or eat the cost and deliver what the client actually needed. Neither option is good. That project taught us a lesson we have not forgotten.

We do not do fixed-price contracts anymore. Here is why, and what we do instead.

The Problem with Fixed Price

Fixed-price contracts sound appealing. The client knows exactly what they will pay. The agency knows what they need to deliver. Everyone is protected. Except none of that is true in practice.

Software development is not like building a house. When you build a house, the blueprints are complete before the first brick is laid. The materials are known. The processes are well-established over centuries. You can estimate with reasonable accuracy.

Software is different. Requirements evolve as you build. Users give feedback that changes priorities. Technical discoveries reveal that the “simple” integration is actually complex. The market shifts. A competitor launches a feature you need to respond to. The whole point of building custom software is that you are solving a problem nobody has solved in exactly this way before. You cannot fully predict the work.

Fixed-price contracts create three specific problems:

Bad incentives for the builder. Once the price is locked, every additional hour comes out of our margin. The rational economic move is to do the minimum possible work to meet the letter of the spec. Cut testing. Skip edge cases. Use the quick hack instead of the right solution. Ship something that technically meets the requirements but nobody loves.

An adversarial relationship. Every change request becomes a negotiation. “That’s out of scope” becomes the most-used phrase in the project. The client starts feeling nickel-and-dimed. The agency starts feeling taken advantage of. Instead of collaborating on the best product, both sides are managing a contract.

Inaccurate estimates baked into commitments. Software estimation is notoriously difficult. Studies have consistently shown that developers underestimate by 30-50% on average. With fixed price, that estimation error becomes a financial problem. Either the agency pads the estimate significantly (and the client overpays), or the agency eats the difference (and the quality suffers).

We have seen this play out with clients who come to us after fixed-price engagements with other agencies. The story is almost always the same: the project went over the original timeline, the final product did not match expectations, and the relationship ended badly.

Time and Materials with Guardrails

Our default engagement model is time-and-materials billing with clear guardrails. You pay for the actual work done, at agreed-upon rates, with full transparency into how that time is spent.

But we do not just hand you an open-ended invoice and say “trust us.” Here is what the guardrails look like:

Weekly time tracking and reporting. Every week, you get a detailed breakdown of what was worked on and how long it took. No surprises. If you see a line item that seems off, we talk about it immediately.

Budget ranges, not fixed prices. At the start of every project, we provide a budget range — not a single number. For example, when we scoped MindHyv, we estimated the MVP at 320-400 hours based on the feature set. The range accounts for the inherent uncertainty in software. The final number came in at 370 hours — right in the middle.

Monthly spending caps. If you need to control cash flow, we set a monthly cap. We will not exceed it without your explicit approval. This gives you the predictability of fixed pricing without the perverse incentives.

Prioritized backlogs. We work from a prioritized backlog that you control. If something is taking longer than expected, you can reprioritize. Drop a lower-priority feature to stay within budget. Simplify a complex feature. You are always in control of where the hours go.

Here is roughly how we structure the agreement:

Engagement Terms (simplified):
- Hourly rate: $XX/hour (blended rate for the team)
- Billing cycle: Bi-weekly invoicing
- Monthly cap: $X,000 (adjustable with 2 weeks notice)
- Minimum commitment: 4 weeks
- Notice period: 2 weeks to pause or end
- Included: All development, code review, deployment, communication

Milestone-Based Billing for Larger Projects

For larger engagements — typically projects over $30,000 — we break the work into milestones. Each milestone has a defined outcome and an estimated budget. You approve each milestone before we move to the next.

This is not the same as fixed-price per milestone. The budget is an estimate, not a guarantee. But because milestones are small (usually 2-4 weeks of work), the variance is much smaller. If a milestone runs 10% over estimate, that is a few thousand dollars, not a blown budget.

Milestones also create natural checkpoints for review and course correction. After completing the first milestone for LancerSpace, the client realized they wanted to restructure the proposal workflow based on early user feedback. Because we were at a natural stopping point between milestones, we could adjust the plan without waste. Under a fixed-price contract, that pivot would have triggered a change order and a renegotiation.

A typical milestone breakdown for an MVP might look like:

Milestone 1: Foundation (2 weeks)
- Project setup, auth, database schema, CI/CD
- Estimate: 60-80 hours
- Deliverable: Deployed staging environment with auth working

Milestone 2: Core Features (3 weeks)
- Primary user flows, data models, business logic
- Estimate: 90-120 hours
- Deliverable: Core product functional on staging

Milestone 3: Polish and Launch (2 weeks)
- UI polish, edge cases, performance, monitoring
- Estimate: 50-70 hours
- Deliverable: Production deployment

Total estimate: 200-270 hours

Each milestone gets a demo. You see the working product, give feedback, and approve the direction before we continue.

Retainers for Ongoing Work

After launch, many of our clients move to a monthly retainer. This works well for products that need continuous development — new features, bug fixes, performance improvements, integrations.

A retainer is a pre-purchased block of hours per month at a slightly discounted rate. Common retainer sizes for us are 20, 40, or 80 hours per month. Unused hours do not roll over (we tried that once — it creates bad dynamics where clients stockpile hours and then dump a massive request), but we are flexible about adjusting the retainer size month to month.

Retainers work because they create a predictable relationship for both sides. We can plan our capacity. You can plan your budget. And because we are engaged month over month, we maintain deep context on your codebase and product, which means we work faster than a team ramping up from scratch.

We cover our post-launch support model in detail in Post-Launch: What Happens After We Ship Your Product.

How We Handle the “But I Need a Number” Conversation

We get it. You have a budget. Your stakeholders want a number. You cannot go to your board with “it depends.”

Here is how we handle it:

Discovery first. Before we quote anything, we do a paid discovery phase (usually 1-2 weeks). We dig into your requirements, map out the technical architecture, identify risks, and produce a detailed estimate with ranges. This costs money upfront, but it dramatically reduces uncertainty for both sides.

T-shirt sizing for early conversations. Before discovery, we can give you rough ranges to make sure we are in the same ballpark. A simple MVP is typically $15,000-30,000. A more complex platform is $40,000-80,000. An enterprise integration project can be $80,000+. These numbers are directional only — the actual scope determines the actual cost.

Transparent trade-offs. If your budget is $40,000 and the ideal scope estimates at $55,000, we do not just say “sorry, too expensive.” We work with you to find the $40,000 version. Which features are essential for launch? What can wait for V2? Where can we simplify without compromising the core value?

This is one of the biggest advantages of flexible pricing: the conversation is about building the best product within your constraints, not about enforcing a contract.

Why Transparency Beats Certainty

The underlying philosophy is simple: you should always know what you are paying for and why.

With fixed-price, you get the illusion of certainty. The number on the contract feels safe. But behind that number, the agency has padded their estimate, baked in risk premiums, and reduced their commitment to quality — all to protect their margin on a bet they might lose.

With our approach, you get transparency. You see every hour. You control every priority. You can adjust course at any time. The total might be slightly unpredictable, but the value-per-dollar is higher because every dollar goes toward building the product, not padding an estimate.

After five years and over a dozen shipped products — including Trackelio, JustTheRip, and Spots Mexico — this model has worked for every client we have worked with. Projects finish closer to estimate, relationships stay collaborative, and the products are better.

When Fixed Price Actually Makes Sense

We will be honest: there are scenarios where fixed-price is appropriate. Small, well-defined projects with minimal unknowns — a landing page, a static site migration, a simple integration between two systems with well-documented APIs. If the scope is genuinely predictable, a fixed price can work.

But for custom software development — building a product from scratch, developing a complex feature set, integrating multiple systems — the uncertainty is too high for fixed price to serve either side well.

If you are evaluating agencies and pricing models for your next project, we are happy to talk through the options and what would work best for your situation. Reach out at [email protected].