Software off the assembly line.
You describe the product intent in prose. Our AI assembly line turns it into tested software — planned, built, cross-reviewed and delivered as a pull request in your repo for approval. You do the merging.
From prose to a reviewed pull request.
A human describes what the product should do. That becomes a machine-readable contract — goals, bounds, acceptance criteria. The build runs in small steps through hard gates. Each critical step is reviewed by a different model before code is allowed to merge.
More than one reviewer — a relay.
Even before building, a deterministic code gate checks the plan contract — every building block must resolve its inputs and outputs cleanly: no orphans, no forward references, no LLM discretion. Where it's about correctness rather than judgment, the hard gate beats probability.
Every build step passes through several roles with a widening view: a quality scan, then multiple adversarial rounds across deliberately diverse models — from sibling models in one family to foreign providers to external cloud bots — and finally an integration architect. Cross-layer changes get a second architect pass on top.
Then the tests run. Every change is classified by type and blast radius (surface class) and dynamically takes the matching route through the pipeline: a small text change the short path, a security-critical one the long path with additional, staged review rounds. That model diversity is load-bearing, not decorative: different systems see different bugs.
Scales reliably, not just fast.
The factory runs several isolated production lines at once — unattended, but not uncontrolled: a compact status bus keeps the overview without a flood of logs, and a fail-closed reconcile lets only a real, reviewed result count as “done.” Failed runs are preserved and worked up — never silently discarded.
Friction becomes rules.
Every run leaves more than a product: friction becomes lessons, lessons become machine-readable operating rules that steer every following run. The rule base grows with every run, and the line gets better without the model having to change.
Decisions under dissent.
When the orchestrator loses confidence on an architecture or tactics call, it doesn't guess — coupled to its own confidence, it convenes a panel of independent models that votes; on a tie it escalates on its own. The effort scales with the stakes — from a quick cross-check to a broad, diverse round. Uncertainty isn't hidden, it's played out.
Diversity, with method.
Efficiency here isn't an after-the-fact savings drive — it's how the line is built. A good assembly line puts every resource exactly where it counts, and wastes no material.
The right model, not the priciest.
We deliberately use different models — each where it's strongest, by fitness rather than price tag. Grounded not in assumption but in thorough model evaluation per role and task.
Prompts on point.
Every role works from a precisely scoped instruction — exactly for its task, without context ballast. Clear instruction instead of dragged-along noise.
Steadily better.
Context and memory are refined continuously — quietly, in the background. Sometimes after hours, sometimes after days: cleaner handovers, less friction, more usable knowledge from the previous steps.
Four pillars that interlock.
Roles
The human owns concept, priority and direction; the machine owns disciplined execution.
Contracts
Product intent is translated into machine-readable specs — build and review share the same ground truth.
Gates
Plan, build, audit and merge run through fixed checkpoints with unambiguous pass criteria — evaluated deterministically, not by an AI's judgement.
Model diversity
No model reviews its own work: critical cross-checks run deliberately across providers and models.
Trust, made mechanical — not promised.
Your code is your capital. So we build trust into the production line itself, not into promises: every run is file-system-separated per customer, executes inside a network-tight cell, and ends in exactly one pull request that your team reviews and merges. What is mechanically enforced, we state; what is still missing, too.
Network-tight — and proven by a canary.
Every command and file access the agent makes runs inside a sealed cell with no network egress: a fresh network namespace, a cleared environment, read-only tools, no sensitive access paths mounted. The tightness is not a claim but proven — with a canary, a marked string that deliberately tries to break out and demonstrably arrives nowhere. The test is repeatable at any time.
One PR — your merge is the gate.
Inside the sealed build cell, commands and file access run with no network and no credentials — nothing there can write to your systems. The cell hands the finished diff to a separate, trusted closing step outside the sandbox. Only that step holds a token — one you issue, minimally scoped (your target repo only, branch + pull request only, expiring) — and uses it solely to push the branch and open one pull request. It cannot merge; that is your decision.
Sealed per customer — with an aborting guard.
Every run's state — build directory, logs, audit, credentials — sits under its own tenant root. Before each run, a mechanical guard checks that working copy, logs, audit and target all sit within the same customer area. On any cross-reference it aborts and logs the rejection.
Named honestly.
For the reasoning and model calls, code leaves the cell: code excerpts and task context go to Anthropic and OpenAI — never to your systems. That is the heart of the method, and we say so openly. Training is disabled on all provider accounts (an actively set, verifiable opt-out); retention we disclose transparently for the pilot.
One way of counting. Counted openly.
On the measured effort we put one fixed, openly stated factor — and add nothing on top: no second invoice for management or orchestration. Scoping, review rounds and release are inside that factor. The way we count is fixed before we start; the amount follows the measured effort.
How your price is set.
Your price comes from your project's verified build effort: measured by the actual token consumption per model, valued at current API prices, multiplied by a fixed factor — verified build effort × 3. You are buying a result; the consumption is how we measure it, not what you buy.
Security-critical auth migration
Self-service signup, email verification and password reset — including session invalidation on reset, rate-limited requests and mails in two languages.
~€1,400 · ~2 days
Payment-provider integration
Subscriptions, seat limits and webhooks on the payment-provider side; VAT ID reconciled against the tax country; booking and accounting exports through to checked billing.
~€3,300 · ~3 days
Bug fix with refactoring and test coverage
A clearly bounded fix that cleans up the cause instead of papering over it — tests included, through the same checkpoints as everything else.
~€280 · same day
From a conversation to a reviewed pull request.
You engage us on a clearly bounded task — one feature or refactor, commissioned individually and clearly signed off. After acceptance, you decide freely whether and how to continue.
Conversation
Together we clarify task, repo, target branch and your requirements — technical, security, legal.
Set the scope
One feature or refactor, clearly outlined, with an unambiguous acceptance definition.
We deliver
You receive a pull request on your target repo — a proposal for your review, not a finished result. And, on request, the audit of the authorization and rejection decisions (see below).
You decide
You review, merge and decide on continuation. What is still missing, we name openly.
Not just the outcome — the decisions too.
On request you receive the audit report for your tenant: which tasks a responsible person authorized and designated for the network-tight cell — and which were refused before the build, with the checkpoint in plain language, e.g. “target outside the approved scope” or “un-approved instruction file present in the workspace”. It is read strictly from your tenant area: a path leading out of it aborts the report rather than filling it.
And what this report is not, we say up front. It contains no reviewer prose — only a fixed whitelist of known fields is rendered, so nothing can fall out that is none of your business. It is a record of decisions, not a gapless ledger of events: that a task was authorized means it was authorized — not that everything afterwards ran through. And network tightness appears there as proof by construction (a route-less cell, verified by canary), not as a list of individual blocked connection attempts — that list is planned, and until it exists we do not claim it. What remains is what you read it for: it takes you to the places where something was refused, before you open the first line of the diff.
Your review time — named, not argued away.
The amount on the invoice measures our effort. Yours is not on it, and it is real nonetheless: someone on your team reads the pull request and owns the merge. We do not take that off your hands — your merge is the gate, and that is precisely the point.
What we do is keep the review small. The scope is tight: one feature or refactor, commissioned individually, with an unambiguous acceptance definition — no catch-all PR spanning three topics.
What we do not do: promise you a number of hours. We do not measure your review time and have no defensible figure for it; anyone who quotes you one here has made it up. Measure it yourself during the pilot — that is exactly why a pilot is small and commissioned on its own: you get your own number before you decide on more.
Let's work together.
You bring the product intent and the context, we bring the assembly line — and we cut the scope together. From a pilot through a complete product to an ongoing product partnership: close collaboration with industrial delivery logic, and the decision stays with you.