FAQ

Product owners who won't let dev capacity gate their ambition. Execs whose team, or software agency, isn't delivering. Founders who'd rather buy a dev team than build one. Product owners tired of quarter-long queues. If you can own a roadmap, you can run this, and if you can't yet, we'll match you with a product partner who helps you own it. What we'll never do is take the roadmap from you.

We love those tools; they proved anyone can conjure software. But they hand you a prototype and keep none of the responsibility. We deliver production-grade software with a named human accountable for it, on infrastructure built for real operations. The difference isn't the interface. It's what comes out, and who answers for it.

Fair question; it's the first one to ask. Our sizing rubric is public: what a 1, 3, 5, and 8 look like, with real examples. Every estimate comes with the reasoning shown, and you accept it before the sprint starts. Accepted work is billed; rejected work is reworked at our cost.

You do; all of it, from the first accepted story. Every story you accept becomes yours the moment you accept it: the code, the documentation, the data. Ownership isn't a clause at the end of a contract here; it's how the billing works: you pay per accepted story, and what you've paid for is yours, sprint by sprint. What stays ours is the factory: the platform, the agents, the gates. Nothing your system needs to run is on our side of the line.

Yes. We assess what exists, tell you honestly what to keep and what to rebuild, and get you shipping again; usually within one Proof Sprint.

Yes; as a crew alongside them, not instead of them. Your engineers stay on the core product; your crew takes the workstreams they never reach: the second product line, the migration nobody wants, internal tooling, overflow. Your team keeps full visibility, and your CTO is welcome in the kitchen: we'll walk your technical leadership through exactly how the platform works, gates and all. We're not the alternative to your dev team. We're the alternative to your dev team spending a year becoming an AI platform team.

You'll never see them. You pay per accepted story point: there is no token line item, no usage meter, no surprise bill when a build gets complex. Under the hood, the delivery engine is model-agnostic: agents route each task to the best model for the job on quality and cost, in real time, so no single AI vendor's pricing, speed, or limits is a dependency. Tokens are our problem to optimize. You buy the output.

No: the two are completely separate. The assistant is just your window into the project: where you write stories and talk to your crew. Which models build your software is decided inside the delivery engine, task by task, and doesn't change based on how you connect. Pick whichever assistant your team already uses.

No; most engagements don't start there. Your crew can build greenfield alongside your core product, integrating through APIs, with zero code sharing. If and when deeper access makes sense, it's scoped to one bounded context at a time, logged, and revocable, and everything runs on your own single-tenant instance: dedicated agents, dedicated infrastructure, nothing shared with another client. Everything we ship is yours, with no training on your code and a no-lock-in exit: leave anytime with all code and maintainable documentation.

Nothing ships without passing security, testing, and quality gates: the same process every time, not a per-project heroic effort. Your Build Lead signs off on every release. Speed comes from the process, not from cutting corners.

Most clients keep their team: a monthly sprint cadence with a committed story-point floor, same speed, same Build Lead. Your product keeps moving as fast as your market does.

Then you leave, with everything. No lock-in is a standard term, not a negotiation: all code in your repositories, running software that doesn't need our platform to operate; the platform is how your software gets built, never what it needs to run. We can deploy into your existing environment and integrate with the systems you already run, so for many clients there's nothing to migrate at exit: the software is already living where it belongs. And the documentation is written so a team that has never met us can pick it up and maintain it. That last part isn't a promise we bolt on at exit: there is always a human who understands your system, and everything your agents know is documented by construction, which is exactly what makes the exit clause real. Put plainly: the reason you can leave is the reason you'll never need to. We're re-chosen every sprint, that's the deal.

On the role, yes. On the person, no, and that's a deliberate piece of engineering. Your twenty-plus agents hold the full context of your product: the architecture and why it went that way, what was rejected and why, which edge case that one workaround exists for, every decision since sprint one. That's the same reason sprint 20 ships as fast as sprint 1, and it's why a Build Lead change costs you nothing. A new one arrives to a system that's already fully described, and picks up the pen. It's a handover, not a restart: no re-discovery, no ramp-up, no invoice for either. Compare that to the day a key engineer resigns anywhere else, when the first casualty is everything they never wrote down.

The two things that can't live in an agent: accountability and final judgment. Your Build Lead signs every release, says no when something isn't ready, and answers when it breaks at 9am on a Monday. The agents hold the knowledge, which is exactly why which Build Lead you have never matters to you. But accountability can't be handed to an agent, and no model release changes that, which is why the seat is never empty. Your Build Lead is replaceable. Having one is not, and if we ever removed the human, you'd be buying a tool again, with nobody to answer for it.

Because good people are a good outcome, not a reliable input. You can't hire your way to a guarantee: the market you hire in is thin, the skills that matter now are eighteen months old, and the person who makes your roadmap work can resign. We're not saying engineers don't matter; we're saying your product shouldn't be a bet on the hiring market. Here, the standard is enforced by gates that don't vary with who's on shift, and keeping up with the AI stack is our permanent job, not a skill you have to keep sourcing. Same output, every sprint, whoever is at the wheel.

Defects in accepted work are fixed at our cost. Full stop. Acceptance transfers ownership of the value to you: not ownership of our mistakes. For live products on a Continuous plan, incident response times are part of your tier. This is the difference between a tool and a team: a tool can't warranty anything.

Yes; this is the dead loop, and we see it weekly. The problem isn't the model; it's that the codebase grew without architecture, tests, docs, or anyone who understands it. Week one of a Proof Sprint gives you an honest assessment: what to keep, what to salvage, what to rebuild, and with our economics, rebuilding is often cheaper than archaeology. Either way, you end up with a system a named human understands, and it stays that way.