Hoe je als startup een geweldige SaaS-app bouwt met een beperkt budget

Een focus op speed-to-market levert, gezien de beperking van een klein budget (tenzij je net de loterij hebt gewonnen), een zeer pragmatische, soms zelfs opportunistische houding op.

Ditzelfde opportunisme levert echter ook wat uitdagingen op als het gaat om het neerzetten van een goed fundament voor je SaaS-app.

Je kunt, mits je je bewust bent van deze dynamiek en de gevolgen daarvan, heel lean en pragmatisch zijn en toch een fantastische eerste indruk maken met je SaaS-MVP.

Als Chief Technology Officer (CTO) heb ik met talloze vroege startups gewerkt, en vele daarvan worstelden met tech-issues.

Ik zal mijn bevindingen groeperen in Proces, Product en Mensen: 

1. Proces

Als je lean bent heb je natuurlijk ook niet heel veel tooling nodig om je bedrijf te managen. Dure projectmanagement-, CRM- of financiële software zijn echt een brug te ver, maar enige structuur moet je wel hebben, met name op taak-, workflow- en kennismanagement.

Let wel: documenten opslaan in mappen is geen kennismanagement

Om als team de neuzen in één richting te krijgen is het goed een kennismanagement tool te gebruiken, liefst eentje die het ultra-simpel en productief maakt om inhoud te schrijven en te delen. Voorheen zou ik gezegd hebben ‘gebruik een Wiki’, maar vergeleken met wat er inmiddels op de markt is, voelt een Wiki stroperig en onhandig aan.

Persoonlijk ben ik erg gecharmeerd van Nuclino. Nuclino geeft direct, gefocust content management, waarbij productiviteit op één staat. Alles wat je schrijft of toevoegt staat direct live (voor je team), interne links is te eenvoudig voor woorden en plaatjes, videos en diagrammen sleep of plak je zonder enige moeite.

Er zijn inmiddels genoeg van dit soort tools die het mogelijk maken dat een team de neuzen één kant op heeft (en houdt) als het gaat om alles wat belangrijk is in het runnen van een startup en het ontwikkelen van een strategie.

Wat je echter niet moet vergeten is dat het gebruik van kennismanagement tools een mindset verandering met zich meebrengt: je teamleden zullen moeten loskomen van vastgeroeste gewoonten als het aan elkaar sturen van mailbijlagen, of documenten opslaan in  SharePoint/OneDrive/Google Drive/Dropbox folders en elkaar links sturen.

Ik heb met zoveel startups, scaleups en ISV’s gewerkt die toegaven dat hun interne kennisdelen een nachtmerrie was, dat ik zonder meer kan zeggen dat een goede kennismanagement tool gebruiken een enorm verschil kan maken.

Prioriteiten

Als je lean wilt zijn betekent dit dat je strict moet zijn in al je besluitvorming om uiteindelijk uit te komen bij je product release:

Zoals Dwight Eisenhower zei: “What is important is seldom urgent and what is urgent is seldom important.”

“Urgent tasks are things that you feel like you need to react to: emails, phone calls, texts, news stories. Meanwhile, in the words of Brett McKay, “Important tasks are things that contribute to our long-term mission, values, and goals.”

Separating these differences is simple enough to do once, but doing so continually can be tough. The reason I like the Eisenhower Matrix is that it provides a clear framework for making the decisions over and over again. And like anything in life, consistency is the hard part.” (bron)

2. Product

Waarde Bouwen

Wat ik tegen iedere startup en scaleup zeg is: focus op waar de waarde-opbouw in je bedrijf zit. Gemakkelijker gezegd dan gedaan, maar toch, zo moeilijk is het nu ook weer niet: Het opbouwen van intellectueel eigendom (IP) en het denken in termen van een exit strategie zouden cruciaal moeten zijn in iedere fase van besluitvorming in startups en scaleups.

Zo simpel kan het zijn: de vraag : “draagt dit bij tot onze IP?” dwingt je tot een antwoord over wat je moet doen of laten, bouwen of inkopen, enzovoorts.

Ik herinner me een startup waar één ontwikkelaar 6 maanden aan een eigen PDF-generator-module heeft gewerkt, voor rapportjes die per mail verstuurd werden. Niet eens iets wat de kern van hun product raakte.

