12 tips voor SaaS ontwikkeling bij een startup

1. Begin met een MVP
2. Kies de juiste programmeertaal en platform
3. Beslis waar en hoe je het wilt gaan hosten
4. Kies de juiste frameworks voor jouw SaaS om op te ontwikkelen
5. Maak gebruik van standaard componenten
6. Zorg voor een OTAP straat
7. Zorg voor goede geautomatiseerde security tests vanaf het begin
8. Kies de juiste softwarepartij
9. Kies de juiste ontwikkel methodiek
10. Bespreek je ideeën met iedereen die wil luisteren
11. Vraag regelmatig advies aan je software partner maar maak je eigen beslissingen
12. Zorg voor budget voor de doorontwikkeling van jouw SaaS

Starten met een Minimal Viable Product is iets wat veel gedaan wordt bij SaaS producten. Om eerst een proof of concept te hebben om vervolgens op door te ontwikkelen. Een MVP is een slimme keuze ook om de investering vooraf te verkleinen. Tevens kan je met een MVP al flink insteken op marketing. Wij raden onze klanten overigens altijd aan om al te beginnen met ‘verkopen’ voordat een product klaar is. Dit is bij een MVP ook zo. Je krijgt namelijk al waardevolle feedback vanuit klanten en je kunt ook polsen wat de verwachtingen en de eisen zijn aan jouw SaaS.

Meestal wordt deze keuze gemaakt door het bedrijf wat de software gaat ontwikkelen. Het is echter als bedrijf of eigenaar van de software belangrijk om bij deze keuze stil te staan. Als je niks van software ontwikkeling weet dan ga je natuurlijk snel uit van de adviezen van je ontwikkel partner.
De meeste bedrijven hebben zo hun voorkeur over de te gebruiken programmeertaal. Deze zijn meestal gebaseerd op wat ze op school hebben geleerd en waar ze de meeste ervaring mee hebben. Dit is logisch. Meestal zijn er ook nog vooroordelen over andere talen waar ze geen kennis van hebben of waar ze mogelijk een slechte ervaring mee hebben gehad en ze het daarna nooit meer gebruikt hebben.
En dan zijn er nog fanatiekelingen die bepaalde benchmarks raadplegen waarin wordt geopperd dat een bepaalde taal iets sneller is dan een andere taal.
Waar echter bijna nooit rekening mee gehouden wordt zijn de gevolgen van zo’n keuze.
Sta eens stil bij het volgende: je hebt gekozen voor een software partner die voor jou een programma ontwikkeld in een programmeertaal zoals Ruby.
Of dat Ruby een geschikte keuze is is niet altijd objectief vast te stellen. Echter is het wel belangrijk om te kijken of er ook andere bedrijven zijn die deze taal beheersen. Het zou namelijk kunnen dat jouw software partner failliet gaat of dat ze niet aan jouw wensen kunnen voldoen. Indien dat zou gebeuren moet je op zoek naar een ander bedrijf dat de software verder kan uitbouwen en onderhouden.
Als je op moment erachter komt dat Ruby ontwikkelaars zeer schaars zijn en dat het geen makkelijke taal is om te leren dan kan je tegen grote problemen aanlopen.
De continuïteit van je software loopt dan groot gevaar. Geen wenselijke situatie dus.
Ook kan het zijn dat je een programmeertaal hebt gekozen die alleen door universiteiten aangeleerd wordt waardoor de software ontwikkelaars erg duur zijn. Of er kan een programmeertaal gekozen zijn die slechts op 1 platform kan draaien. Dan ben je niet alleen afhankelijk van de programmeertaal voor de ontwikkeling maar ook van het onderliggende platform voor de hosting en onderhoud.
Bedenk dus goed wat de voor- en nadelen zijn op het moment dat er voor een bepaalde programmeertaal gekozen wordt. Jouw belangen hierin zijn niet altijd dezelfde als het bedrijf die het gaat ontwikkelen.

Als je een SaaS wilt maken dan moet de webapplicatie ook ergens online te benaderen zijn. Als je hier mee aan de slag gaat. Als je je gaat oriënteren denk dan aan de volgende punten.

Zodra er gekozen is voor een programmeertaal is het slim om een ontwikkel framework te kiezen. Hierbij gelden grotendeels dezelfde aandachtspunten als bij het zoeken van een programmeertaal. Echter is een framework niet zo ingrijpend als een programmeertaal. Wel zijn er grote verschillende tussen verschillende frameworks en waar ze voor ingezet kunnen worden.

Nadat er een keuze is gemaakt voor een framework zijn er een aantal standaard componenten die gebruikt kunnen worden. Hoewel deze verschillen per framework zijn deze meestal gericht op gebruikersbeheer, authenticatie en autorisatie.

Naast de standaard componenten die in een framework aanwezig zijn hebben de meeste frameworks een grote community die ook standaard componenten ontwikkelen en ter beschikking stellen. Zo zijn er standaard componenten voor duizenden functies in software. Denk dan aan bijvoorbeeld agenda functionaliteiten, standaard API’s en admin functionaliteiten.

