← Blog

AI agents

Stack-scorecard voor bureaus: agent fleet vs Next.js vs Retool

Drie klantbriefs op de keukentafel, zes devs, een junior die in maand 2 begint. Een drie-assen methode om de stack per project te kiezen, niet per bureau.

Jacob Molkenboer· Oprichter · A Brand New Company· 14 jan 2026· 6 min
Houten telefoonschakelbord met messing patchkabels, één groen snoer, gevouwen brief, inktgrootboek, rode lakzegel op ivoorpapier.

Het is een donderdagavond in mei. Je runt een bureau in Utrecht: zes devs, €4,2M omzet trailing twelve. Drie klantbriefs liggen op je keukentafel. Een 3PL wil een invoice-chaser. Een aannemer wil een intern portaal dat met AFAS praat. Een private-label merk wil hun marketing-ops opnieuw opgebouwd hebben, omdat hun huidige Zapier-graaf 137 zaps telt en niemand het meer kan uitleggen. Alle drie moeten vóór Q4 live. Twee devs zijn met vakantie in week 3. De junior begint in maand 2. En jij moet vanavond beslissen waarop elk project gebouwd wordt.

Sinds de laatste ronde HN-threads die “AI-native” als default voor nieuwe builds neerzet, vraagt de helft van je inbox of ze alles met een Claude Code-fleet moeten doen. De andere helft zit nog op Retool-bouwt-alles. Geen van beide zienswijzen is fout. Allebei zijn waardeloos zonder methode.

Dit is de methode die wij bij ABN gebruiken om de stack per project te kiezen, niet per bureau. Ze komt voort uit veertien agents in productie en een handvol reddingen bij teams die de verkeerde stack op de verkeerde brief hadden geleverd.

De drie eerlijke beschrijvingen

