Van idee naar product in 16 weken — hoe een fintech startup zijn eerste betalende klanten won

In het vroege voorjaar van 2025 kwamen twee oprichters naar ons toe met een idee en een probleem. Het idee: een tool die kleine bedrijven helpt bij het afstemmen van inkomende betalingen op openstaande facturen — een proces dat in de boekhoudwereld "reconciliatie" heet en door veel MKB'ers wekelijks handmatig wordt gedaan in Excel of via hun boekhouder.

Het probleem: geen van beiden had een technische achtergrond. Ze kenden het domein — de ene oprichter had tien jaar in financieel management gewerkt — maar ze hadden geen idee hoe je van een idee naar een werkend product komt.

Zestien weken later was het product live. In de eerste maand: 47 betalende klanten. Drie maanden daarna: een seed ronde van €600.000, mede mogelijk gemaakt door het feit dat ze een werkend product konden demonstreren.

Dit is het verhaal van hoe dat traject eruitzag — inclusief wat we hebben weggesneden en waarom.

Week 1–2: Discovery en fundering

De eerste twee weken hebben we niet gebouwd. We hebben geluisterd, gevraagd en gestructureerd.

De oprichters hadden een lijst met twintig features. Dat is normaal — iedereen die een probleem goed kent, heeft ideeën over hoe het op te lossen. Onze taak in deze fase was het scheiden van "nice to have" en "must have" — maar meer nog: het identificeren van de ene kernfunctie die het verschil maakt.

Via interviews met tien potentiële gebruikers — kleine ondernemers, freelancers, eenmanszaken met een boekhouder — kwamen we tot een scherp beeld. Het pijnpunt was niet de reconciliatie zelf, maar het ontbreken van overzicht: welke facturen zijn betaald, welke zijn open, en zijn de bedragen correct? Het werkelijke probleem was statusonzekerheid, niet procesautomatisering.

Dit veranderde de scope fundamenteel.

Parallel aan de discovery: tech stack beslissingen. We kozen voor een bewezen combinatie — Next.js voor de frontend, een Node.js backend, PostgreSQL als database — en integreerden met de Mollie API voor betalingsdata en de Twinfield API voor boekhoudkoppelingen. Geen experimentele keuzes: bij een strakke tijdlijn wil je technologie die je goed kent.

Week 3–6: Het MVP bouwen

De kern van het MVP bestond uit drie componenten:

Authenticatie en onboarding. Niet glamoureus, maar kritiek. Een gebruiker die niet kan inloggen of de koppeling met zijn bankrekening niet kan maken, is een gebruiker die je kwijt bent. We hebben de onboarding drie keer opnieuw ontworpen na interne testsessies. De definitieve versie: vijf stappen, geen verplichte creditcard, koppeling met Mollie of eigen bankfeed via bestandsupload.

De reconciliatie-engine. Het hart van het product. Inkomende betalingen worden gematcht aan openstaande facturen op basis van bedrag, factuurnummer en betalingsreferentie. Bij een exacte match: automatisch verwerkt. Bij onzekerheid: gepresenteerd aan de gebruiker ter bevestiging. We gebruikten fuzzy matching voor gevallen waarbij betalingsomschrijvingen niet exact overeenkomen — dit dekte zo'n 80% van de twijfelgevallen.

Het dashboard. Eén scherm met drie getallen: openstaande facturen, ontvangen maar niet gematcht betalingen, en succesvolle reconciliaties deze maand. Geen rapporten, geen grafieken, geen exports — dat was allemaal uitgesteld. Het dashboard beantwoordde de centrale gebruikersvraag: "Wat moet ik vandaag doen?"

Wat in deze fase bewust is weggelaten: automatische e-mailherinneringen aan klanten, een multi-user omgeving, boekhoudkundige rapportage, en een mobiele app. Allemaal wensen van de oprichters — allemaal legitiem. Maar geen van deze was noodzakelijk om de kernwaarde te demonstreren.

Week 7–10: Beta met vijf pilotklanten

Halverwege de bouw zijn we gestopt om te testen. Niet intern — met echte gebruikers.

