Approach

How a build actually runs, and what it costs you to find out.

No discovery phase that bills for a quarter and produces a deck. A scoping conversation, a written plan, and working software you can open in a browser long before the end.

The four steps
01

Frame the problem

We start with the business outcome, not the feature list. Most briefs contain one requirement doing all the work and six that can wait.

02

Build the spine

Auth, tenancy, data model and deployment go in first. The unglamorous foundation is what decides whether month six is pleasant or painful.

03

Ship depth-first

One module finished completely — including its long tail of edge cases — before the next one opens. Half-built modules are how products die.

04

Put it in front of users

Real deployment, real accounts, real payments. Demos prove nothing; a customer completing a transaction proves everything.

Engagement models

Three ways to work with us.

Product build

Fixed scope

A defined thing, built and delivered.

  • Scoping pass with a written build plan before anything is quoted
  • Depth-first delivery — one module finished before the next opens
  • Deployed to your infrastructure, in your accounts, from week one
  • Handover with runbooks written for someone who was not in the room

Best for
A new product, a replacement for something failing, or a module your team has no appetite for.

Ongoing build

Monthly

A team that keeps shipping after launch.

  • Continuous delivery against a roadmap you set
  • We operate what we build, including the parts that page at night
  • Priorities re-cut every cycle rather than fixed a year ahead
  • Stop whenever it stops being worth it — no exit fee, no lock-in

Best for
A live product with a backlog longer than the team, where the work is not going to end.

Rescue & modernization

Audit first

Something exists. It is not working.

  • Audit first: what earns its keep, what does not, what a rewrite really costs
  • Migration with reconciliation reports, not optimism
  • Incremental cutover so the business keeps running throughout
  • We will tell you when the answer is to keep what you have

Best for
A legacy platform, a stalled rebuild, or a system whose original authors have left.

Questions

The things people ask first.

If yours is not here, ask it directly — we would rather answer than have you guess.

Fixed price for a defined scope, or a monthly rate for an ongoing build. We quote after a scoping conversation, not before — a number produced without understanding the problem is a guess, and guesses get corrected upward later.

You do, entirely, including while the work is in progress. It lives in your repository under your account from the first commit. There is no license, no escrow arrangement and nothing to buy out if you want to take it elsewhere.

A focused product with a real user in front of it: weeks, not quarters. A platform with tenancy, billing, permissions and a migration: months. We would rather give you a short honest range after scoping than a long optimistic one before.

Yes, and it is often the better arrangement. We take the parts your team has not done before — the AI layer, the tenancy model, the billing spine — and hand them over with the reasoning written down, so nobody is dependent on us afterwards.

Most of our work touches something that already exists. We start with an audit of what earns its keep, and we are direct when the answer is that a rewrite costs more than it returns. Incremental cutover keeps the business running while things change underneath it.

We pick the stack the problem deserves rather than the one we prefer. In practice we reach most often for React, TypeScript, Cloudflare Workers, Postgres and Anthropic models, and we have run Kubernetes, Azure, Python and Salesforce in production when that was the right answer.

Fair question, and worth asking anyone who claims otherwise. Ours reads construction drawings into priced quantities and retrieves over customer document corpora. We are equally willing to tell you when a feature you are asking for does not need a model at all.

We operate our own products, so we assume software needs owners rather than a handover ceremony. You can retain us for ongoing work, or take it in-house with documentation and runbooks written for someone who was not in the room.

Yes, before anything substantive is discussed if you prefer.

Send a description of the outcome you need through the contact form. We reply within a business day, usually with questions. If it is not a fit we will say so quickly and, where we can, point you at someone better suited.