Het feit dat er veel standaard componenten zijn wil niet zeggen dat er niets meer ontwikkeld hoeft te worden. Veel webapplicaties hebben specifieke functionaliteiten nodig die niet te vinden zijn in standaard componenten. Ook zullen veel standaard componenten niet volledig gemaakt zijn voor de functionaliteiten die nodig zijn voor een nieuwe applicatie. Hiervoor zullen standaard componenten nog geconfigureerd of aangepast moeten worden.

Gebruik maken van standaard componenten is aan te raden waar mogelijk. Het scheelt veel ontwikkeltijd en de meeste standaard componenten zijn doorontwikkeld zodat er meestal geen bugs meer in zitten en ze zijn meestal ook grondig getest op beveiligingsproblemen. Indien er dus een standaard component bestaat voor een bepaalde functie in je applicatie is het meestal aan te raden om deze ook te gebruiken.

Voordat een applicatie live gaat heb je nog geen complete OTAP straat nodig maar zodra je applicatie in gebruik is genomen is het slim om direct een OTAP methodiek te implementeren.

OTAP staat voor Ontwikkel, Test, Acceptatie en Productie. Eventueel kan je deze nog uitbreiden met een failover ofwel een Uitwijk mogelijkheid. OTAP is de Nederlandse benaming voor de engelse DTAP methode.

Met een OTAP methode heb je de mogelijkheid om nieuwe functionaliteiten te ontwikkelen en te testen voordat de gebruikers van de applicatie deze functies erbij krijgen. Op deze manier kan je de meeste bugs vooraf al uit je systeem halen zodat je klanten hier geen last van hebben. Uiteraard neemt dit wel tijd in beslag, zowel voor de ontwikkelaars als de testers.

Zodra je een actieve applicatie hebt ontkom je niet meer aan een OTAP methodiek. Als je functionaliteiten gaat implementeren die nog niet getest zijn zal de helpdesk extra capaciteit nodig hebben om alle support vragen met betrekking tot de bugs af te handelen. Tevens is het mogelijk dat je gebruikers gaan klagen over de vele bugs die je applicatie bevat. En dat updates ook veel bugs bevatten is meestal geen positieve ervaring voor je gebruikers. Met een OTAP methode kan je dit grotendeels afvangen.

Als je met een SaaS start zal je waarschijnlijk gegevens op gaan slaan. Omdat de gegevens meestal niet jouw eigendom zijn is het belangrijk dat je de gegevens op een adequate wijze beveiligd. In een framework is meestal het een en ander mogelijk qua autorisatie en authenticatie. Alles wat echter wordt geïmplementeerd moet ook getest worden op veiligheid. Dit kan je met de hand (laten) doen maar je kunt er ook voor kiezen om periodiek een geautomatiseerde security scan uit te laten voeren. Op die manier kan je bijvoorbeeld een groot deel van de OWASP top 10 checken.

Ook moet je bij iedere ontwikkeling beveiliging voorop stellen. Ga hier echter op een praktische manier mee om. Het is namelijk onmogelijk om een applicatie te maken die niet gehackt kan worden. Het is echter niet de bedoeling dat je de voordeur open laat staan. Dat voorkom je door regelmatig een security scan uit te laten voeren.

Wat is regelmatig vraag je je dan af. Dit hangt ook af van ontwikkel cyclus. Als je dagelijks updates doorvoeren dan is het slim om wekelijks een scan uit te laten voeren. Als je echter maar 1x per maand een update uitvoert heeft het geen zin om wekelijks een scan uit te laten voeren.

Het is belangrijk dat je de scan uit laat voeren door een extern bedrijf en niet door het bedrijf die de software ontwikkeld. Zo krijg je een onafhankelijk oordeel en je kunt ook meer kennis met betrekking tot security binnen halen.

Er zijn verschillende redenen om een een partnerschap aan te gaan met een softwarepartij. Daarbij horen verschillende overwegingen.

Als het om ontwikkelmethodes gaat kom je voortaan vooral agile en scrum tegen. Dit zijn echter niet de enige of de beste ontwikkelmethodes die er zijn. Als je je gaat oriënteren op ontwikkelmethodes zijn er eigenlijk 3 grote stromen binnen software ontwikkeling:

• Iteratief
• Waterval
• Spiraal

Als je een idee hebt probeer dan zoveel mogelijk mensen hierover te spreken. Je zult hierdoor meerdere inzichten krijgen en mogelijk krijg je zelfs al feedback waar je zelf nog niet over had nagedacht. Er zijn veel mensen die een idee hebben en dit voor zich houden. Ze zijn bang dat iemand anders met het idee aan de slag gaat. Dat zou mogelijk kunnen zijn. Het is alleen moeilijk om een idee uit te gaan werken zonder er over te praten. Ook zal je product ooit verkocht moeten gaan worden en ook dan kan iemand anders zijn versie ervan maken. Bedenk je ten eerste dat een idee niets waard is. Als je het idee niet ten uitvoer gaat brengen is het een idee en niets meer. Een idee krijgt pas waarde als je er een product of dienst van maakt en dan ook nog succesvol in de markt kan zetten.

