Fixed Price vs. Hourly: How to Pay for App Hardening

Here is the moment you are in. A working demo. A pilot on the calendar. A vendor quote on your screen with two pricing options you were not expecting to have to choose between. The number on the left looks safer. The structure on the right sounds more flexible. Neither description tells you which one protects your runway — and the difference between choosing correctly and choosing quickly can cost more than the gap between the rates.

Why does pricing even matter when my real problem is a brittle MVP?

Pricing structure determines who carries the risk when scope surprises appear — and in a vibe-coded codebase, surprises are not the exception. A fixed-price contract on unknown depth forces the vendor to hedge by padding the quote or stopping at the budget ceiling, not at the finish line. An hourly contract on well-defined work leaves your budget open-ended when it never needed to be. Either mismatch can blow a pilot deadline faster than a bug report.

The rate itself is almost never the problem. The model is.

Your AI-generated MVP got you to a demo. That is genuinely hard. Now the work is different: you need to productionize something whose internal structure neither you nor the tool that built it fully documented. The pricing question is really a scope-certainty question in disguise — and the two models answer it differently.

Fixed price works when you know exactly what needs hardening

Fixed price is appropriate when the scope is fully defined before any work starts. That means a named codebase, a specific list of deliverables, and a ceiling both sides can commit to without either party absorbing surprise overruns. When those conditions are met, fixed price gives you budget legibility — the one thing your runway needs most.

The key word is "before." If your vendor cannot write down exactly what they will audit and what they will hand back before the contract is signed, fixed price is not protecting you. It is protecting them.

What counts as 'fully defined scope' in a hardening engagement?

Bounded scope names three things: a specific codebase, a defined stage of your pipeline, and a fixed list of outputs. A scoped engagement might cover the ingest-through-QA-generation stage of a pipeline and deliver a threat model plus a remediation report. That is a bounded scope. "Make it secure" is not.

If the statement of work contains the phrase "as needed" or "ongoing," the scope is not defined — regardless of whether the contract says fixed price. Push for exact pipeline stages and named deliverables before you sign. If the vendor cannot produce them, the work is not ready to be priced as fixed.

What does a fixed-price audit actually deliver versus a scanner tool?

A scoped fixed-price engagement produces functional app understanding, intent modeling, and a remediation plan you can act on or hand to another engineer. A scanner tool surfaces issues and returns the problem to you — without resolution, without context, and without portability.

The three layers of the market make this distinction useful. Vibe-native scanners find issues only. Legacy DevSecOps tools were packaged for professional engineering teams, not solo founders or small teams inheriting a vibe-coded codebase. Neither category completes the loop: ingest, threat model, pen-test, code and architecture review, QA generation and execution, automated remediation, then platform rip and deploy. A fixed-price audit that covers a defined segment of that pipeline hands you an artifact. A scanner hands you a list.

The artifact travels with you. The list does not.

Hourly is the honest model when the depth of the problem is genuinely unknown

No one can price spaghetti code they have not read. A vibe-coded MVP carries tech debt in amounts and locations that are invisible until a senior engineer sits with the code — and forcing a fixed price on that uncertainty does one of two things: it inflates the quote to cover vendor risk, or it incentivizes the vendor to stop when the budget runs out rather than when the work is done.

Hourly is not a blank check. It is an acknowledgment that the true scope has not yet been measured. That is an honest position. The alternative — a fixed price built on a guess — is not conservative. It is a transfer of risk, and the direction of transfer depends entirely on who has more information at signing. The vendor always has less than they need. You always have less than you think.

Hourly, with the right controls, lets the work define the scope rather than the other way around.

How do I stop an hourly engagement from becoming an open-ended money drain?

Three controls keep an hourly engagement bounded: weekly time-boxed sprints, a written change-order threshold, and a shared project board where every hour maps to a named deliverable. With those in place, you remain the decision owner at each milestone — not a passenger watching the meter run.

The sprint structure matters most. When each week closes with a named output — a completed code review, a QA generation run, a threat model for a specific module — you can decide at the sprint boundary whether to continue, redirect, or stop. That decision gate is what separates a controlled hourly engagement from an open-ended one. Without it, you are not buying flexibility. You are buying ambiguity.

Set your change-order threshold in writing before work starts. A realistic number is a percentage of the original estimate — if scope grows beyond that, the vendor writes a new line item and you approve it before the hours are spent. That single clause removes most of the fear attached to hourly pricing.

The hybrid approach: fixed price for the audit, hourly for the remediation

The model that matches certainty to pricing at each phase is a hybrid: a fixed-price diagnostic sprint to size the problem, followed by a capped hourly block for remediation. Neither party carries unfair risk, and your runway stays legible throughout.

The diagnostic sprint has a defined output — a threat model, a prioritized remediation report, a clear picture of what the codebase actually contains. That output is bounded. Fixed price fits it. The remediation that follows depends on what the audit found, which means the scope is not yet known when the audit begins. Hourly with a cap fits that phase.

This structure also protects your pilot timeline. You know what the audit costs before you commission the remediation. You can make a go/no-go decision at the boundary with real information rather than a vendor's pre-sale estimate.

One question to ask before you sign any engagement

Ask this: "What happens if the scope grows by 30 percent mid-engagement?"

A trustworthy answer names the change-order process and a rate. The vendor describes exactly how a scope addition gets documented, approved, and priced — before the extra hours are spent. That answer, specific and procedural, tells you the vendor has managed this before and expects to manage it transparently.

A vague answer is a red flag. "We'll work something out" or "that hasn't come up yet" means the vendor has not thought through the moment when your interests and theirs diverge. That moment will come. In a vibe-coded codebase with unknowable tech debt, it almost always does.

The question is not about the rate. It is about who is in control when the unexpected arrives — and whether the contract you are about to sign answers that question before it needs to.