De perfecte app die een ander probleem oploste
Ik heb maandenlang aan een app gewerkt die technisch perfect is. AI-chatbot die natuurlijk communiceert, beeldherkenning die werkt, video compressie, automatische opslag, sessie management – alles klopt. Ik was trots op wat ik had gemaakt.
Maar hij kwam niet in gebruik zoals bedoeld.
Niet omdat de techniek faalde. Niet omdat niemand hem wilde. Maar omdat ik alleen stond in het hele traject – van bouwen tot implementeren tot communiceren naar de eindgebruikers. Dat kon ik niet. En misschien was een app zelfs niet eens de juiste oplossing. Misschien moest gewoon de communicatie tussen het marketingbureau en hun klanten beter.
Dit is het verhaal van die les. Over hoe een werkend product nog niet betekent dat je het juiste probleem oplost. En waarom ik nu nooit meer begin zonder een blueprint.
Hoe het begon
Ik werkte destijds in dienst bij een bedrijf dat geen duidelijke richting gaf. Er waren geen heldere doelen, geen strategie waar je je aan vast kon houden. In plaats daarvan kreeg ik de ruimte om zelf projecten te bedenken en uit te voeren. “Ga maar zwemmen,” was eigenlijk de boodschap.
Dat klinkt als vrijheid. En op een bepaalde manier was het dat ook. Maar vrijheid zonder richting is eigenlijk gewoon dobberen.
In die omgeving kreeg ik een vraag van een marketingbureau. Hun klanten leverden geen informatie aan voor marketingmateriaal. Foto’s, teksten, video’s – alles wat ze nodig hadden, kwam niet of veel te laat binnen.
Ik zag een oplossing. Een professionele chat-app waar hun klanten tussendoor, vanaf hun telefoon, projectinformatie konden delen. Met een slimme AI die de juiste vragen stelt.
Ik maakte een proof of concept. Het werkte. Het marketingbureau was enthousiast. Dit kon echt iets worden.
Maar toen kwam het echte werk. En daar stond ik alleen. Geen team om mee te sparren. Geen gedeelde visie over waar dit naartoe moest. Geen blueprint van hoe we dit tot een succes zouden maken. Gewoon ik, een werkende prototype, en het idee dat ik dit wel zou uitbouwen.
Wat ik niet deed
Ik ging bouwen. n8n als backend voor de workflows. Claude AI voor intelligente gesprekken. Flutter voor de app op Android en iOS. Supabase voor data management. NextCloud voor opslag.
Ik loste technische uitdagingen op waar ik trots op was: sessie management tussen verschillende systemen, verschillende soorten input verwerken, video’s comprimeren, authenticatie via SMS. Het was mooi werk. Het werkte allemaal.
Maar ik was alleen in het project. Niemand om mee te sparren over waar dit naartoe moest. Geen gedeelde visie over hoe succes eruitzag. Geen duidelijk plan over hoe we dit bij de klanten van het marketingbureau geïmplementeerd zouden krijgen.
Ik miste de professionaliteit om dit tot een success te maken. Niet de technische kant – die had ik wel. Maar de structuur eromheen. Het gezamenlijke begrip van wat we aan het bouwen waren en waarom het zou werken. De aansluiting met het team van het marketingbureau en hun klanten.
Een proof of concept maken dat werkt is één ding. Dat omzetten naar iets dat mensen daadwerkelijk gaan gebruiken is iets heel anders. En daarvoor had ik een blueprint nodig. Een gedeeld fundament. Professionaliteit in het proces, niet alleen in de code.
Wat er gebeurde
De app werkte. Het marketingbureau vond het interessant. Maar om het echt te laten werken – om het bij hun klanten geïmplementeerd te krijgen – daar was meer voor nodig dan alleen ik.
Ik kon de techniek bouwen. Maar ik kon niet ook de hele communicatie naar hun klanten doen. Ik kon niet de implementatie begeleiden. Ik kon niet de feedback verzamelen en doorvertalen. Dat was een heel traject op zich.
En ondertussen begon ik me af te vragen: is een app wel de oplossing? Misschien moest gewoon de communicatie tussen het marketingbureau en hun klanten beter. Misschien was dit een proces-probleem, geen technologie-probleem.
Er was geen duidelijkheid over wat we nu eigenlijk aan het oplossen waren. Geen gedeeld beeld van hoe dit succesvol zou worden. Het bleef een werkend prototype zonder verder traject.
Niet omdat het niet goed was. Maar omdat er geen structuur was om het verder te brengen. Omdat we misschien het verkeerde probleem aan het oplossen waren.
De harde les
Als ontwikkelaar denk je al snel: als ik het technisch kan bouwen, komt het wel goed. Als de code werkt, is het probleem opgelost.
Maar dat is niet waar.
Tussen een werkend prototype en een succesvol product zit een heel traject. Implementatie. Communicatie. Begeleiding. Feedback verzamelen en verwerken. En dat is allemaal werk dat gedaan moet worden.
Dit project leerde me twee dingen tegelijk.
Eén: dat je heel duidelijk moet zijn over wat je aan het oplossen bent. Is het een technologie-probleem? Of is het een communicatie-probleem? In dit geval was het misschien helemaal geen app die nodig was, maar gewoon betere communicatie tussen het marketingbureau en hun klanten.
Twee: dat autonomie zonder richting geen vrijheid is, maar zwemmen. In dat bedrijf waar ik werkte, mocht ik alles bedenken en uitvoeren. Dat klonk fantastisch. Maar zonder een gedeeld beeld van waar we naartoe werkten, zonder een fundament waarop je kunt bouwen, maak je dingen die nergens op landen.
Ik had een werkend product. Maar ik miste de structuur en duidelijkheid om te bepalen of dit het juiste product was, en hoe we het succesvol zouden maken.
Die ervaring – zowel de app die bleef hangen als het werken zonder richting – heeft me geleerd waarom een blueprint niet optioneel is. Het is het verschil tussen bouwen en weten wat je aan het bouwen bent.
Wat ik leerde
Technisch kunnen bouwen is niet genoeg. Je moet eerst weten wat het échte probleem is dat je oplost.
Je kunt de mooiste oplossing ter wereld bouwen, maar als je het verkeerde probleem oplost – of als er geen structuur is om het tot een succes te maken – blijft het een prototype zonder verder traject.
Een blueprint is geen bureaucratie. Het is geen vervelend stappenplan dat je moet afwerken voordat je “eindelijk” mag beginnen. Een blueprint is het fundament waarop alles rust. Het is duidelijkheid over wat je aan het doen bent en waarom.
Een blueprint beantwoordt vragen als:
- Wat is het échte probleem? Is dit een technologie-probleem of een communicatie-probleem?
- Wat proberen we op te lossen? Voor wie precies?
- Hoe ziet succes eruit voor iedereen die erbij betrokken is?
- Wat zijn de stappen om van hier naar daar te komen?
- Wie doet wat, en wanneer? Wat kan ik, wat moet iemand anders doen?
- Hoe implementeren we dit in de werkelijkheid?
Die vragen beantwoorden kost tijd. Maar die tijd voorkomt dat je maanden besteedt aan het bouwen van een oplossing voor het verkeerde probleem.
De app vindt zijn plek
De kennis en techniek die ik ontwikkelde zijn niet verloren. Het systeem is gereed en klaar om ingezet te worden. En ik geef diezelfde techniek nu een nieuw leven – maar dit keer voor een toepassing waar hij beter past.
Een universele chat-app die direct met verschillende systemen kan praten. Onafhankelijk van grote bedrijven zoals Meta (WhatsApp), waar je niet weet wat er met je data gebeurt en waar je geen controle hebt over je zakelijke communicatie. Voor organisaties die controle willen over hun communicatie.
Het verschil? Dit keer begin ik met de blueprint. Dit keer is er duidelijkheid over wat het probleem is, voor wie ik het oplos, en wat er allemaal komt kijken om het succesvol te maken. De techniek is grotendeels hetzelfde, maar de context en structuur zijn er nu wel.
De app was niet mislukt. Hij paste gewoon niet bij dat specifieke probleem, in die specifieke situatie. Nu vindt hij zijn juiste plek.
Waarom Blueprint 8
Daarom heet mijn bedrijf Blueprint 8.
De 8 staat voor de oneindige integratiemogelijkheden waar ik mee werk. Maar “Blueprint” staat voorop. Niet omdat ik verliefd ben op documentatie of planning. Niet omdat ik ervan houd om vooraf eindeloos te praten.
Maar omdat ik heb geleerd – de harde manier – dat elk bouwwerk begint bij het fundament.
Een architect maakt eerst een blauwdruk. Die blauwdruk zegt: zo ziet het eruit, daarom staat het zo, dit dragen de muren, hier komen de leidingen. En pas dan begint het bouwen.
Een ontwikkelaar die dat niet doet, mist de professionaliteit om iets tot een succes te maken. Ik werk niet meer zonder die professionaliteit. Niet met mijn eigen tijd, en zeker niet met die van mijn klanten.
Als we samenwerken, beginnen we altijd met een Blueprint:
- We snappen eerst wat je nodig hebt en waarom
- We brengen in kaart hoe je nu werkt
- We ontwerpen wat moet veranderen
- We zorgen dat iedereen hetzelfde voor zich ziet
- We maken een plan voor implementatie
- En pas dan beginnen we met bouwen
Het klinkt langzamer. Voelt alsof je niet vooruit komt. Maar het is veel sneller. Omdat we niet maanden bouwen om later te ontdekken dat het als prototype blijft hangen zonder verdere ontwikkeling.
Wat het nu betekent
Die app die niet werd zoals bedoeld? Die was een waardevolle les. Over scope, over duidelijkheid, over wat er allemaal komt kijken naast de techniek. En het mooie is: de app zelf leeft nog steeds. Hij krijgt nu een tweede leven met een andere toepassing, waar hij beter past.
Ik bouw nu anders. Niet omdat ik minder ambitieus ben of minder graag wil bouwen. Maar omdat ik begrijp dat vakmanschap meer is dan goede code schrijven. Het is duidelijkheid over wat je aan het oplossen bent. Het is eerlijk zijn over wat je wel en niet kunt. Het is professionaliteit in het hele proces – van begrip tot implementatie.
En eerlijk? Het voelt beter. Het voelt als écht vakmanschap in plaats van alleen technisch knap werk. Als iets maken dat écht het juiste probleem oplost, in plaats van iets maken dat technisch indrukwekkend is maar misschien het verkeerde probleem aanpakt.
Eerst het fundament, dan bouwen.
Elke keer. Altijd. Geen uitzonderingen.
Dat is geen beperking. Dat is de enige manier om iets te maken dat echt werkt.