Nu zijn er honderden SaaS services voor PDF generators en open source PDF-generator-modules die mogelijk hadden voldaan, maar deze ontwikkelaar had of niet voldoende onderzoek gedaan, of vond dat hij het beter kon. Hoe dan ook, de vraag “draagt dit bij tot onze IP?” had direct met “nee!” beantwoord kunnen worden, als hij gesteld was.

De effecten van IP-gebaseerde besluitvorming kunnen dramatisch zijn: bedenk maar eens wat voor mooie dingen er allemaal in 6 maanden gebouwd hadden kunnen worden!

Kortom, build-or-buy besluitvorming zou altijd gedreven moeten worden door IP-denken.

Architectuur

Ik weet dat ik hiermee nou niet per se iets heel populairs zeg, maar mijn advies aan jonge startups is altijd geweest om architectuur voorrang te geven boven implementatie.

“If you think good architecture is expensive, try bad architecture” — Brian Foote and Joseph Yoder

Ik weet het, ik kom uit de Enterprise Software-hoek, maar architectuurontwerp wat initiële focus geven (misschien met wat externe hulp) is altijd een goed idee, en het zal zeker pijn (en geld) besparen in een latere fase.

Natuurlijk wil je, met je time-to-market focus, niet vervallen in over-architecting, maar als je wilt bijdragen aan het succes na de eerste lancering van je product is het goed om een aantal architectonische zaken in ogenschouw te nemen:

– Veilige en compliant data opslag (denk bijvoorbeeld aan GDPR/AVG)
– Multi-tenancy implementeren
– Operationele performance en schaalbaarheid
– Uitbreidbaarheid

Alles Meten

In de “Lean” methodologie is efficiëntie leidend, zoals we besproken hebben. Dit betekent in principe dat je niets onnodigs bouwt, en je vervolgens aanpast aan de hand van metingen.

Daarvoor moet je dus zoveel mogelijk data verzamelen rondom het gebruik van de software, zelfs in de prototype- of interne bèta-fase.

Software genoeg die daarbij kan helpen, en het kost allemaal weinig moeite, dus er is geen excuus om niet data-driven te zijn:

• New Relic
• Application Insights (Azure)
• CloudWatch (AWS)

De Voordelen van moderne cloud platforms

Zoals ik in eerdere artikelen heb gezegd heeft de cloud het software-ontwikkelings-paradigma behoorlijk op zijn kop gezet. Letterlijk ieder aspect van softwareontwikkeling is door met name Native Cloud voorgoed veranderd:

Dit betekent dat je nog steeds lokaal een applicatie kunt bouwen en die zonder veel poespas naar de cloud kunt tillen. Of je dat ook moet willen is een tweede.

Cloud-niveaus

Cloud loopt al een tijdje mee. Ietwat simplificerend kunnen we stellen dat de eerste migraties naar Cloud simpelweg virtual machines (VM’s) verplaatsten naar andere hardware (IaaS).

De volgende stap was containerisatie: kleinere onafhankelijke werkeenheden (zgn. containers) die uitgerold konden worden en een groot deel van het operating system (OS) abstraheerden (CaaS).

Natuurlijk gingen de cloud-providers al snel aan de slag met het aanbieden van allerlei diensten die door hen gehost (en beheerd) werden, waardoor je in staat gesteld werd om snel en eenvoudig volledige applicaties en data uit te rollen die op die diensten draaiden (PaaS), en de laatste stap is geweest om vrijwel ieder aspect van de onderliggende applicatie, en elk aspect van de lagen daaronder, weg te abstraheren (FaaS – ofwel Serverless).

In termen van de aspecten van de totale oplossingen die je als startup zelf moet beheren, kun je het op deze manier bekijken:

Zoals je ziet: hoe hoger het cloud-niveau, hoe minder je zelf hoeft te onderhouden en managen. Vanuit een Lean-benadering is het niet zo moeilijk om in te zien dat de PaaS en FaaS (of Serverless) niveaus ervoor zorgen dat je je als startup vooral kunt focussen op je product features, en vooral niet lastig gevallen wordt door technisch gerommel met opschalen, back-ups, fail-over, beveiligingspatches, OS updates, enzovoorts.

Lean Tech

Bij mijn PDF-generator voorbeeld had ik het er al over, maar kijkend naar alles wat je bij het bouwen van je SaaS product tegen komt waar een build-or-buy beslissing aan vast zit, loont het zeker de moeite om tijd te besteden aan het vinden van services en/of open source of commerciële libraries die specifieke taken in je app kunnen afhandelen.

