Prototype in een dag: van idee naar werkende app
Een digitale use case bestaat vaak alleen in slides en discussies — tot iemand er code op zet. Met One Day Build zet Appfront in één werkdag een echt werkend prototype neer voor jouw idee. Geen Figma-klikplaatje, geen specificatiedocument: een live applicatie die je collega's, gebruikers of directie meteen kunnen openen en testen.
Wat is een one day prototype precies?
Een one day prototype is een werkende eerste versie van een digitaal idee, gebouwd in één werkdag door een klein team. Geen ontwerp dat nog uitgebouwd moet worden, geen demo op localhost — maar een applicatie die op een echte URL draait, met echte interactie, geschikt om aan stakeholders te laten zien of door eindgebruikers te laten proberen.
Het idee is niet nieuw: in design sprints van Google Ventures wordt een vergelijkbare versnelling toegepast op designvraagstukken. Wat One Day Build anders maakt, is dat het eindresultaat geen klikbare schets is maar daadwerkelijke code. Een interactief klantportaal, een planningstool met echte logica, een dashboard dat data uit een testbestand laadt — wat de use case ook is.
De propositie past in een bredere tendens: AI-assisted development heeft de bouwsnelheid van applicaties drastisch verhoogd, en dat verandert wanneer "even snel iets uitproberen" realistisch is. Appfront combineert die snelheid met tien jaar ervaring in maatwerk software ontwikkelen, zodat het prototype niet alleen werkt, maar ook een fundament biedt voor een eventueel vervolg.
Werkende code, geen mockup
Het verschil met een klikbaar Figma-bestand is fundamenteel: een prototype heeft echte logica, kan data verwerken en gedraagt zich zoals een live applicatie. Verschil tussen MVP en prototype: een prototype valideert het idee, een MVP gaat naar de eerste gebruikers.
Aan tafel, niet via tickets
Een one day prototype is een gezamenlijke werksessie. Jij zit erbij, beslist mee over scope en ziet keuzes ontstaan. Geen lange briefings, geen radiostilte tussen oplevering en feedback.
Echte URL aan het eind
Aan het einde van de dag krijg je een live link die je kunt delen met collega's, klanten of investeerders. Geen "we sturen het binnenkort", geen demo-omgeving die alleen op een laptop draait.
Wanneer past een one day prototype bij jouw situatie?
Niet elk softwarevraagstuk vraagt om een prototype-in-een-dag. Voor een complex platform met meerdere gebruikersrollen, gevoelige integraties en compliance-eisen begin je beter met een gedegen consultancy-traject. Maar voor de fase waarin een idee nog geen draagvlak heeft, geen concrete vorm en geen prijskaartje, is een werkende dag-prototype vaak de snelste manier om verder te komen.
Goede momenten voor een One Day Build
- Een directielid heeft een idee dat moeilijk uitlegbaar is in tekst of slides
- Er ligt een investeringsvoorstel waar concreetheid aan toegevoegd moet worden
- Een interne afdeling wil aantonen dat een proces digitaal kan, voordat IT capaciteit toezegt
- Een product-team wil drie verschillende oplossingsrichtingen tegen elkaar afzetten
- Een sales- of customer-success-team wil iets tastbaars laten zien aan een prospect
- Een founder wil voor een investeringsronde een werkend voorbeeld op tafel hebben
Wanneer beter een ander traject
- De use case is uitgekristalliseerd en je weet al dat je naar productie wilt — start direct met een uitgebreider prototype-traject
- Er zijn complexe integraties nodig met meerdere bestaande systemen
- De applicatie moet voldoen aan strenge compliance (medisch, financieel toezicht)
- Er zijn al gebruikers wachtend op een werkende versie — dan is een maatwerk-traject passender
- De ambitie is een volledig product, geen experiment — start met scoping
Welke use cases passen in een werkdag?
Een goed One Day Build heeft een scherpe scope: één kern-flow, één duidelijke gebruiker, één bewijs-vraag. Dat klinkt beperkend, maar binnen die afbakening is veel mogelijk omdat moderne frameworks en bibliotheken het bouwen van interactieve interfaces sneller maken dan ooit. Voorbeelden van wat in één dag haalbaar is — generiek beschreven, omdat elke use case anders is:
Klantportaal voor self-service
Een interface waar klanten inloggen, hun gegevens zien, een aanvraag indienen en de status volgen. Een werkende eerste versie van een portaal-applicatie als bewijs van concept voor je interne discussie.
Operationeel dashboard
Een interface die data uit een spreadsheet of API binnenhaalt en visualiseert in grafieken, tabellen en filters. Vergelijkbaar met een KPI-dashboard op maat, maar dan in dag-vorm om eerst het concept te bewijzen.
Planning- of registratietool
Een interface waar een team taken plant, uren registreert, voorraad bijhoudt of een ander operationeel proces vastlegt. Een eerste schets van een workflow-applicatie die je kunt voorleggen aan de eindgebruikers.
Interne registratie-app
Een formulier-gedreven tool die data verzamelt en doorzet naar een database of bestaand systeem. Bijvoorbeeld een intake-app, een meldingensysteem of een eenvoudige intranet-webapp.
AI-gedreven feature
Een interface bovenop een large language model dat een specifieke taak uitvoert: documenten samenvatten, vragen beantwoorden, content genereren. Een eerste prototype voor een AI-applicatie om te toetsen of de output bruikbaar is.
Mobiele app-schets
Een prototype dat ook werkt op smartphones — bijvoorbeeld een veldwerk-app of een ledenapp. Vaak gebouwd als responsive webapp die later als native of hybride app doorontwikkeld kan worden.
Hoe verloopt zo'n werkdag in grote lijnen?
Een One Day Build is bewust strak ingericht. Een werkdag is kort, dus elke fase heeft een vast doel. Het uitgebreide verhaal — inclusief wat je vooraf instuurt, wie aan tafel zit en wat je na afloop meekrijgt — staat op de OneDayBuild-pagina onedaybuild.nl. In grote lijnen ziet zo'n dag er als volgt uit:
Voorafgaand aan de dag deel je de use case en een paar referenties. Wij kiezen de juiste stack, zetten de projectomgeving klaar en zorgen dat we op dag-zelf direct kunnen bouwen — niet eerst tooling installeren.
In de ochtend bepalen we samen de scherpe scope. Welke kern-flow moet werken? Welke schermen zijn essentieel? Wat houden we expliciet buiten dit prototype? Een goede scope is het verschil tussen een af prototype en een halve oplevering.
Het grootste deel van de dag bouwen we, met jou aan tafel. We laten regelmatig zien wat werkt, we passen aan op basis van wat je terugkrijgt. Beslissingen die normaal in tickets en mails zouden plaatsvinden, gebeuren ter plekke.
Aan het einde van de dag staat het prototype op een echte URL. Je krijgt toegang tot de code, een korte schriftelijke samenvatting van de keuzes die we hebben gemaakt en — als je dat wilt — een roadmap voor een eventueel vervolgtraject.
Wat krijg je aan het einde van de dag?
Een werkend prototype is het zichtbare resultaat, maar het belangrijkste is dat je verder kunt. Het prototype is bedoeld om beslissingen te ondersteunen — niet als product op zichzelf. We zorgen dat je er meteen iets mee kunt, of de uitkomst nu "we gaan door" of "we stoppen ermee" is.
Het werkende prototype
- Live applicatie op een eigen URL, deelbaar met je team of stakeholders
- Werkende kern-flow met realistische data — geen lorem ipsum, geen lege schermen
- Responsive interface die werkt op laptop, tablet en telefoon
- Toegang tot de broncode, in een Git-repository die op jouw naam staat
Het fundament eronder
- Een keuze voor de techstack die past bij waar dit idee uiteindelijk heen zou kunnen groeien
- Een schriftelijke samenvatting van de keuzes die gemaakt zijn en waarom
- Een ruwe roadmap-schets voor wat een vervolgtraject zou inhouden
- Een eerlijk advies of een vervolg überhaupt zinvol is — en zo ja, in welke vorm
Waarom werkt prototyping in een dag eigenlijk?
Een prototype in een dag bouwen zou tien jaar geleden ondenkbaar zijn geweest. Drie ontwikkelingen hebben het haalbaar gemaakt, en alle drie zijn de afgelopen jaren in een stroomversnelling geraakt:
Volwassen frameworks
Tools als Next.js, React en Tailwind verzorgen het saaie werk — routing, styling, formulieren — uit de doos. Wat blijft is de logica die jouw use case uniek maakt.
Database-as-a-service
Met Postgres-cloud-providers, Firebase en vergelijkbare diensten heb je binnen minuten een werkende database en authenticatie. Geen servers configureren op de dag zelf.
AI-assisted development
Code-assistenten als Cursor en Claude versnellen het schrijven van standaardcode. De developer blijft in de stoel — maar besteedt minder tijd aan boilerplate en meer aan keuzes die ertoe doen.
Het is niet "magie" en het lost niet ieder vraagstuk op. Voor productie-software gelden andere eisen — testing, security, performance, compliance — en daar nemen we ruim de tijd voor. Maar voor het beantwoorden van de vraag "kan dit eigenlijk?" is een werkdag vaak meer dan genoeg. Lees in de kennisbank over softwarekosten hoe een one day prototype zich verhoudt tot grotere ontwikkelbudgetten.
Welke technologie zetten we standaard in?
De keuze is altijd afhankelijk van de use case, maar er is een veelgebruikte basis waarmee we elk One Day Build kunnen starten. De stack is bewust gangbaar — geen exotische experimenten — zodat een eventueel vervolgtraject niet vastloopt op rare keuzes die op de dag zelf zijn gemaakt.
Frontend
Voor de interface kiezen we doorgaans Next.js of Astro met React-componenten. Beide frameworks zijn goed gedocumenteerd en breed gedragen, dus elk developer-team kan er later mee verder. Mobiele interactie testen we via responsive design — voor echt native gedrag zetten we soms Flutter in.
Data, AI en hosting
Voor data gebruiken we Postgres via een managed provider zodat we op dag-zelf geen tijd verliezen aan database-administratie. AI-features sluiten we aan op gevestigde modellen via standaard-API's. De hosting is per default cloud-managed, met een eigen domeinnaam als je dat wilt.
Waarom een One Day Build bij Appfront?
Snel een prototype bouwen kan tegenwoordig met talloze tools. Het verschil zit niet in de snelheid op zich, maar in wat je eruit haalt en wat je ermee kunt na afloop. Drie redenen waarom organisaties hun One Day Build bij Appfront doen in plaats van bij een puur productizing-bureau:
Consultancy in dezelfde stoel
De developer die jouw prototype bouwt, denkt mee over de scope. Wat is de kern-vraag die we willen beantwoorden? Welke aanname is het meest risicovol? Vergelijkbaar met onze maatwerk-consultancy, maar dan in een ander tempo.
UX-denken vanaf het begin
Een prototype dat er rommelig uitziet, krijgt geen serieuze respons van stakeholders. Onze designers werken mee aan de structuur en het gevoel — niet als afzonderlijke designfase, maar parallel aan het bouwen.
Echte engineering, geen vibecoding
Het prototype is zo gebouwd dat een vervolgtraject erop kan voortbouwen. Standaard project-structuur, leesbare code, geen losse hacks die later opnieuw moeten worden. Zie ons werk voor de software-trajecten die uit zulke starts zijn voortgekomen.
Wat gebeurt er na de One Day Build?
Een prototype is geen eindpunt. Het is een beslis-moment. Op basis van wat er aan het einde van de dag staat, kies je hoe je verder gaat — en die keuze maak je zelf, niet onder druk. We zien grofweg vier vervolgen voorkomen:
Direct doorbouwen naar productie
Je bent overtuigd, de stakeholders zijn overtuigd, en je wilt doorpakken. We zetten het traject om in een regulier maatwerk-software-traject met sprint-planning, een vaste developer-bezetting en concrete opleveringen.
Doorontwikkelen naar MVP
Het prototype heeft de kern bewezen, maar er moeten nog gebruikersrollen, integraties en productie-eisen bij. Een webapplicatie-traject of bredere AI-applicatie kan dan een logische vervolgstap zijn.
Intern dragen, met losse hulp
Soms heeft een organisatie zelf een developer-team en wil het de doorontwikkeling intern doen. Dan dragen we de code netjes over en blijven we op afroep beschikbaar voor sparring of stukjes uitbesteed werk.
Het idee niet voortzetten
Dat is ook een legitiem resultaat. Soms is de uitkomst dat het idee in deze vorm niet werkt — en dan heeft de dag je veel meer bespaard dan hij gekost heeft. Geen langdurig project dat ergens halverwege stuk loopt.
Klinkt het als wat jij nodig hebt?
Begin met een korte beschrijving van het idee en wat je ermee wilt aantonen. We laten weten of een One Day Build past, of dat een ander traject logischer is. Voor de uitgebreide propositie, beschikbaarheid en wat je vooraf instuurt, zie de OneDayBuild-pagina.
Veelgestelde vragen over prototyping in een dag
De vragen die we het vaakst krijgen van organisaties die overwegen om een One Day Build te doen of een use case op deze manier willen valideren.
Een prototype bewijst een idee — kan dit werken, gaan mensen dit gebruiken, is dit de juiste richting. Een MVP (minimum viable product) is een eerste productieversie die naar echte gebruikers gaat en omzet kan genereren. Een prototype zit voor het MVP, niet erna. Meer hierover lees je in onze kennisbank over MVP versus prototype.
De actuele prijs, beschikbaarheid en wat erbij is inbegrepen staat op de OneDayBuild-pagina onedaybuild.nl. Daar staat ook hoe de prijs zich verhoudt tot een eventueel vervolgtraject. We hanteren bewust geen prijslijst op deze pagina, omdat de voorwaarden van tijd tot tijd worden bijgesteld.
Voor een scherp afgebakende use case wel. Het ontkent niet dat een productie-app maanden bouwwerk vraagt — maar voor de vraag "werkt deze kern-flow zoals we denken?" is een werkdag, met een ervaren team aan tafel, vaak voldoende. Het cruciale woord is afbakening: een One Day Build die te veel wil dekken, levert geen werkend prototype op. Daar bewaken we de scope strak voor.
Jij. Aan het einde van de dag krijg je toegang tot de Git-repository, je kunt de code zelf hosten of door je eigen team laten doorontwikkelen. Geen vendor lock-in. Ook als je besluit niet met Appfront verder te gaan, blijft de code van jou.
Een korte beschrijving van het idee, de gebruiker waar het voor bedoeld is, en de centrale vraag die het prototype moet beantwoorden. Eventueel een paar voorbeelden of referenties van vergelijkbare interfaces. Geen technische specs nodig — die werken we samen uit. De OneDayBuild-pagina onedaybuild.nl beschrijft het voorbereidingsproces uitgebreider.
In de meeste gevallen wel, mits het data is die niet onder strenge compliance valt. Een Excel-bestand met testgegevens, een CSV-export uit een bestaand systeem of een paar voorbeeld-records is doorgaans voldoende. Voor productie-data uit gevoelige systemen vragen we vooraf om eventuele verwerkersovereenkomsten of beperkingen.
Dan zetten we het om in een vervolgtraject. Afhankelijk van wat het idee vraagt, kan dat een maatwerk-software-traject zijn, een MVP-bouw of een ingebouwde feature in een bestaand systeem. We maken in dat geval samen een roadmap met sprint-indeling en gerichte opleveringen.
Ja, en dat is vaak juist waar de meeste waarde zit. Voor organisaties zonder een eigen developer-team is een werkend prototype hét moment om intern draagvlak te krijgen voor een digitaal initiatief. We zijn gewend om met directies, innovatie-managers en operationele teams te werken die zelf geen code schrijven.
One Day Build in onze bredere dienstverlening
Een One Day Build is een instap-product, geen losse activiteit. Het past in een ecosysteem van diensten waarin we organisaties begeleiden van eerste idee tot live software. Voor wie verder kijkt dan het prototype, zijn dit de logische vervolgen of alternatieven binnen het diensten-portfolio:
Maatwerk software ontwikkelen
Maatwerk software laten maken is het natuurlijke vervolg op een geslaagd prototype. Volwaardige sprint-trajecten met UX, development en oplevering.
Webapplicatie laten bouwen
Een webapplicatie laten bouwen is geschikt voor prototypes die richting een echte gebruikersbasis groeien — met authenticatie, rollen en integraties.
AI-applicaties bouwen
Voor prototypes met een AI-component zetten we een AI-applicatie-traject in, met evaluatie van modeluitvoer en kostenstructuur.
Software-consultancy
Geen One Day Build, maar een traject van weken? Onze software-consultancy begeleidt bij architectuur en stack-keuzes.
Prototype-trajecten
Iets uitgebreider dan een dag? Een app-prototype-traject bestrijkt enkele sprints met diepere uitwerking en gebruikerstests.
Eerder werk inzien
Benieuwd welke trajecten uit vergelijkbare vragen zijn voortgekomen? Op ons werk staan voorbeelden van software-trajecten in zorg, transport en publieke sector.
Een prototype is sneller dan een uitleg
Of het idee uiteindelijk doorgaat of niet — een werkend prototype maakt het gesprek scherper, de beslissing makkelijker en de volgende stap concreter. Vertel ons in een paar zinnen wat je voor je ziet, dan kijken we of een One Day Build de juiste vorm is. Voor de uitvoerige aanpak-uitleg, beschikbaarheid en voorwaarden staat alles op de OneDayBuild-pagina.