Fixed-price vs hourly billing - Leval

Audience: CTOs and technical founders at US/EU startups and SMBs Reading time: 15 minutes

If you've worked with dev agencies in the US or Europe, you're familiar with the hourly model. A contract lands in your inbox with an $80 - 180/hour rate, a "rough estimate" that's never binding, and a clause about weekly billing based on hours logged. You sign, because the alternative is not having the engineering capacity you need.

Six months later, you're tracking timesheets instead of features. The estimate has drifted 40%. Every scope question generates a change order. And somewhere between the kickoffs and status calls, you lost track of whether you're buying outcomes or buying time.

We don't bill by the hour. Every project at Leval has a fixed price, agreed before we start. This article explains why, how we make it work, and what it means for your team.

The hourly model creates the wrong incentives

Let's be direct about what hourly billing actually incentivizes.

When an agency bills by the hour, a slow developer is more valuable than a fast one. A project that takes 200 hours generates twice the revenue of a project that takes 100 hours - even if the outcome is identical. There's no financial incentive to write efficient code, to find a simpler solution, or to finish on time.

This isn't a character flaw of the people involved. It's a structural problem. The incentives point in the wrong direction, and eventually, behavior follows incentives.

The client on the other side of that arrangement gets:

• Unpredictable invoices
• Hours billed for meetings, admin, and internal coordination
• A constant low-grade anxiety about "running up the clock"
• No clear connection between hours spent and value delivered

You end up managing inputs (hours, tasks, sprints) instead of outputs (working software, shipped features).

What fixed-price actually means

Fixed-price doesn't mean "we'll build whatever you want for a flat rate." That's not how serious software development works.

Fixed-price means: we scope the project thoroughly upfront, agree on exactly what gets built, and commit to that price. Scope changes are discussed explicitly, not absorbed silently or discovered in the invoice.

The deal from your perspective:

• You know the cost before we write a line of code
• The number on the contract is the number you pay
• We're aligned on what "done" looks like from day one

The deal from our perspective:

• We need to scope carefully, because we carry the risk on estimation errors
• We're incentivized to build efficiently - faster and cleaner means better margin for us
• We're incentivized to understand the requirements correctly, because misunderstandings cost us, not you

This alignment is the core of why fixed-price works better than hourly for most software projects.

"But doesn't fixed-price mean you'll cut corners?"

This is the obvious objection, and it's worth addressing directly.

The concern is: if an agency commits to a fixed price and then finds the project harder than expected, they'll ship something mediocre to hit the deadline without losing money.

This happens. With agencies that don't scope properly, it's common. The fix isn't hourly billing - it's rigorous scoping.

When we scope a project, we're not just writing down feature names. We're identifying:

• The technical unknowns that could expand scope (third-party API behavior, legacy system constraints, authentication edge cases)
• The requirements that seem simple but aren't (bidirectional sync, conflict resolution, offline support)
• The non-functional requirements that will drive architecture decisions (load, latency, availability)

We build buffer into our estimates for the unknowns we know exist. Not to pad the price - to protect the quality. A project that's correctly scoped at a realistic price delivers better outcomes than a project that's artificially cheap and then cut at the end.

If we genuinely can't scope something - because the requirements are too uncertain, the domain is too novel, or the integration surface is too unpredictable - we say so. Some work genuinely requires time-and-materials. We'd rather tell you that than commit to a fixed price we can't hold.

How scoping actually works

The discovery process before we quote a fixed price:

Step 1: Problem, not solution. We start by understanding what the business actually needs. "We want to build an integration between our CRM and our ERP" is a starting point. We need to know: what data flows which direction, how often, with what latency requirements, what happens on conflict, who resolves errors.

Step 2: Technical surface assessment. Before we quote, we look at the relevant APIs, documentation, and existing system constraints. If the third-party API you're integrating with has rate limits, undocumented behavior, or poor reliability - that's scope risk, and it needs to be priced in or scoped out.

Step 3: RFC-style writeup. Our architect documents the proposed solution: data model, API contract, integration points, load characteristics, dependencies. This isn't a 50-page waterfall spec - it's enough detail that both sides can agree on what "done" means and spot disagreements before they become arguments.

Step 4: Scope negotiation. We present the estimate with explicit tradeoffs. "Here's the MVP scope for $X. Here's what's in scope and out of scope. If you want Y added, it's $Z more and 2 more weeks." You make explicit decisions about what to include, not implicit assumptions that come out later.

This process takes time - usually 1 - 3 days of architect work for a medium-size project. We do this before signing a contract, not after. The output is a shared understanding of the project, not a document that gets filed and forgotten.

What happens when scope changes

In any real project, some things change. A requirement that looked clear turns out to be ambiguous. You discover that what you thought you wanted isn't actually what you need. The market shifts and you need to pivot a feature.

Fixed-price doesn't mean "scope is frozen forever." It means "scope changes are explicit conversations, not silent additions."

Our process for scope changes:

