How we take on work

Engagements start with a conversation about the problem rather than the feature list. Most initial scopes contain a good deal that can be removed without anyone noticing, and finding that before estimating is the cheapest saving available on any project.

We give ranges rather than single numbers, and the range widens with uncertainty. A confident figure against an undefined scope is a guess wearing a suit. Where a brief is genuinely too vague to price honestly, we will propose a short paid discovery and produce a real estimate from it.

Who we are a poor fit for

Large programmes needing a dozen people working in parallel — there is no bench here to allocate. Staff augmentation, where you want additional hands under your own technical direction rather than judgement. And projects that are primarily a brand and visual identity exercise, which somebody else should lead.

We would rather say this in the first exchange than discover it in month three. Declining a poor fit costs both sides far less than a project that quietly goes wrong.

What you own at the end

The source, in your repository. A build pipeline that runs without us. Store listings and cloud accounts in your name. Signing keys in your custody. Documentation written for a developer who has never seen the project.

We would prefer to stay on for maintenance, because software needs OS upgrades and policy changes long after launch. But a client who cannot leave is not a client, and it produces worse work.