Een prototype dat prima werkt als jij het test, kan al struikelen bij twintig mensen tegelijk, en dat komt bijna nooit doordat de server te klein is. Het knelt vrijwel altijd op een limiet: het aantal databaseverbindingen, een externe dienst die je afremt, of zwaar werk dat in het verzoek zelf gebeurt terwijl de gebruiker wacht. Hieronder staat waar het misgaat, hoe je het herkent en hoeveel je prototype eigenlijk aan moet kunnen.
Vrijwel elk schaalprobleem in een prototype is een limiet die geraakt wordt, geen tekort aan rekenkracht.
Als je alleen bent, doorloopt je prototype één pad tegelijk. Zodra er meerdere mensen op zitten, vechten die paden om dezelfde databaseverbinding, dezelfde plek in de wachtrij, dezelfde externe dienst met een eigen limiet. Het beeld is verwarrend: de app is loodzwaar en tegelijk doet de processor vrijwel niets. Er wordt niet gerekend, er wordt gewacht.
Dat is een ander probleem dan een prototype dat live helemaal niet opstart. Werkt je app lokaal wel en op de server niet, dan zit de fout in de omgeving, en daarover gaat een prototype dat lokaal werkt maar niet live. Deze pagina gaat over het geval daarna: het staat live en werkt, maar bezwijkt zodra er echt mensen tegelijk op zitten.
Bezoekersaantallen zeggen weinig. Wat telt is hoeveel werk er tegelijk openstaat.
Jij denkt in bezoekers per maand, je server denkt in verzoeken die nu nog niet klaar zijn. Een paar honderd bezoekers per dag, netjes verspreid, betekent zelden meer dan een handvol mensen die echt tegelijk iets doen. Wat je omver duwt is niet het gemiddelde maar de piek: de mailing, de presentatie waarin je de link op het scherm zet.
Zelfs dan is het aantal mensen niet de goede maatstaf. Wat de capaciteit bepaalt is hoeveel verzoeken elkaar overlappen en hoe lang elk verzoek bezig is. Eén handeling die seconden duurt, omdat er een bestand wordt ingelezen of een AI-model wordt aangeroepen, houdt al die tijd een plek bezet. Twintig mensen op die ene knop vragen meer van je systeem dan duizend mensen die de homepage bekijken.
Deze vijf zie je bijna altijd terug, en geen ervan wordt opgelost door een zwaardere machine.
Een limiet gedraagt zich anders dan een tekort. Aan het patroon zie je welke van de twee je hebt.
Een echt capaciteitstekort verloopt geleidelijk: het wordt drukker en alles wordt beetje bij beetje trager. Een limiet gedraagt zich als een schakelaar. Tot een bepaald punt is alles normaal, daarboven valt het in één keer om, en zodra de piek voorbij is werkt alles weer alsof er nooit iets was. Daarom blijft dit vaak onopgemerkt: tegen de tijd dat jij kijkt, is het bewijs verdwenen.
Dat is ook waarom de eerste reflex, een groter hostingpakket, meestal niets oplevert. Meer rekenkracht verandert niets aan het aantal verbindingen dat je database toestaat, niets aan de rem van je mailprovider en niets aan twee mensen die hetzelfde record overschrijven. Meten is goedkoper dan gokken: de enige vraag is waar een verzoek op staat te wachten, en dat is vaak al zichtbaar met een tijdmeting rond de verdachte handelingen.
De linkerkolom voorkomt de meest voorkomende ellende met beperkt werk. De rechterkolom kun je uitstellen tot je weet dat je het nodig hebt.
De vraag omdraaien scheelt werk aan iets waar nog niemand om heeft gevraagd.
Bouwen voor duizenden gebruikers terwijl je er nog geen tien hebt, is de duurste manier om een idee te toetsen. Elke voorziening kost bouwtijd, maakt aanpassen moeilijker en moet onderhouden worden, ook als de drukte nooit komt. En dat is het normale scenario: de meeste validatie-prototypes komen nooit in de buurt van een echt schaalprobleem.
De bruikbaarder vraag is niet hoeveel je prototype aankan, maar hoeveel het aan moet kunnen om je volgende beslissing te nemen. Een team van vijftien dat ermee moet werken is een andere bovengrens dan één demo aan een investeerder. In beide gevallen zit je ruim binnen wat een eenvoudige opzet aankan, zolang de knelpunten hierboven niet in je code zitten. Klopt het idee, dan is dat het moment om de rest te bouwen: van prototype naar productie beschrijft dat werk, en wanneer een prototype productierijp is geeft de vragen waarmee je die stap inschat.
Daar is geen vast getal voor. Het hangt niet af van het aantal mensen, maar van hoeveel trage handelingen tegelijk openstaan. Zit er een handeling in die seconden duurt, zoals een AI-aanroep, dan loopt de wachtrij bij een handvol gelijktijdige gebruikers al vol.
Omdat er niet gerekend wordt maar gewacht: op een vrije databaseverbinding, op een externe dienst of op elkaar in de wachtrij. Een lage processorbelasting bij trage pagina's is juist het signaal dat je tegen een limiet aanloopt, niet tegen een tekort aan capaciteit.
Zelden. Meer rekenkracht verandert niets aan het aantal verbindingen dat je database toestaat, niets aan de limiet van een leverancier en niets aan twee gebruikers die hetzelfde record overschrijven. Zoek eerst uit waar een verzoek op staat te wachten.
Dat is een ander probleem. Start je prototype live helemaal niet, dan zit de fout in de omgeving: instellingen, paden, sleutels. Deze pagina gaat over een prototype dat wel live staat en werkt, maar bezwijkt onder gelijktijdig gebruik.
Veel goedkope en gratis hostingplannen zetten je applicatie stil als er een tijd niemand komt, en starten hem pas bij het volgende verzoek weer op. Die eerste bezoeker betaalt de opstarttijd. Deel je de link met testgebruikers, kies dan een omgeving die blijft draaien.
In de meeste snel gebouwde prototypes wint degene die als laatste opslaat, en verdwijnt de wijziging van de ander zonder melding. Zelfde categorie: voorraad die dubbel verkocht wordt. Het wordt niet traag, het wordt stil fout.
Nee. Bouwen voor duizenden gebruikers terwijl je er nog geen tien hebt, kost bouwtijd en onderhoud waar niets tegenover staat. Bepaal hoeveel gelijktijdig gebruik je nodig hebt voor je volgende beslissing en meet wanneer die grens in zicht komt.
Stuur ons je idee. Wij leveren in één werkdag een klikbaar prototype waarmee je je testgroep kunt laten werken, zodat je weet of het de moeite waard is om er iets omheen te bouwen dat gelijktijdig gebruik moet dragen.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.