Doorloop de eerste sessie van de klant
Maak een vers account aan in de omgeving die je wilt uitbrengen. Volg verificatie- of providercallbacks, herlaad de applicatie, werk een profiel bij en log uit. Herhaal de reis op een smal scherm met een toetsenbord. Je normale ontwikkelsessie kan ontbrekende setupstappen en verloren state verbergen.
Controleer de berichten die uitleggen wat er daarna te doen is. Een leeg scherm moet een nuttige actie bieden. Een gefaalde request moet uitleggen hoe opnieuw te proberen zonder te suggereren dat werk is gelukt. Gebruik de taal van het echte product in die berichten en zorg dat account- en supportlinks naar echte bestemmingen leiden.
Herhaal de reis één keer per inlogmethode. OAuth-callbacks voor Google en GitHub dragen elk hun eigen redirect- en faalvormen (de OAuth-setupgids dekt het configureren), en het test-consentscherm van een provider gedraagt zich anders dan een productiescherm.
- Nieuwe accountcreatie en sessieherstel werken.
- Uitloggen trekt toegang in en wist de presentatie van de vorige gebruiker.
- Lege-, laad- en errorstates blijven begrijpelijk op mobiel.
- Elke OAuth-provider voltooit zijn callback op het echte domein.
- Verificatie- en resetmails komen aan, lezen helder en linken naar de juiste omgeving.
- De first-run-ervaring vertelt een nieuwe gebruiker wat de volgende stap is.
Bewijs betaalde toegang op de server
Checkout is de makkelijke helft. Doorloop de hele lifecycle in de sandbox van de provider: aankoop, webhook ontvangen en geverifieerd, entitlement gepersisteerd, betaalde feature ontgrendeld — daarna verlenging, annulering en refund. Elke overgang moet server-owned state wijzigen, niet alleen een clientflag. De billinggids laat zien waar supastack die state bewaart.
Test daarna de events die je hoopt niet te zien: een webhook die twee keer aankomt, een gefaalde betaling, een abonnement dat midden in een taak vervalt. Een entitlement beantwoordt “mag dit nu” op het moment van de request; een dashboardbadge doet dat niet.
- Een sandboxaankoop voltooit en ontgrendelt de betaalde feature.
- Dubbele webhookafleveringen zijn veilig — verwerking is idempotent.
- Annulering en refund trekken toegang in op de servergrens.
- Per-seat- of gebruikslimieten, indien aangeboden, weigeren buiten hun voorwaarden.
Verifieer de grenzen met echte dependencies
Gebruik twee onafhankelijke accounts om eigenaarschap te verifiëren. Probeer het record van het ene account vanuit het andere te lezen en te wijzigen, inclusief taakstatus en recovery-URL's. Check betaalde toegang op de serveractiegrens, niet alleen door een knop in de interface te verbergen.
Workspace-afgebakende records zijn de ruggengraat van een multi-tenantproduct — de workspacegrenzen-post legt het model uit. Wat je stack ook is, de launchvraag is dezelfde: leidt elke read en write eigenaarschap af van de geauthenticeerde servercontext, zonder dat een record-ID of een door de client gestuurde workspace als bewijs wordt geaccepteerd?
- Cross-workspace reads en writes worden afgewezen.
- Recovery- en taak-URL's verlenen op zichzelf geen toegang.
- List- en detailviews handhaven dezelfde scoping.
- API-keys en webhooks dragen, indien aangeboden, ook workspacescope.
Oefen de faalpaden bewust
Achtergrondwerk faalt op twee verschillende manieren, en elk heeft zijn eigen test nodig. Een gefaalde dispatch laat de client onzeker of er iets in de queue is gezet — een taak-scoped idempotencykey en een opgeslagen submission laten recovery de originele request hergebruiken in plaats van te dupliceren. Een gefaalde voltooiing betekent dat het werk draaide maar het resultaat nooit aankwam — retries en statuspolling moeten die kloof dichten zonder een tweede generatie.
Pas dezelfde denkwijze toe op providers: een AI-providertimeout, een gebouncte e-mail, een billing-API-fout. Elk moet eindigen in een specifieke, uitlegbare state in plaats van een stil halfresultaat. De taakrecoverygids documenteert hoe het productiepad van de kit hiermee omgaat.
- Een retry na een submissiontimeout dupliceert geen werk of kosten.
- Een gefaalde voltooiing is zichtbaar en herstelbaar, geen stil verlies.
- Providerfouten bereiken de gebruiker als eerlijke states, niet als generieke crashes.
Bereid je voor op de eerste failure
Zorg dat iemand een fout kan vinden, aan de relevante taak kan koppelen en de gebruiker kan helpen herstellen zonder providersecrets bloot te stellen. Bevestig welke logs en auditrecords bestaan, hoe lang je ze bewaart en hoe een operator er toegang toe krijgt.
Bepaal vóór de lancering hoe “er is iets mis” eruitziet: gefaalde jobafleveringen, webhookverificatiefouten, een plotselinge stijging in providerspend. Een alert die niemand ontvangt is geen monitoring — de observability-setup dekt het bedraden van die signalen.
Behandel backups als een operationele oefening: een geconfigureerde backup is niet hetzelfde als een herstelde. Draai de restore eenmalig, op data die op productie lijkt, vóór de dag dat je hem nodig hebt.
- Een fout is te herleiden tot de request, gebruiker en taak die hem veroorzaakte.
- Logs en auditrecords hebben een eigenaar, een retentiebeleid en toegangsregels.
- Een backup is hersteld, niet alleen geconfigureerd.
- Gefaalde jobs en webhookfouten wekken een alert die een mens ontvangt.
Check de oppervlakken rond het product
Juridische en communicatieoppervlakken zijn deel van de launch, geen polish: privacy en voorwaarden die beschrijven wat het product echt doet, een supportadres dat een mens bereikt en een geverifieerd afzenderdomein zodat transactionele mail aankomt vanaf een adres dat jij bezit.
Lees elke geautomatiseerde e-mail zoals een klant dat zou doen. Verificatie-, reset-, bon- en voltooiingsberichten moeten de naam van het product dragen, links naar de juiste omgeving en een antwoordpad dat geen dood noreply-adres is.
- Privacy- en voorwaardenpagina's beschrijven het product dat je echt draait.
- Transactionele mail verzendt vanaf een geverifieerd domein dat jij bezit.
- Support- en billingvragen hebben een bereikbare bestemming.
Maak de go- of no-go-beslissing expliciet
Stel het releasedossier samen: de buildrevisie, de doelomgeving, wat getest is en hoe, en wat ongeverifieerd blijft. Een checklist met eerlijke gaten verslaat een zelfverzekerde samenvatting — in de gaten zit meestal het eerste incident.
Bepaal het rollbackpad voordat je het nodig hebt: hoe je de deployment terugdraait, wat er gebeurt met de tussendoor geschreven data en wie de call maakt. Lanceer daarna de kleinste versie van het aanbod die je volledig kunt ondersteunen, en verbreed bewust.
Veelgestelde launchvragen
Launchchecklists falen op voorspelbare plekken. Dit zijn de vragen die de meeste ervan opvangen.
- Wat vergeten de meeste SaaS-launches? — De uiteinden van flows: uitloggen dat echt revocet, annulering die echt toegang verwijdert en een restore-oefening voor de backup die op papier bestaat.
- Hoeveel testaccounts heb ik nodig? — Minstens twee, in de doelomgeving. Data-isolatie en uitnodigingsflows zijn met één niet te verifiëren.
- Sandboxtesten of productietesten? — Allebei. Sandbox bewijst de lifecyclelogica; een kleine echte transactie bewijst dat keys, domeinen en webhooks naar de juiste plek bedraad zijn.
- Wanneer is het veilig om te lanceren? — Wanneer elk item dat klantdata of geld beschermt geverifieerd is, en de ongeverifieerde items met eigenaren zijn opgeschreven — niet wanneer de featurelijst er compleet uitziet.
- Wat verandert er na de launch? — Bewaar het releasedossier, let op de failure-alerts die je configureerde en draai de checklist opnieuw na elke significante wijziging aan auth, billing of scoping.