Naar inhoud
TwentyOne
Start je Proof Sprint

Twenty+One / Veelgestelde vragen

Veelgestelde vragen

Voor wie is dit?

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.

Hoe verschilt dit van Lovable, Bolt of andere AI-builders?

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.

Wat is een story point hier precies, en waarom zou ik jullie schattingen vertrouwen?

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.

Van wie is de software?

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.

Mijn team, of mijn softwarebureau, levert niet. Kunnen jullie een bestaande build overnemen?

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.

We hebben al een devteam. Is dit dan nog voor ons?

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.

Hoe zit het met modelafhankelijkheid, rate limits en tokenkosten?

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.

Maakt het uit vanuit welke assistent ik verbind (Claude, ChatGPT, Gemini) voor hoe mijn software wordt gebouwd?

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.

We kunnen onze codebase niet delen. Is dat een probleem?

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.

Is door AI gebouwde software veilig voor enterprisegebruik?

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.

Wat gebeurt er na de launch?

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.

En als we ooit weg willen?

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.

Jullie geven me één menselijke Build Lead; ben ik dan niet van diegene afhankelijk?

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.

Als de agents alle context dragen, wat doet de Build Lead dan eigenlijk?

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.

Wij nemen goede mensen aan. Waarom is niet van ze afhangen een voordeel?

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.

Wat als er iets kapotgaat nadat ik geaccepteerd en betaald heb?

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.

Ik heb iets met AI gebouwd en nu gaat het kapot, en zelfs AI krijgt het niet gerepareerd. Kunnen jullie dat?

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.

Start je Proof Sprint