Vind je services via Programmableweb.com, Apis.io of Rapidapi.com, zoek libraries en best practices op Github.com en Nuget.org en als je niet direct alle antwoorden hebt, vind die op Stackoverflow.com.

Bootstrappen

Niemand bouwt complexe SaaS-systemen meer vanaf een leeg canvas. Er zijn op ieder gebied van app-bouw, van HTML/CSS tot Cloud-architectuur-patronen bootstrappers te vinden, kant-en-klare standaardinrichtingen met allerlei voorbeeldcode.

Het Mobiele Dilemma

Ik kan lange discussies hebben over web en mobiel softwareontwikkeling met mensen die ik tegenkom. Afhankelijk van hun core business zullen ze me proberen te overtuigen dat native mobile apps superieur zijn aan alles wat voor het web gebouwd is en op een smartphone draait, of ze zullen zeggen dat native app development op sterven na dood is en dat de gecombineerde evolutie van web standaarden en smartphones native development overbodig gaat maken.

Als CTO doet mijn persoonlijke mening er niet per se toe. De beslissing om een extra ontwikkelproces op te starten om een native app te bouwen heeft een gigantische impact op startups:
1. Extra mensen nodig
2. Complexer feature-management
3. Vertraging van de uitrol
4. Toenemende complexiteit van de software-ondersteuning

Kort gezegd zal ik startups in een vroege fase afraden om ook maar te denken aan een mobiele app, tenzij het product daardoor een veel betere market-fit zou krijgen (bijvoorbeeld omdat de persona’s met name mobiel toegang willen).

Later in het proces, wanneer bijvoorbeeld een investeerder is binnengetrokken, zijn native apps te heroverwegen, maar wel met volledige inachtneming van de consequenties. Ik heb genoeg scaleups gezien die een native app hebben laten ontwikkelen die ook makkelijk als een hybride app (met één web-frontend dat ook in de mobile app wordt gebruikt) had kunnen worden ontwikkeld, en waarbij het betreffende bedrijf vervolgens last had van alle 4 hierboven genoemde problemen…

3. Mensen

Tot slot, het managen van het menselijk kapitaal waarmee je een product in de markt wilt zetten, dat is altijd één van de lastigste aspecten van het runnen van een startup.

Er is geen magische formule, geen oplossing die altijd werkt, want het hangt allemaal af van je opzet. Had je alleen een commercieel idee of ben je in staat om de meeste technische uitdagingen zelf te overzien? Wie zit(ten) er met jou in? Heb je technische medeoprichter? Of heb je partners of freelancers die behoorlijk loyaal zijn of die willen investeren op basis van winstdeling? Enzovoorts…

Outsourcing

Het is ontzettend eenvoudig om een ontwikkelshop in de arm te nemen die je eisen en wensen vertaalt in een oplossing. Met wat filteren op basis van hun portfolio kom je een aardig eind. Niet veel moeilijker is het om te zien of de gekozen partij zich committeert aan professionele standaarden, maar waar het vaak toch nog misgaat is in de dagelijkse routine: de modus operandi van een extreem agile, lean (en dus adaptieve, data-driven) SaaS-product startup is in de praktijk voor dit soort outsourced partijen een stuk moeilijker te managen dan het uitvoeren van een traditioneel waterfall project.

Interne Product Owner

Een oplossing voor dit probleem is om lokaal een Product Owner (PO) aan te stellen of in te huren. Deze kan dan als brug dienen naar het outsourced team. Aan de ene kant is deze PO betrokken bij wat je als startup probeert te bereiken, maar hij/zij is ook in staat om vragen en onduidelijkheden van de developers te vertalen in klare taal. Kortom, win-win.

Ik heb outsourcingstrajecten heel vaak zien mislukken. Met een interne PO worden de risico’s daarop een stuk kleiner.

Assistentie op Technische Strategie

Als jonge startup moet je echt heel veel geluk hebben om er iemand bij te hebben die in SaaS tech een track-record heeft en uit ervaring spreekt.

Iemand aanstellen met dit soort ervaring is bijna onmogelijk vanwege de kosten (opnieuw, tenzij je enorm gelukkig bent en iemand vindt die zich via aandelen of winstdeling wil laten betalen).

Het loont echter om echte ervaring in huis te trekken, al is het maar voor een paar uur per week, zelfs als het alleen maar is om technische plannen te valideren, je app te evalueren in termen van optimale cloud fit, of te assisteren bij het vinden van de juiste tech-partners.