The commercial structure follows how much is known: defined delivery phases can use a fixed-price project retainer, while uncertain existing systems begin with an assessment or focused consulting blocks.
A new, bounded delivery phase can be described and priced in a written proposal. An inherited, unstable, or poorly understood system may reveal important conditions only after inspection. The engagement model should reflect that difference.
Prototype, MVP, application, and larger delivery phases may use a proposal-defined fixed-price retainer. The proposal identifies the included deliverables, assumptions, schedule, exact fee, and change process before payment.
Existing codebases, rescue work, and open-ended technical problems are not forced into a false completion promise. They can begin with the Four-Hour App Rescue Assessment or move forward in approved consulting blocks as the real condition of the system becomes clear.
A fixed price applies only to the delivery phase and deliverables in the accepted proposal. Added features, changed assumptions, and newly discovered work are reviewed in writing before they affect price or schedule.
An accepted project proposal can be funded through a discounted prepaid total or the standard total through a fixed number of weekly payments. The exact amounts, savings, payment count, and schedule are shown before checkout. The first payment is due before work begins.
Work is organized around reviewable milestones and practical evidence. When a decision, dependency, or change affects the agreed delivery phase, it is surfaced rather than hidden inside optimistic promises.
Defined work receives a defined commercial structure. Uncertain work receives an evidence-first structure. Neither approach treats software as unlimited work, and neither hides uncertainty from the client.