Via het netwerk van de oprichters namen vijf kleine bedrijven deel aan de beta: een fotograaf, twee freelance consultants, een kleine installatiebedrijf en een webdesigner. Allemaal met vijf tot veertig openstaande facturen per maand.

De eerste week was leerzaam op een manier die geen interne test kan evenaren.

De installatiebedrijf werkte met factuurnummers die begonnen met "INS-2025-" — een prefix die onze matching-engine niet verwachtte. Het systeem deed niets fout, maar toonde alle betalingen als "onbekend". Fix: twee uur werk om de matching-logica flexibeler te maken.

De fotograaf wilde meerdere bankrekeningen kunnen koppelen. Die functie hadden we niet. Oplossing op korte termijn: handmatige CSV-upload als workaround. Op de backlog: native multi-bankrekening support.

Het meest waardevolle inzicht: gebruikers checkten het dashboard niet dagelijks, maar wekelijks. Ze wilden een e-mailsamenvatting op maandagochtend. Dit was een simpele feature — een geautomatiseerde wekelijkse digest — die we in week negen hebben toegevoegd. Retentie steeg direct zichtbaar: gebruikers die de digest kregen, kwamen drie keer vaker terug.

Week 11–14: Verfijning, performance, beveiliging

Na de betafase wisten we wat er moest worden verbeterd. Geen grote koerswijzigingen — gerichte aanpassingen.

Performance was een aandachtspunt. Bij grotere datasets (500+ facturen) was de initiële laadtijd van het dashboard te traag: 4–6 seconden. Via database-indexering en query-optimalisatie brachten we dit terug naar onder de 800 milliseconden.

In week dertien voerden we een externe security audit uit. Niet als formaliteit, maar als vereiste — je werkt met financiële data van klanten, en een kwetsbaarheid in een vroeg stadium is makkelijker op te lossen dan na de launch. De audit vond twee middelgrote issues rondom session management die we hebben opgelost. Geen kritieke kwetsbaarheden.

De oprichters hadden in de oorspronkelijke scope ook een gedetailleerde analytics module gewild. We hebben dit een tweede keer expliciet uitgesteld. Niet omdat het geen waarde heeft, maar omdat het de launch zou vertragen voor een feature die bestaande gebruikers nog niet vroegen. Het argument: "kom first, build fast, learn real" won het van "build comprehensive, launch perfect".

Week 15–16: Launch en monitoring

De launch was geen evenement. Het was een schakelaar die werd omgezet.

De eerste gebruikers — de vijf beta-deelnemers — werden omgezet naar betalende accounts. Hun feedback en gebruik gaven ons vertrouwen dat het product stabiel genoeg was voor een bredere lancering.

Via een LinkedIn-post van de oprichters, een ProductHunt-launch, en directe outreach in drie relevante online communities kwamen in de eerste twee weken 112 aanmeldingen binnen. Van die 112 converteerden 47 naar een betaald account binnen de eerste maand. Dat is een conversieratio van 42% — bovengemiddeld voor een nieuw SaaS-product.

De monitoring in de eerste twee weken was intensief: foutlogs dagelijks doorgenomen, gebruikersgedrag in Posthog gevolgd, en de oprichters in direct contact met elke betalende klant in de eerste week.

Drie maanden later hadden de oprichters genoeg tractie om een seed ronde te openen. Het werkende product — niet een pitch deck, niet een prototype, maar een product met betalende klanten en meetbare retentie — was het sterkste argument in die gesprekken.

Wat dit traject leert

Zestien weken is snel, maar niet magisch. Het vereiste een opdrachtgever die bereid was beslissingen te nemen en scope los te laten, een team dat prioriteiten stelde in plaats van alles wilde bouwen, en een proces dat real-world feedback vroeg inbracht in plaats van het uit te stellen tot na de launch.

De twintig features op de originele lijst van de oprichters zijn nog niet allemaal gebouwd. Sommige staan op de roadmap. Andere blijken na zes maanden gebruik minder relevant dan gedacht. Dat is geen teleurstelling — dat is het systeem dat werkt zoals het hoort.

Benieuwd of jouw idee in een vergelijkbaar traject tot een werkend product kan worden omgezet? Neem contact op voor een vrijblijvend gesprek.