Strip de marketing eraf. Een Claude Code agent-fleet is een Git-repo vol met agent-specs, een dispatcher, een tools-laag (jouw API's, jouw DB, jouw filesystem) en een orchestrator. De agent doet werk dat mensen vroeger deden: triage, chasen, classificeren, drafts schrijven. Hij loopt. Hij roept tools aan. Hij schrijft terug. De Claude Code-docs van Anthropic beschrijven de runtime, maar het operationele model bedenk je zelf. Goedkoop om te starten. Duur om om 23:00 op vrijdag te debuggen.

Een handgebouwde Next.js + Postgres-app is wat je devs al kennen. App Router, Drizzle of Prisma, Postgres op Neon of Supabase, een queue als je er een nodig hebt, deploy op Vercel of Fly. Deterministisch. Saai. Je bezit elke regel. De bus factor matcht je headcount.

Een Retool-on-steroids opzet betekent een internal-tool platform (Retool, Budibase, ToolJet) als front, jouw API's en DB als back, met een workflow-runner ernaast. Closed-source UI, semi-open lijm. Goedkoop per scherm, duur per verrassing. De Retool-docs zijn eerlijk over waar het platform ophoudt en code begint.

Alle drie kunnen dezelfde brief leveren. De verkeerde eet je marge op.

De drie assen die de keuze maken

We scoren elk project op dezelfde drie getallen. Elk is een 1–10. Elk komt uit een concrete vraag, niet uit een gevoel.

Marge per project over zes devs

Niet “is het goedkoop om te bouwen.” De juiste vraag is: hoeveel van onze zes devs kunnen in week 2 zelfstandig een feature leveren in deze stack, zonder dat een senior ernaast zit? Zes van de zes is een 10. Eén van de zes (jouw enige senior) is een 1. Stacks waarin alleen je beste dev kan leveren, worden stilletjes gesubsidieerd door het salaris van die dev op elk ander project dat hij niet aanraakt. Daar lekt je marge weg zonder dat je het ziet.

Klant-handover verdedigbaarheid

De brief: een junior vertrekt in maand 4. Zijn vervanger begint in maand 5. Kan die vervanger in zijn eerste sprint het systeem uitbreiden zonder dat je senior erbij hoeft te zitten? Een 10 betekent ja, met publieke docs. Een 1 betekent dat het systeem eigen tribale patronen en ongeschreven orchestratie-regels heeft. Dit is de as waarop agent-fleets stil punten verliezen, tenzij je een eigen runbook-laag hebt geschreven. Het framework is nog jong genoeg dat er geen Stack Overflow is waar je een junior naartoe stuurt.

Runbook-eigenaarschap op een vrijdagmiddag

Het is 16:45 op een vrijdag. De agent loopt. Hij heeft send_invoice zeven keer naar dezelfde debiteur aangeroepen. De klant belt. Wie neemt de telefoon op, wie heeft de kill switch, wie leest de logs? Als het antwoord “we zien wel” is, gaat het project niet live op die stack. Score 1. Als het antwoord één benoemd persoon is met een vastgepind runbook, een geteste kill switch en een bekende SLA: score 10. Deze as is niet onderhandelbaar voor elke stack die autonoom draait tussen deploys door — en dat doen zowel de agent-fleet als de Retool-workflow optie.

Let op

Als je vóór de start van het project geen runbook-eigenaar kunt noemen, maakt de stack niet uit. Het project faalt op elke stack even hard.

Het scoreblad

We bewaren dit in een YAML-bestand in onze intake-repo. Eén bestand per project, één minuut per as, drie minuten naar een besluit. De gewichten zijn niet gelijk. Marge is het luidste getal. Verdedigbaarheid is een belasting die zich over jaren opstapelt. Runbook-eigenaarschap is een gate, geen score.

# intake/scorecard.yaml
project: logistics-invoice-chaser
client: 3pl-rotterdam
deadline: 2026-09-30

axes:
  marge_across_6_devs:
    next_js: 8       # whole team ships
    agent_fleet: 5   # one senior + one mid
    retool: 9        # any dev, any junior
    weight: 0.5

  klant_handover_defensibility:
    next_js: 8       # standard stack, public docs
    agent_fleet: 4   # tribal, no junior pipeline
    retool: 6        # vendor-locked UI
    weight: 0.3

  runbook_ownership:
    next_js: pass    # deterministic, no autonomy
    agent_fleet: BLOCKED  # no named owner yet
    retool: pass     # human-in-the-loop
    weight: gate

decision:
  formula: 0.5*marge + 0.3*defensibility, gate on runbook
  next_js: 0.5*8 + 0.3*8 = 6.4
  agent_fleet: BLOCKED
  retool: 0.5*9 + 0.3*6 = 6.3
verdict: next_js   # marge edge, no autonomy needed for v1

De formule is minder belangrijk dan de gate. Bijna elke ramp die we hebben opgeruimd, was een agent-fleet die live ging zonder benoemde runbook-eigenaar. De kill switch bestond in slides. Hij bestond niet in productie. Tegen de tijd dat iemand de loop-logs las, was de derde factuur al in de inbox van de debiteur van de klant beland en stond de relatie in de fik.

Hoe de drie briefs scoorden

Run het blad tegen de briefs van de keukentafel.

De 3PL invoice-chaser ziet eruit als een poster child voor een agent-fleet, en op Reddit zou hij zo gebouwd worden. Op de scorecard zakte hij op de runbook-gate. Zes devs, geen benoemde ops-lead, geen kill-switch-infra, geen SLA-gesprek met de klant. We hebben het geleverd als Next.js + Postgres, met een “draft, mens keurt goed, verstuur”-loop. Saai. Marge bleef staan. We hebben de agent-laag in v2 toegevoegd, toen de ops-handoff echt was.

Het aannemersportaal met AFAS kreeg Retool. Vijf interne gebruikers, twintig schermen, geen autonomie, het IT-team van de klant gebruikte zelf al Retool. Verdedigbaarheid scoorde 9, omdat de klant het zelf kon onderhouden. Marge scoorde 9, omdat twee van onze juniors het leeuwendeel bouwden. De AFAS-adapter ging in een kleine Next.js-sidecar onder ons onderhoudscontract, want dat is de enige naad waar Retool ophoudt eerlijk te zijn over zichzelf.

De marketing-ops-rebuild kreeg de agent-fleet, maar alleen omdat we een benoemde runbook-eigenaar aan klantzijde hebben onderhandeld, een kleine premie hebben gerekend voor een 24/5 on-call rotatie, en de Zapier-vervanging hebben geleverd als een Claude Code-orchestrator met harde limieten op tool calls per uur. Het runbook leeft in hun Notion, eigendom van hun head of growth, met een kill-switch endpoint dat de agent uitzet en een Slack-page triggert.

Waar de methode stopt

De scorecard is eerlijk over wat ze niet kan beprijzen. Ze beprijst geen klantprestige (sommige projecten lever je op dunne marge om het logo). Ze beprijst geen teamhonger — als je drie beste devs opstappen wanneer je nóg een Retool levert, scoor dát. Ze beprijst geen strategisch leren. Agent-fleets zijn in 2026 nog steeds een moat-bouwer voor een bureau dat vooruit op de markt wil hiren, en een verlies van 0,4 punt op marge kan dat oefenen waard zijn.

Wat de methode wél doet, is het gesprek eerlijk houden. Je mag het oneens zijn met de score, maar je moet het oneens zijn met een getal, niet met een gevoel.

Als je vandaag één ding doet: draai de drie-assen check op het project dat het dichtst bij de start zit. Open een YAML-bestand. Scoor de drie stacks op marge, verdedigbaarheid en runbook. Zie welke geblokkeerd is. Toen we de marketing-ops-agent voor dat private-label merk bouwden, was de runbook-gate het ding dat we bijna gemist hadden; we hebben het opgelost door het kill-switch endpoint in het klantcontract op te nemen vóór de kickoff. Aan dat soort leidingwerk werken wij als AI-agents voor bureaus onder €8M en hun klanten.

Kern

Kies de stack per project, niet per bureau: scoor elke brief op marge over zes devs, junior-handover verdedigbaarheid, en wie eigenaar is van het runbook op vrijdagmiddag.

FAQ

Waarom scoren per project in plaats van het bureau standaardiseren op één stack?

Omdat de drie assen per brief verschuiven. Een portaal zonder autonomie en een Retool-bekwame klant is een andere rekensom dan een autonome invoice-chaser zonder benoemde ops-eigenaar.

Waarom is runbook-eigenaarschap een gate en geen gewogen score?

Omdat een autonoom systeem zonder benoemde eigenaar niet netjes faalt. Het faalt op een vrijdagmiddag en brandt een klantrelatie op. Een gate dwingt dat gesprek af vóór de kickoff.

Waar winnen agent-fleets daadwerkelijk op de scorecard?

Op projecten met een benoemde runbook-eigenaar aan klantzijde, een echt ops-budget, en werk dat mensen nu op schaal doen. De marge-upside laat zich zien in v2, zodra de orchestratielaag hergebruikt wordt.

Werkt de scorecard ook voor solo-founders of alleen voor bureaus met zes devs?

Hij schaalt naar beneden. Vervang de marge-as door uren-per-week-die-je-aan-onderhoud-kunt-besteden. De verdedigbaarheid- en runbook-as blijven hetzelfde; allebei bijten ze een solo-founder net zo hard, vaak harder.

ai agentsautomationstrategyarchitectureoperationsbusiness

Iets bouwen?

Start een project