Start-ups komen door de manier waarop ze hun propositie in de markt willen zetten vaak technisch in de problemen. Dit stuk beschrijft enkele van de problemen en hoe ze te voorkomen.
Als Interim cto raak ik vaak betrokken bij start-ups die al redelijk onderweg zijn met een outsourced bedrijf dat een mvp (minimum viable product – zie ‘The Lean Startup’ – Eric Ries) voor hen bouwt.
In mijn ervaring hebben veel start-ups een geweldig idee, maar maken ze vaak de fout om te snel naar een outsourced partner te zoeken die de mvp wel eventjes voor ze bouwt. Op zichzelf niet erg, maar er kunnen wel problemen optreden. Hier zijn er een paar, en hoe je ze voorkomt.
1. Gebrek aan wederzijds begrip (ook wel bekend als ‘lost in Translation’).
Je hebt als start-up veelvuldig overleg gehad met de bouwer, maar de opgeleverde software is niet echt volgens verwachting. Hoezeer je de eisen ook probeerde over te brengen, het blijkt dat de bouwer het niet goed genoeg begrepen heeft, of dat er blijkbaar iets is ‘blijven steken’ bij de overdracht. Het resultaat is een langer traject tot lancering, en hogere kosten.
2. Onvoldoende schaalbaarheid.
Je komt er bij de lancering achter dat het ontwikkelde product, hoe leuk het ook werkt, onvoldoende schaalt bij die plotselinge belasting na je succesvolle marketingcampagne. Hoogst frustrerend om op die manier slachtoffer van je eigen succes te worden.
Hoe is dat zo gekomen? Misschien heeft het ermee te maken dat de bouwer jouw mvp niet echt ziet als product, maar als project. Ze kijken simpelweg niet naar een lange termijn levenscyclus en zijn daarom niet gefocust op het bouwen van een solide, flexibele en duurzame architectuur die bovendien meeschaalt met je groei, omdat ze geen eigenaar zijn.
Deze situatie is zo mogelijk nog erger, want de kern van je software zou wel eens inherent ongeschikt kunnen zijn.
3. Onvoldoende platform omarming.
Cloudplatform-selectie is niet altijd een volledig objectief proces. Het kan bijvoorbeeld zijn dat je bestaande commitments hebt, of op de één of andere manier gesponsord wordt. Of je partnert met bedrijven die aan een bepaalde cloud gelieerd zijn, of er een persoonlijke connectie mee hebben.
Bij de keuze van een bedrijf dat je apps gaat bouwen zijn er echter vaak andere krachten aan het werk. Het vreemde hierbij is dat deze vaak volledig onafhankelijk blijken te zijn van de cloud selectie. Raar maar waar.
Ervaring
Een ontwikkelbedrijf dat geen of weinig ervaring heeft met de specifieke aspecten van de gekozen cloud is niet in staat om de volledige rijkdom van dat cloudplatform te omarmen. Of ze zijn zo gewend om dingen op een bepaalde manier te doen dat ze ‘vergeten’ te kijken naar de native cloud alternatieve aanpak. Als dat vervolgens betekent dat ze daarvoor een ‘non-managed’ dienst moeten gebruiken en zo dus niet optimaal van de kracht van de cloud profiteren, nemen ze dat op de koop toe. Tco is immers niet hun probleem.
Het eindresultaat is dan een oplossing die niet ideaal is, met componenten die niet automatisch schalen en waar je zelf onderhoud aan hebt (non-managed). Of met componenten die ‘buiten’ die cloud staan, waardoor je extra ‘egress’-kosten hebt (data transfers naar buiten de cloud kosten vaak veel extra).
Tenslotte is het nog zo dat, wanneer je bijvoorbeeld profiteert van sponsoring zoals geboden wordt via Microsoft BizSpark, de verkregen sponsoring niet geldt voor services buiten die cloud. Wéér extra operationele kosten dus, maar wéér niet zo spannend voor de bouwer….
Conclusie
Je mvp vormt de eerste indruk die je doelgroep van je product krijgt. Je weet wat ze zeggen van eerste indrukken…
Het is cruciaal dat start-ups een ervaren cto (chief technical officer) in de beginfase van een mvp bij de plannen betrekken, om dit soort fouten te voorkomen. Een cto kan de intermediair zijn die je functionele eisen kan vertalen, zodat een ontwikkelbedrijf veel minder ruimte heeft voor eigen interpretatie, de architectuur gebouwd wordt met schaalbaarheid in gedachten, en modulair en duurzaam is. Daarnaast kan de cto ervoor zorgen dat native cloud features goed gebruikt worden.
Over het algemeen leidt gebrek aan kennis van een cloud ecosysteem tot hogere servicekosten, dus investeren in een optimaal performante kosten-efficiënte infrastructuur is zeer gewenst.
(Dit artikel is vertaald uit het Engels en is eerder verschenen in LinkedIn Pulse, op 23 mei 2017)
