Three ways
to buy engineering.
Pick the shape that matches your constraint rather than the one that sounds most impressive. All three carry the same operating standard, the same review discipline, and the same named accountability — the commercial wrapper is the only thing that changes.
Project delivery
Defined scope, defined outcome
A bounded build with an agreed specification, milestone sequence, and handover. Best when the destination is clear and the path needs engineering.
Suits
- New platform builds
- Rebuilds and migrations
- Defined feature programmes
Fixed scope · milestone billing · documented handover
Embedded engineering
Our engineers, inside your team
Dedicated engineers and designers working in your stack, your standups, and your repository. Capacity without a hiring cycle, under our review discipline.
Suits
- Teams behind on roadmap
- Specialist gaps
- Sustained delivery pressure
Monthly · dedicated allocation · your process
Technology leadership
Fractional CTO and architecture authority
Senior technical judgement on retainer — architecture calls, delivery review, stack and hiring direction — without a full-time executive appointment.
Suits
- Funded teams pre-CTO
- Boards needing technical assurance
- Pre-build diligence
Retainer · fixed hours · decision records
The differences
that matter.
Everything below is negotiable except the operating standard. If a proposal you receive from us contradicts this table, the table is wrong and we will fix it.
Four inputs.
That is the ask.
You do not need a specification document or a technical vocabulary. You need to be clear about four things, and we will do the translation into architecture.
The constraint, stated
Deadline, budget ceiling, regulatory requirement, or the integration you cannot change. The real constraint shapes the architecture more than the feature list does.
Access to a decision maker
One person who can settle a scope question in a day. Engagements slow down over unanswered questions far more often than over hard engineering.
What already exists
Repository access, an architecture sketch, or an honest description of the spreadsheet holding it together. We would rather read the mess than a cleaned-up summary.
The definition of success
A number, a date, or a behaviour that changes. If nobody can state it, that is the first thing we work on together.
Accountability is assigned, not implied.
Every engagement has a named engagement lead accountable for scope, schedule, and quality, working to a documented governance model: weekly written reporting, a defined escalation path, formal change control, and senior technical review on every change before it reaches production.
A named engagement lead accountable end to end
Weekly written reporting and a defined escalation path
Formal change control and senior review on every change
Reviewed
No change reaches production without a second engineer reading it. This applies to our own ventures identically.
Reproducible
Environments defined as code. Any engineer can rebuild the stack from an empty account.
Observable
Logging, error reporting, and alerting configured before launch rather than after an incident.
Documented
Architecture notes, decision records, and runbooks handed over as deliverables, not favours.
Accessible
Semantic markup, keyboard paths, contrast ratios, and reduced-motion support treated as requirements.
Recoverable
Backups verified by restoring them. A backup nobody has restored is a rumour.
Not sure which model fits?
Describe the problem and we will tell you which shape we would recommend — including when the answer is that you do not need us yet.