Why I Don’t Price Software Like a Project

If you're hiring a developer and asking for a fixed price to "finish" an uncertain existing system, you're starting from the wrong model.

TLDR: Defined new delivery phases can use a fixed-price project retainer. Rescue work and poorly understood existing systems need an evidence-first structure because the conditions required to promise completion are not known yet.
Software money trap

The Question Clients Always Ask

At some point, every conversation gets here:

“Can you just give me a price to fix this?”

Or:

“If I keep paying you, will this get finished?”

Those questions make sense — but they assume something that isn’t true.

They assume the system is already understood.

It’s not.

What You’re Actually Buying in an Unknown System

When you bring someone into an inherited, unstable, or poorly understood codebase, you’re not automatically buying a finished outcome.

You’re buying:

  • time inside a system
  • investigation
  • progress based on what’s uncovered

Because the reality is:

no one fully understands the system until they’re inside it.

Why Fixed Completion Pricing Breaks on Unknown Systems

When you ask for a fixed price to complete work whose current state has not been inspected, you’re asking someone to:

  • predict unknown depth
  • assume no hidden issues
  • ignore how software actually behaves

That’s how projects go wrong.

Not because developers are bad.

Because the model is wrong.

What Actually Happens When Work Starts

  • You start digging
  • The problem expands
  • You uncover dependencies
  • You understand the system
  • Then it stabilizes
  • Then it gets fixed

That expansion phase?

That is the work.

How Engagements Work

1. Defined delivery phases can use a fixed-price retainer

A prototype, MVP, application release, or other bounded phase can be described in a written proposal with included deliverables, assumptions, schedule, exact fee, and a change process.

2. Unknown systems start with evidence

Existing systems with unclear conditions begin with an assessment or focused consulting blocks. Each step moves the system forward and clarifies what is actually there.

3. The accepted proposal is the boundary

Fixed-price payment covers only the defined delivery phase. Added or changed work is reviewed and approved separately.

4. We focus on what matters first

We don’t fix everything. We stabilize the highest-leverage part of the system.

5. Payment terms match the engagement

A defined project can use a discounted prepaid total or a fixed weekly payment plan. Open-ended consulting remains tied to approved time and objectives.

6. The honest expectation

Defined work receives a defined commercial structure. Unknown work does not receive a false completion promise.

The Real Decision

The question isn’t:

“How much does it cost to finish?”

The real question is:

“Is this work defined well enough for a proposal-defined phase, or do we need evidence first?”

Final Thought

I’m not here to promise outcomes that the available evidence cannot support.

I’m here to define what can be responsibly proposed, move the system forward, and show you what is real before the next commitment.

One-line version

Price defined delivery phases; investigate uncertain systems before promising completion.

Next Step

Learn how the engagement structures differ → How Engagements Work or review Fixed-Price Project Retainers.

Software rescue and reliability

Apply This to Your Project

Connect the technical problem to hands-on work on the application, backend, and data. Review what needs to launch, stabilize, or be replaced, and agree the next delivery stage.