How we work
What happens after you send the first email
The sequence from your first message to work starting, the two models we sell, and how both of them are paid for.
DAY 0
You send the problem
A paragraph is enough. The published commitment is a reply within 12 hours — including when the reply is that you should not hire us for this.
DAY 1–3
One call, with engineers on it
Sixty minutes with the people who would do the work. We come having read your repository if you have shared it, and we bring the questions that would change our estimate.
DAY 4–10
Written scope, and the estimate under it
You get the estimate, the assumptions it rests on, and the team shape and rate behind it. If it cannot be scoped in two weeks, we say that instead of quoting anyway.
OPTIONAL
A test project, if you want one
We would rather prove this on something small and real than argue it in a deck. A first paid piece of work, scoped to be genuinely useful on its own, is a normal way to start here and always has been.
ONGOING
Weekly, in writing
What shipped, what slipped, and what we got wrong — sent every Friday, whether or not you ask.
What you are actually buying
01
The first call is not with a salesperson
You will be on a call with the engineers who would do the work. If you hire us, the same names appear in the commit log.
02
Estimates come with their assumptions attached
Every number we give you arrives with what it assumes and what would change it. When an assumption breaks, you hear about it that week — not at the milestone review.
03
Your code is yours, and the policy predates you
Source code and property rights — the ones you bring and the ones written alongside us — are yours. That has been the written policy since before this site existed, and it applies to the code, the repositories and the accounts.
04
We tell you when we are the wrong shop
Some work belongs in-house, and some belongs with a specialist we do not employ. We will name which, and who to call instead.
AI writes some of it. A person is accountable for all of it.
AI-assisted development is the default across this industry now, ours included, and a vendor telling you they use it has told you nothing. What is worth putting in writing is what happens after the model produces something: where we let it near your work, where we do not, and whose name is on the result either way.
Where it is in the work
- Code generation and scaffolding
- Read and revised by the engineer whose name goes on the commit, before it is pushed anywhere you can see.
- Test scaffolding
- Checked against your acceptance criteria. A test generated by the same tool that generated the code proves nothing on its own, and we do not count it as coverage until someone has read it.
- Review support
- It flags. It does not approve. Nothing merges on a machine's opinion.
- Documentation and release notes
- Edited by a person before they reach you, for the ordinary reason that a confident description of behaviour the system does not have is worse than no description.
What it never does unsupervised
- Architecture and design decisions. Those are the judgement you are hiring, and they stay with the engineers you met.
- Anything that reaches production. Deployments are run by people who can be asked why.
- Final approval. On a repository we control, every merge carries a human sign-off from one of the engineers on your project. Where you own the pipeline we work to your rules — and if those rules would let unreviewed output through, you will hear it from us rather than discover it.
- Your code or your data inside a tool we have not named to you first.
- Tools in use
- Claude Code, Cursor
- Plans
- Commercial team plans
- Your code as training data
- No
- Vendor-side retention
- 30 days at most
- The tool list reaches you
- Before work starts
Who is accountable
One person owns this rather than a policy document: our Head of Engineering approves what goes on that list and answers for what it allows. If your security review wants that conversation directly, ask for it — you will get the person who sets the rules rather than an account manager reading this page back to you.
Those are the two tools, and they are on commercial plans rather than somebody's personal subscription — which is the specific reason the training row reads the way it does, because on the consumer tiers of the same products it would not. You get the full version in writing before work starts: what each tool is allowed to see, what it is never allowed near, and what each vendor retains. If your answer to any of this has to be an EU one, a third of our engineers are in Poland — worth raising in the first call rather than in the security review, because what that can and cannot staff is a real conversation and not a line for a website.
Two ways to work with us
These are the two collaboration models the company has sold since 2003, not a taxonomy invented for a website. The client counts below are the actual companies on the clients page.
Offshore Development Center
A standing, full-time team we hire, house and manage, working as an extension of your own development organisation. You take part in choosing the people; a senior engineer of ours runs the team day to day. No office or infrastructure for you to set up.
- Shape
- Dedicated team
- Clients on this model
- 15
- Payment
- Time and materials
- Best for
- Long-term product work
Custom software development
A project with a defined shape: requirements analysis, architecture, build, QA, delivery and maintenance. Priced hourly against a written estimate, with the assumptions under that estimate stated and reported against as the work runs.
- Shape
- Project, full cycle
- Clients on this model
- 4
- Payment
- Time and materials
- Best for
- Defined, boundable builds
And one way to pay for either
Time and materials
Hourly, against a written estimate with its assumptions attached. It does not require the whole project planned up front, it survives you changing your mind, and it is how every one of our clients works with us. On this model you see working output in days rather than at a milestone.
What we turn down
We do not run a bench you pay to keep warm
If an engineer is not needed, they come off the invoice that month.
We do not bid on scopes we cannot estimate
Some briefs are research, not delivery. We will say that and offer a paid discovery instead of an estimate we would have to defend later.
We do not send a different team than the one you met
The engineers on the pitch are the engineers on the project. If someone has to change, you hear the reason and you meet the replacement first.