Veel ondernemers krijgen een idee niet uitgewerkt. Hier hebben meerdere factoren invloed op. Er kan te weinig budget zijn voor de ontwikkeling ervan, de focus van de ondernemer kan te verspreid zijn waardoor het project niet van de grond komt, de markt kan het product of dienst afkeuren of niet waardevol vinden, de marketing kan een probleem zijn. Zo zijn er nog wel een aantal punten te bedenken waar het fout kan gaan.

Sommige ondernemers komen met hun idee bij ons en vragen ons vooraf om een geheimhoudingsverklaring te tekenen. Wij staan vrijwel nooit open om vooraf een geheimhoudingsverklaring te tekenen. Ten eerste weten we niet of het idee een conflict veroorzaakt met een van onze klanten en als je iets geheim wilt houden dan pak je in onze ogen de marketing al verkeerd aan vanaf het begin. Als je iets gaat maken dan moet je eigenlijk zo enthousiast zijn dat je het aan iedereen wilt laten weten om zo de markt op te warmen en om te polsen of er wel een markt is voor het idee.

Ook denken wij graag mee met onze klanten. Als wij enthousiast worden van jouw idee dan willen we dat ook graag bespreken binnen ons netwerk. Mogelijk komt er dan makkelijker een investeerder aan boord of er zijn mensen die je direct kunnen helpen met bepaalde onderdelen van het project.

Wil je dus dat jouw idee uitgewerkt word en een succes word zorg er dan voor dat je er zoveel mogelijk en zo enthousiast mogelijk over kunt vertellen en luister naar de feedback die je van mensen krijgt. Je hoeft niets te doen met de feedback maar je kunt zeker wel iets doen met de inzichten die je ervan krijgt.

Wij raden altijd aan om een partnerschap aan te gaan met je software partner. Wij zien een partnerschap altijd als gelijkwaardig; je bent namelijk beide een expert op je eigen gebied. Het is dan ook niet slim om je software partner aan te sturen op wat hij moet uitvoeren omdat je niet weet wat relevant voor hem kan zijn. Hiervoor is het wel belangrijk dat je een partner vind die je vertrouwd. Je software partner moet ook iemand zijn die op een afstand naar je product kan kijken. Hij kan aangeven waar je het beste kunt beginnen met ontwikkelen, hoe je de kortste time-to-market krijgt en hoe je belangrijke keuzes kan maken. Je software partner moet niet de beslissingen voor jou nemen maar moet jou wel adviseren over de voor- en nadelen van de keuzes die gemaakt worden. Leg dan ook goed uit aan je software partner waar je naar toe wilt met je SaaS product.

Uiteraard de korte termijn doelstellingen maar ook de langere termijn doelstellingen kan je het beste vooraf al bespreken. Op die manier kan de software partij je adviseren bij keuzes die voor de lange termijn ook relevant zijn en daarmee kan je de impact van sommige toekomstige uitbreidingen simpeler houden.

Als je een idee hebt en dit om gaat zetten in een SaaS weet dan dat je product of dienst waarschijnlijk nog enkele keren opnieuw uitgevonden zal moeten worden. Kijk bijvoorbeeld naar Instagram die begon als app voor fotografen. Ze waren toen niet succesvol en de echte groei kwam toen ze minder gingen focussen op fotografen en meer op de ‘gewone mens’ die toch mooie foto’s wilde maken.

Wij hebben ook meerdere klanten die een SaaS zijn begonnen voor een bepaalde markt en er vervolgens achter kwamen dat er in die markt weinig tot geen kansen lagen. Vervolgens zijn ze de SaaS iets aan gaan passen en omdat ze wel flink op marketing instaken kwamen ze een nieuwe markt tegen die wel behoefte hadden aan hun SaaS oplossing en waar bovendien hogere marges op de licenties te verdienen waren. Zo hebben wij meerdere startups bediend die de eerste 2 tot 3 jaar niet succesvol waren in het verkopen van hun product maar die vervolgens in jaar 3 tot 5 een zeer grote groei hebben gerealiseerd door zich te gaan focussen op een andere doelgroep/markt.

Hierdoor is het niet alleen belangrijk om open te staan voor input van andere maar ook om jouw idee bij te laten sturen door de markt. Een belangrijk punt dat hierbij komt kijken is eigenlijk ook dat je SaaS nooit klaar is met ontwikkelen. Naast uitbreidingen en updates is het ook mogelijk dat je je product aan moet passen zodat de software voldoet voor een andere markt. Zorg ervoor dat je met het maken van je budget dus ook geld overhoud om dit soort aanpassingen en updates te realiseren. Meestal zijn dit niet meer de kosten die je hebt betaald voor de initiële ontwikkeling maar de kosten hiervoor kunnen wel aanzienlijk oplopen naar mate de SaaS aangepast moet worden.

Indien je van plan bent om een SaaS te gaan ontwikkelen denken we graag een keer met je mee. Ook kunnen we je adviseren over bovenstaande punten en we helpen je graag om je product te ontwikkelen. Neem contact met ons op om een afspraak in te plannen.