1. Someone identifies a change - either you or us
2. We assess the impact: effort, timeline, dependencies
3. We present the options: include in current scope for $X more, defer to a follow-on, descope something else to make room
4. You decide

No surprise invoices. No passive-aggressive timesheets. No "we had to add that because the original requirements were unclear" - because the original requirements were made clear in the scoping process.

The timezone and rate arithmetic

We're a European-based team with 9 years of experience. Our engineers are senior. Our rates are significantly below what senior engineers cost in San Francisco, New York, or London - not because we cut corners, but because our cost structure is different.

The implication for you: fixed-price projects with us are competitively priced against hourly agencies in Western markets, even accounting for the fixed-price model carrying more of the risk on our side.

A $10,000 fixed-price project from us delivers the same outcome as an "estimated" $10,000 project from a US agency - except our number is binding and theirs isn't.

This isn't a pitch about offshoring to the cheapest possible option. Senior engineers who don't understand requirements and communicate poorly are expensive at any price. We're talking about a senior technical team with a different cost structure and a pricing model that aligns incentives properly.

What we won't take on fixed-price

Honesty requires the counterexamples.

Research and exploration. If you need us to investigate whether something is technically feasible, or to design an architecture for a novel problem - that's not fixed-price work. That's time-bounded research. We'll scope the research separately.

Highly ambiguous requirements. If you can't describe what "done" looks like in enough detail to scope it, we can't quote a fixed price responsibly. We'll run a paid discovery session to get to scoped requirements.

Active R&D. Building something genuinely new - new ML model, novel algorithm, pioneering integration with an undocumented system - carries too much technical uncertainty for fixed-price.

Ongoing maintenance and support. Maintenance is time-and-materials by nature. We handle this with SLA agreements, not fixed-price contracts.

For everything else - which covers the large majority of business software development projects - fixed-price works, and it works better for both sides.

The hidden costs of hourly billing that don't show up in the rate

The hourly rate is not the cost. It's the starting point.

Here's what actually gets billed in a typical hourly engagement:

• Developer hours - the rate on the contract
• Meeting time - every standup, review, planning session, and "quick call" is billable
• Context switching - when a developer moves between your project and another client's, you pay for the ramp-up time
• Rework - if the developer misunderstood a requirement and built the wrong thing, you often pay for the rebuild too
• Admin and coordination - PMs logging time, account managers on review calls, senior engineers reviewing junior engineers' work

A $120/hour rate across 500 hours is $60,000. That same project, scoped and delivered on fixed-price, might be $48,000 - with binding delivery instead of a best-effort estimate. The rate looks lower on hourly; the total is often higher.

There's also the cost of your own time. Managing an hourly engagement requires a significant investment from your side: tracking hours, reviewing timesheets, managing scope creep, adjudicating disputes about whether a particular hour was spent on your project or another. This is time your CTO or VP Engineering could spend on actual product decisions.

Fixed-price shifts this entirely. You review demos, not timesheets. You approve or decline scope changes as business decisions, not accounting entries.

What your development team should know

If you have an internal engineering team and you're evaluating us as a vendor, a few things worth understanding:

We deliver working software, not just code. Our handoff includes OpenAPI specs, README with architectural decisions, docker-compose for local development, and a runbook for your team. Your engineers should be able to pick this up and extend it without a call with us.

We don't lock you in. We use standard stacks, standard patterns, and good documentation specifically so that you can transfer ownership to your team or another vendor. We're not interested in creating dependency.

Your engineers will see the code during the project. We're comfortable with code review from your side mid-project. If your engineers have concerns about an architectural decision, we'd rather hear it in week 2 than week 8.

We'll tell you when your requirements are wrong. Not in a confrontational way - but if you're about to build something that won't solve the actual problem, we'll say so. We've been building software for a long time. Sometimes the most valuable thing we can do is push back on the brief.

A concrete example

A client came to us needing a pricing microservice for their B2B SaaS. They had 12 pricing parameters: user tiers, modules, regions, billing cycle, promo codes. Sales were calculating in Excel, manually creating invoices in Stripe. The process took 1 - 3 days per deal.

We scoped: Go service, pricing rules in PostgreSQL (so the product team could update pricing without a deploy), Redis cache (public-facing calculator expected 100 - 500 RPS), Stripe integration with backend price recalculation (never trust the price from the frontend).

Fixed price. Delivered in 6 weeks.

Result: quote-to-payment cycle dropped from 1 - 3 days to under 10 minutes self-service. Conversion from site visit to payment improved measurably.

That's what good scoping and fixed-price delivery looks like. Not a timesheet - an outcome.

How to start

If you have a project in mind - or just a problem and some rough requirements - describe it here.

We'll respond within one business day with either: a request for a discovery call (if the scope needs more definition), or a preliminary estimate and architectural approach (if the requirements are clear enough to scope immediately).

No hourly estimates. No "it depends" non-answers. A real conversation about what you're building and what it'll cost.

Leval is a cloud development team with 9 years of experience building backend services, integrations, bots, and browser extensions. Fixed-price projects. Any stack, any API.