Almost every project that comes to me starts the same way: someone has a system that's held together with spreadsheets and email, or an idea that's still just a document, and they want to know two things — what will it cost, and how long will it take. Fixed-price, milestone-based scoping is how I answer both questions before any code gets written.
Why not hourly?
Hourly billing puts the risk on the client: the meter runs whether or not the build is going well. Fixed scope puts the risk on me, which is exactly where it belongs — I'm the one who's supposed to know how long the work takes. It also forces a discipline that hourly work doesn't: I can't hand over a vague scope and bill my way out of the ambiguity later. The scope has to be specific enough to quote, which means it has to be specific enough to build.
The four steps
Every engagement, regardless of size, follows the same path:
- Discover. A strategy call to define the actual problem before touching a solution. This is where most of the ambiguity in a project gets removed. Output: a written scope and a fixed quote.
- Architect. You see and approve the blueprint before production code is written — the data model, the integrations, the rough shape of the system. Output: architecture and a milestone plan.
- Build. Working software at every milestone, not a black box that reappears at the deadline. Output: a working system, documented as it's built.
- Operate. Launch support, monitoring, and a handover your team actually owns — not a system only I can maintain. Output: stability and independence.
What this looks like at different scopes
A Launch-tier engagement (a custom platform or MVP, 2–4 weeks) goes through the same four steps as a Systems-tier one (multi-role platforms and integrations, 8–16 weeks) — the steps just compress or expand with the size of the problem. The fastest full idea-to-production turnaround I've run through this process is 3 weeks, for a startup's community platform that had 50 real users in its first week live. The process doesn't change; the calendar does.
Where it breaks down — and how I avoid that
Fixed-scope work only works if the scope is actually fixed. The failure mode is a client (or a consultant) treating "fixed price" as "unlimited requests." That's why Discover produces a written scope before anything is billed, and why each tier includes a defined number of revision rounds and a specific post-launch support window rather than an open-ended promise. If something genuinely new comes up mid-build, it becomes its own scoped conversation — not a silent expansion of the original one.
If you're trying to figure out which shape fits what you're building, the pricing page breaks down the three tiers, or you can just start with a call.