FAQVeelgestelde vragen

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.Product owners die hun ambitie niet laten begrenzen door devcapaciteit. Bestuurders wier team, of softwarebureau, niet levert. Founders die liever een devteam kopen dan er een bouwen. Product owners die klaar zijn met wachtrijen van een kwartaal. Kun je een roadmap bezitten, dan kun je dit runnen, en kun je dat nog niet, dan matchen we je met een productpartner die je helpt hem te bezitten. Wat we nooit doen: de roadmap van je overnemen.

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.We zijn dol op die tools; ze bewezen dat iedereen software tevoorschijn kan toveren. Maar ze geven je een prototype en houden geen enkele verantwoordelijkheid. Wij leveren production-grade software met een mens met een naam die ervoor instaat, op infrastructuur gebouwd voor echte operaties. Het verschil zit niet in de interface. Het zit in wat eruit komt, en wie ervoor instaat.

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.Terechte vraag: het is de eerste die je moet stellen. Onze sizing-rubric is openbaar: hoe een 1, 3, 5 en 8 eruitzien, met echte voorbeelden. Elke schatting komt met de redenering erbij, en jij accepteert hem vóór de sprint start. Geaccepteerd werk wordt gefactureerd; afgekeurd werk wordt herwerkt op onze kosten.

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.Van jou; helemaal, vanaf de eerste geaccepteerde story. Elke story die je accepteert wordt van jou op het moment dat je hem accepteert: de code, de documentatie, de data. Eigendom is hier geen clausule aan het einde van een contract; het is hoe de facturering werkt: je betaalt per geaccepteerde story, en waarvoor je betaald hebt is van jou, sprint na sprint. Wat van ons blijft is de fabriek: het platform, de agents, de gates. Niets wat jouw systeem nodig heeft om te draaien staat aan onze kant van de lijn.

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.Ja. We beoordelen wat er ligt, vertellen je eerlijk wat je moet houden en wat je moet herbouwen, en krijgen je weer aan het shippen; meestal binnen één 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.Ja; als crew naast je team, niet in plaats van je team. Jouw engineers blijven op het kernproduct; jouw crew pakt de workstreams waar zij nooit aan toekomen: de tweede productlijn, de migratie die niemand wil, interne tooling, overloop. Je team houdt volledig zicht, en je CTO is welkom in de keuken: we nemen je technisch leiderschap precies mee door hoe het platform werkt, gates en al. Wij zijn niet het alternatief voor je devteam. Wij zijn het alternatief voor een devteam dat een jaar kwijt is aan zelf een AI-platformteam worden.

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.Die zie je nooit. Je betaalt per geaccepteerd story point: er is geen tokenregel op de factuur, geen verbruiksmeter, geen verrassingsrekening als een build complex wordt. Onder de motorkap is de delivery-engine model-agnostisch: agents routeren elke taak in realtime naar het beste model voor de klus, op kwaliteit en kosten, dus geen enkele AI-leverancier is met prijs, snelheid of limieten een afhankelijkheid. Tokens zijn ons probleem om te optimaliseren. Jij koopt de 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.Nee, die twee staan volledig los van elkaar. De assistent is alleen jouw venster op het project: waar je stories schrijft en met je crew praat. Welke modellen jouw software bouwen wordt binnen de delivery-engine bepaald, taak voor taak, en verandert niet door hoe jij verbindt. Kies de assistent die je team al gebruikt.

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.Nee: de meeste trajecten beginnen daar niet. Jouw crew kan greenfield bouwen naast je kernproduct, geïntegreerd via API's, zonder enige code te delen. Als diepere toegang ooit zinvol wordt, is die gescoped tot één bounded context tegelijk, gelogd en intrekbaar, en alles draait op je eigen single-tenant instance: dedicated agents, dedicated infrastructuur, niets gedeeld met een andere klant. Alles wat we shippen is van jou, zonder training op jouw code en met een exit zonder lock-in: stap op elk moment op, met alle code en onderhoudbare documentatie.

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.Niets shipt zonder de security-, test- en kwaliteitsgates te passeren: hetzelfde proces, elke keer, geen heldendaad per project. Je Build Lead tekent af op elke release. Snelheid komt uit het proces, niet uit bochten afsnijden.

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.De meeste klanten houden hun team: een maandelijkse sprintcadans met een gecommitteerde story point-bodem, dezelfde snelheid, dezelfde Build Lead. Je product blijft zo snel bewegen als je markt.

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.Dan ga je, met alles. Geen lock-in is een standaardvoorwaarde, geen onderhandeling: alle code in jouw repositories, draaiende software die ons platform niet nodig heeft om te werken; het platform is hoe je software gebouwd wordt, nooit wat hij nodig heeft om te draaien. We kunnen deployen in jouw bestaande omgeving en integreren met de systemen die je al draait, dus voor veel klanten is er bij vertrek niets te migreren: de software woont al waar hij hoort. En de documentatie is zo geschreven dat een team dat ons nooit heeft ontmoet hem kan oppakken en onderhouden. Dat laatste is geen belofte die we er bij vertrek aan vastschroeven: er is altijd een mens die jouw systeem begrijpt, en alles wat je agents weten is gedocumenteerd by construction, precies wat de exitclausule echt maakt. Simpel gezegd: de reden dat je weg kunt is de reden dat het nooit hoeft. We worden elke sprint opnieuw gekozen, dat is de 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.Van de rol, ja. Van de persoon, nee, en dat is bewust zo geëngineerd. Je twintig-plus agents dragen de volledige context van je product: de architectuur en waarom die zo is, wat is afgewezen en waarom, voor welke edge case die ene workaround bestaat, elke beslissing sinds sprint één. Dat is dezelfde reden dat sprint 20 net zo snel shipt als sprint 1, en waarom een wissel van Build Lead jou niets kost. Een nieuwe stapt binnen in een systeem dat al volledig beschreven is, en pakt de pen op. Het is een overdracht, geen herstart: geen herontdekking, geen inwerktijd, geen factuur voor allebei. Vergelijk dat met de dag dat ergens anders een sleutel-engineer opstapt, en het eerste slachtoffer alles is wat die nooit heeft opgeschreven.

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.De twee dingen die niet in een agent kunnen wonen: verantwoordelijkheid en het eindoordeel. Je Build Lead tekent elke release, zegt nee als iets niet klaar is, en staat ervoor als het maandagochtend om 9 uur kapotgaat. De agents dragen de kennis; precies waarom het voor jou nooit uitmaakt welke Build Lead je hebt. Maar verantwoordelijkheid kun je niet aan een agent overdragen, en geen enkele modelrelease verandert dat; daarom is de stoel nooit leeg. Je Build Lead is vervangbaar. Er één hebben niet, en als we de mens ooit zouden weghalen, koop je weer een tool, met niemand die ervoor instaat.

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.Omdat goede mensen een goede uitkomst zijn, geen betrouwbare input. Je kunt je niet naar een garantie toe werven: de markt waarin je werft is dun, de vaardigheden die er nu toe doen zijn achttien maanden oud, en de persoon die jouw roadmap laat werken kan opzeggen. We zeggen niet dat engineers er niet toe doen; we zeggen dat je product geen weddenschap op de arbeidsmarkt zou moeten zijn. Hier wordt de standaard afgedwongen door gates die niet variëren met wie er die dag werkt, en het bijhouden van de AI-stack is onze vaste baan, geen vaardigheid die jij telkens opnieuw moet inkopen. Dezelfde output, elke sprint, wie er ook aan het stuur zit.

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.Defecten in geaccepteerd werk worden op onze kosten gerepareerd. Punt. Acceptatie draagt het eigendom van de waarde aan jou over: niet het eigendom van onze fouten. Voor live producten op een Continuous-plan horen incident-responstijden bij je tier. Dit is het verschil tussen een tool en een team: een tool kan nergens garantie op geven.

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.Ja; dit is de dead loop, en we zien hem wekelijks. Het probleem is niet het model; het is dat de codebase groeide zonder architectuur, tests, docs of iemand die hem begrijpt. Week één van een Proof Sprint geeft je een eerlijke beoordeling: wat houden, wat redden, wat herbouwen, en met onze economie is herbouwen vaak goedkoper dan archeologie. Hoe dan ook eindig je met een systeem dat een mens met een naam begrijpt, en dat blijft zo.