Het werk dat elk product herhaalt
Een nieuw product begint met een specifiek probleem. De eerste weken zien er vaak veel minder specifiek uit: sessies, workspacerecords, abonnementsstatus, achtergrondwerk en e-mailaflevering. Deze stukken moeten samenwerken voordat het product iets nuttigs kan doen.
supastack geeft dat herhaalde werk een thuis. Een Next.js-webapp en een Expo-mobiele app delen TypeScript-packages voor de infrastructuur eronder. Het doel is die grenzen begrijpelijk genoeg te maken dat een product ze kan configureren zonder andermans domeinmodel te erven.
Geen van de stukken is op zichzelf moeilijk. De kosten zitten in hun coördinatie — een betaling die een entitlement moet worden, een sessie die een workspacescope moet worden, een taak die een dichte laptop moet overleven. Producten falen zelden op een ontbrekende feature. Ze falen op een naad.
Geef elke module één verantwoordelijkheid
Identiteit stelt vast wie een request doet. Workspaces bepalen welke records die persoon kan benaderen. Billing legt betaalstatus vast, terwijl entitlements beantwoorden of een capability beschikbaar is. Deze zaken gescheiden houden voorkomt dat een succesvolle betaalredirect een autorisatiebeslissing wordt.
Dezelfde discipline geldt voor achtergrondwerk. Het gedeelde JobRunner-contract belooft enqueue, status en cancel. Trigger.dev bezit het workflowgedrag. Een klein interface is waardevol wanneer zijn grenzen zichtbaar zijn; retries of scheduling achter een generieke methode verstoppen zou het systeem moeilijker te beredeneren maken.
Better Auth beantwoordt identiteit. Postgres en Drizzle houden de records vast. Stripe of Lemon Squeezy rapporteren betaalstatus. Van geen van hen wordt gevraagd slim te zijn over de taak van een andere module — de naden blijven smal genoeg om te beredeneren — en een fundament is slechts zo betrouwbaar als zijn naden.
Laat ruimte voor het product
Een prospectingworkflow, een documenteditor en een researchassistant kunnen dezelfde identiteits- en billingmodules gebruiken. Hun records, taal en workflows blijven verschillend. Productspecifieke logica hoort in de codebase van het consumerende product, met configuratie die het aan het fundament verbindt.
Deze scheiding is ook een praktische onderhoudsbeslissing. Een fix voor workspace-isolatie moet herbruikbaar zijn. Een wijziging in hoe één product een prospect scoort mag geen nieuwe eis worden voor elk ander product.
Dat is het verschil tussen een fundament en een thema. Een thema geeft je een uiterlijk om te houden of te vervangen. Een fundament geeft je dragende beslissingen — wie identiteit bezit, hoe records worden afgebakend, waar een betaling toegang wordt — waarop een product bouwt in plaats van eromheen werkt. De projectstructuurgids laat zien waar het ene eindigt en het andere begint.
Begin met één complete flow
Begin met het lokale referentiepad: log in, inspecteer toegang, dien een taak in en lees het resultaat. Fake en lokale adapters laten deterministische tests het pad oefenen zonder betaalde providerrequests — de vijf-minuten-quickstart draait het end-to-end. Configureer daarna de productie-integraties die je product echt nodig heeft.
Lokale acceptatie en productieacceptatie beantwoorden verschillende vragen. Een slagende lokale test stelt applicatiegedrag onder gecontroleerde condities vast. Echte authenticatiepersistentie, provideraflevering, deployment en apparaatgedrag hebben nog steeds hun eigen verificatie nodig. Houd dat onderscheid zichtbaar terwijl het product groeit.
Een fundament verdient zijn naam langzaam: in het tweede product dat sneller shipt dan het eerste, en in de onderhoudsdag die één module fixt in plaats van vijf codebases. Dat is de weddenschap achter supastack — en het is de lat waaraan elke module wordt gehouden.
Vragen achter de aanpak
Onder deze aanpak zitten een paar vragen, en die verdienen een eerlijk antwoord.
- Is supastack een template of een framework? — Een fundament van modules met contracten ertussen. Productcode leeft buiten Starter Core en verbindt via configuratie, zodat het platform kan worden geüpdatet zonder je features te forken.
- Maakt gedeelde infrastructuur producten niet generiek? — Alleen de plumbing is gedeeld. Records, workflows en taal blijven in de codebase van het product — de delen die klanten echt zien blijven van jou.
- Waar begint de eigen code van het product? — Bij de records en workflows die alleen het product heeft. Het fundament authenticeert de gebruiker en bakt de data af; het weet niet wat een prospect is.
- Waarom een monorepo? — Zodat de web-, mobiele en desktop-apps samen veranderen met de packages eronder: één typesysteem, één testgate, geen drift tussen repositories.
- Wat als ik alleen de webapp nodig heb? — Het fundament is de aankoop; mobiel en desktop zijn oppervlakken om te adopteren of te negeren. Niets dwingt je een app te shippen die je niet nodig hebt.