Three Ways to Buy Engineering. Pick the One That Fits.
A fixed-price project, a dedicated team by the month, or a fractional CTO. They differ in who carries the estimating risk, how scope changes are handled and what you commit to — and nothing stops you moving between them.
- Written update at the end of every working day
- Working demo build every two weeks
- You own the code and the accounts throughout
Start Here
Most clients begin with one of the first two. The third is for founders who need a technical opinion before they need code.
Fixed-Price Project
An agreed scope, an agreed number, and a written change process if the scope moves. Best when you can describe what needs to exist. If the build takes longer than we estimated, that is our problem, not your invoice.
How fixed price worksDedicated Team
Named engineers on a monthly basis, working your backlog in priority order. Best when the work is ongoing and the requirements keep changing as you learn from real users.
How a team worksFractional CTO
Architecture calls, oversight of other vendors, technical diligence before a raise, and hiring input. Best when you are non-technical and the decisions matter more than the keystrokes.
How a fractional CTO worksThe Differences That Actually Matter
Everything below is contractual, not aspirational. If a row here contradicts something a salesperson says, the row is right.
| Fixed-Price Project | Dedicated Team | Fractional CTO | |
|---|---|---|---|
| Who it suits | You can describe what needs to exist and why. A first version, a defined module, a rebuild of a known thing. | The roadmap is long and keeps changing. You want capacity, not a contract for one outcome. | You are non-technical, and the expensive mistakes ahead are decisions rather than code. |
| What you are buying | An outcome. A defined piece of working software for a defined number. | Capacity. Named engineers for an agreed number of days per month. | Judgement. A senior technical voice accountable to you, not to a vendor. |
| How billing works | Milestone payments against an agreed total. Typically a deposit, then payments at named milestones, with the balance on delivery. | A flat monthly invoice per person, billed in advance. No timesheets to argue about. | A monthly retainer for an agreed block of hours, usually between 10 and 40 per month. |
| If it takes longer than estimated | We absorb it. That is the whole point of fixed price, and it is why we scope carefully before quoting. | You decide what gets dropped or deferred. The monthly cost does not move. | Hours are the unit. If a question needs more than the block allows, we say so before starting. |
| How scope changes are handled | A written change request per change, with its own cost and schedule impact. Nothing starts until you approve it. | No change request process. Reprioritising the backlog is the normal way to work. | A conversation. You redirect the hours to whatever is most urgent that month. |
| Who directs the work | We do, against the signed scope. You approve at each milestone. | You set priorities; our lead runs the team day to day and protects the estimates. | You do. We advise, review, and tell you plainly when we disagree. |
| Minimum engagement | The project. Smallest sensible size is roughly four weeks of work. | Three months, then month to month with 30 days notice. | Three months, then month to month with 30 days notice. |
| Where it works badly | When requirements are genuinely unknown. Padding a guess helps nobody and the change requests become the project. | When you have no one to make product decisions. A team with no priorities produces expensive drift. | When you actually need hands on keyboards. Advice does not ship software. |
Indicative figures and ranges sit on the pricing page. The delivery mechanics — sprints, testing, releases — are the same in all three and are described in our process.
How You Will Hear From Us
Our delivery team is not based in the United States. Rather than dress that up, here is exactly what we commit to — and it applies to all three models.
End-of-day written update
At the close of every working day: what moved, what is blocked, what is next. It lands while your day is still running, so you read progress over morning coffee rather than chasing it.
Calls in your morning
Scheduled calls sit in the morning, US Eastern, at a fixed recurring slot agreed at kickoff. Weekly on active builds, monthly on lighter engagements, and extra ones whenever something needs a real conversation.
One business day to reply
Anything you raise gets a substantive reply within one business day — including a reply that says we do not know yet and here is when we will. Nothing sits unanswered while you wonder if it was received.
A demo build every two weeks
Not a slide deck or a screenshot. An installable build you can put on your own phone or open in your own browser, every second Friday, from the first sprint onwards.
What we deliberately do not claim is a live standup in your working hours. Plenty of agencies promise it and very few sustain it past month two. We would rather commit to four things we hit every week than to one thing that quietly stops happening.
Moving Between Models
The typical arc through a relationship with us, and how each transition is handled without a gap in delivery.
Usually it starts fixed price
A first version has a shape you can describe, and the thing you most want is a known budget. Fixed price answers that question and puts the overrun risk on us. Most engagements begin here, including ones that later become something else entirely.
Then reality arrives
Users do things nobody predicted. Priorities change monthly rather than quarterly. At this point every new piece of work needs its own quote and its own approval, which starts to cost more in overhead than it saves in certainty. That friction is the signal to move.
It becomes a team or a retainer
Ongoing improvement suits a dedicated team; keeping a stable product healthy suits a maintenance retainer. Both are monthly, both are cancellable, and both remove the quote-per-change overhead entirely.
Transitions happen at clean boundaries
We switch at a completed milestone or the end of a calendar month, never mid-task. Whatever is in flight is finished and documented first, the remaining backlog is written down, and the new arrangement starts from a known position rather than an argument about what was included.
Or it ends, cleanly
You hire in-house, or the product simply does not need us any more. Everything is already in your accounts, so the handover is documentation and a walkthrough rather than a negotiation. We would rather be a good reference than a hostage-taker — see ownership and IP.
What Does Not Change, Whichever Model You Pick
Ownership and access
- Repositories, cloud accounts and store listings are in your name from day one
- You have full access to the code throughout, not at the end
- Intellectual property transfers to you, and a mutual NDA is available before any detailed discussion
- Credentials and documentation are handed over whenever you ask, not only on exit
How the work is actually done
- Two-week sprints with a working build at the end of each one
- Code review on every change before it reaches your main branch
- Automated deployment, so releases are routine rather than events
- Architecture chosen for where the product is going, not only for where it is today
- The same senior people who scoped the work stay attached to it
Questions About Working Together
Which engagement model should we start with?
If you can describe what needs to exist and roughly why, start with a fixed-price project, because that puts the estimating risk on us rather than you. If the requirements will keep moving because you are learning from real users, a dedicated team costs less than renegotiating a fixed scope every few weeks. If the real problem is that nobody technical is helping you decide anything, start with a fractional CTO and choose a build model afterwards.
Can we switch models partway through?
Yes, and most long relationships do. The usual path is a fixed-price first version, then a retainer or a dedicated team once there are users and the roadmap starts reacting to them. We switch at a clean boundary, meaning a completed milestone or the end of a calendar month, with the current work closed out and documented before the new arrangement starts.
Can we run more than one model at the same time?
Yes. A common arrangement is a dedicated team working through the roadmap while a separate fixed-price contract covers one large, well-defined piece such as a payments integration or an accessibility pass. We keep the two budgets and the two reports separate so it stays obvious what each one is delivering.
How are scope changes handled in each model?
On a fixed-price project every change is written up as a change request with its own cost and schedule impact, and nothing begins until you approve it in writing. On a dedicated team there is no change request process at all, because reprioritising the backlog is simply how the model works and you decide what the team picks up next. With a fractional CTO the engagement is a monthly block of hours, so changing what those hours are spent on is a conversation, not a contract amendment.
How much visibility do we get into progress?
A written update at the end of every working day, a demo build you can install and use every two weeks, and direct access to the repository and the task board throughout. You should never have to ask what happened this week, and if a week went badly the update says so on the day rather than at the end of the month.
Does your team work in our time zone?
Our delivery team is not based in the United States, and we would rather say that plainly than imply otherwise. What we commit to is a written update at the end of every working day, calls scheduled in your morning US Eastern, a reply to anything you raise within one business day, and a working demo build every two weeks. In practice you are rarely waiting more than one overnight for an answer.
Not Sure Which One You Need?
Describe the situation in a few sentences. We will tell you which model fits — including when the honest answer is none of them yet.