The things people ask before they commit.

Are we locked in?

No, and it is worth being concrete about why. What you get is an ordinary code repository — no proprietary runtime, nothing hosted you cannot leave, no migration to negotiate. The delivery board — the same one we run on, not a client-facing copy — is yours from day one, and the delivery record travels with the code. If you stop working with us, you keep a system another team can pick up, including the reasoning behind every significant decision.

What actually happens if the AI produces something wrong?

It gets caught, or it does not ship. That is the entire purpose of the six checks — one of which samples and scores what the AI produced rather than assuming it. The last check asks whether a real person can finish the job on the running system, because that is the failure mode tests miss. We have had a fully green test suite over a broken product; that incident is why the sixth check exists, and we wrote it up.

Where does our code and data live?

Your code stays in your repositories, and we work in them under accounts you issue. Engineers work from copies on NamiQ machines, limited to the repositories you name, and the security page sets out exactly where that line sits, including which AI models may read your code. No real customer data is ever written into a delivered artifact, and that is enforced by one of the six checks rather than by a policy document. Our own commercial systems — the CRM behind this website — are self-hosted on our own hardware in Austin, Texas; see the privacy page for exactly what we keep about you and how to have it deleted.

How does pricing work?

Per engagement, sized to scope. We do not publish a range, because a range that turns out not to apply to you is worse than none — the engagements page instead lists the four things that move the figure, so you can size it yourself before talking to us. The first step — mapping one system and writing up what we found — is free.

Because delivery is metered per item, we can tell you what a change would cost to produce before you commit to it. That makes a scope conversation a question about value rather than about day rates.

Can you work on a system we already have?

That is the more common case, and the one the process was extended for. Pointed at a system nobody fully understands, the factory maps it and tells you what it could not account for — about ten minutes on a codebase the size ours was (165,000 lines), without overwriting a single existing document. A larger estate takes longer; that is the figure we have measured, not a promise about yours. Your prior work is input, not something we replace. We do not open with a rewrite proposal — a rewrite trades a system you do not understand for one that does not exist yet.

How small can a first engagement be?

One piece of work and read access to one system. The floor is that low on purpose: one change taken through all six checks shows you how we work and shows us what your codebase actually does, which a proposal document cannot do for either of us. It also means a bad fit costs you a week rather than a quarter.

Is a person actually involved?

Yes. A small team is accountable for it: a Technical Architect for what ships, and a Forward Deployed Engineer who is your named contact. 87% of the process runs unattended, which means 13% does not — and that 13% is the judgement: what to build, what to accept, what to stop. Work is assigned to a role with a defined scope and a definition of done, never to a general-purpose prompt.

Which AI models read our code?

Two kinds. Delivery uses models we run on our own hardware, and a hosted frontier coding model from a third-party provider. When a task runs on the hosted model, the parts of your source that task needs are sent to that provider. Before work starts you get, in writing, which models may read your code. If none of it may reach a third party, tell us first and we will say plainly whether we can deliver that way, and what it would change.

What is fixed before we pay?

For a stabilize engagement: the scope, the acceptance criteria each change has to meet, and the price, all in writing before any work starts. Monthly work is sized to scope, and the engagements page lists what moves that figure.

What if the person working on our system is unavailable?

The work does not live in anyone’s head, ours included. Every change is a ticket with its reasoning, every check result is recorded, and more than one person on our side knows your system. The record sits in your repository, so another team could pick it up too.

What will you not take on?

Work where the scope is genuinely unknown — that needs discovery first, and we will say so rather than bill for the ambiguity. A fixed scope where nobody on your side can agree what done means, because a scope without an owner drifts. And anything where the honest answer is that a simpler tool would do; sovereignty and process rigour have real costs and should not be paid for nothing.

Something not answered here? [email protected] — a person reads every one.