Het inschakelen van een softwarepartner kan voor een jonge startup een zeer verleidelijke aanpak zijn. Zeker als je geen technische co-founder hebt (of een technisch adviseur), is de stap naar zo’n bureau snel gemaakt. Je beschikt immers niet over de technische knowhow, laat staan over een ontwikkelteam, maar je wilt wel snel de markt op.
Deze agencies staan je dan met open armen op te wachten, en je zult je heel erg op je gemak voelen, wetende dat zij je gaan ‘ontzorgen’. A match made in heaven. Of toch niet?
Verborgen problemen
Als fractional cto heb ik de laatste zeven jaar veel van dit soort bedrijven geholpen, zoals startups die hun software eerst volledig ge-outsourced hadden, maar vervolgens (met wat funding) wilden gaan insourcen. Maar ook piepjonge startups met enkel nog ‘het idee’, maar met de tegenwoordigheid van geest om er eerst een expert bij te betrekken.
Al deze ervaringen verwerk ik regelmatig in posts op LinkedIn, maar ik denk dat het goed is de boel eens structureel op te sommen en zo veel leed te besparen bij startups. Want het zijn altijd de startups die de dupe worden. Op den duur.
Wat is er aan de hand? Nou, heel veel. En verreweg de meeste SaaS-startups komen er veel te laat achter.
1. Waar jij PRODUCT denkt, zien ontwikkelaars een PROJECT
Denk daar maar eens over na. Iedere lijst aan features die je over de schutting gooit, leidt gewoon tot een projectje om het voor elkaar te fietsen. Niets minder, maar ook zeker niets meer.
2. Domein, product en marktdenken is volledig losgekoppeld van softwareontwikkeling
Dit vergt wat uitleg: een ideaal SaaS-bedrijf heeft een doorlopende, continue ontwikkeling die een verlengstuk vormt en nauw geïntegreerd is met de productvisie.
Lean, agile ontwikkelen, met name met het gedachtegoed van design thinking, is zeer ver te zoeken als je een extern softwarebedrijf inschakelt. De lijnen worden lang, schakelen/itereren/aanpassen in het ontwikkelproces wordt als onwenselijk gezien.
3. Hun voornaamste zorg is het optimaliseren van de winst
Ze zijn niet geïnteresseerd in het slim afsnijden van bochten voor een eerste minimum viable product, noch in het creëren van herbruikbare blokken, abstractielagen, security of data-architectuur.
4. Documentatie is niet hun prioriteit
Of het nu gaat om genomen stappen (architectuurbeslissingen bijvoorbeeld), processen of onderzoek, het is gewoon niet hun prioriteit. Tenzij je hier natuurlijk specifiek om vraagt. Maar verwacht dan een gepeperde extra rekening, want ja, ‘documenteren kost zoveel extra tijd als je lekker snel wilt ontwikkelen…’
5. Als non-technical founders kun je alleen op geleverde functionaliteit beoordelen
Je moet de softwarebouwer maar op z’n blauwe ogen vertrouwen, want je kunt simpelweg niets zeggen over de softwarekwaliteit, robuustheid, schaalbaarheid, onderliggende architectuur, etc.
6. Je bouwt minder waarde/IP op
Als startup bouw je geen overdraagbare kennis en IP op over (de technische kant van) je product. Met andere woorden, je krijgt minder waardeopbouw in je startup, omdat je de volledige technologie hebt uitbesteed.
Dit is een groot risico en zal vaak negatief worden beoordeeld als je financiering probeert te krijgen, omdat een investeerder natuurlijk uitgebreid gaat kijken hoe de kennis belegd is binnen de organisatie.
Indien er een technische due diligence wordt gedaan, ben je natuurlijk helemaal overgeleverd aan de goden, als non-technical founders.
7. De stack wordt je opgedrongen — zonder dat je het merkt
De software stack (de talen, het platform, de client- en serverside frameworks) die het softwarehuis gebruikt, de tooling, de hostingpartij waar ze mee partneren: allemaal zaken waar ze het liefst niet eens over praten, want het is zo lekker efficiënt als het voor al hun klanten exact hetzelfde is.
De gekozen software stack is vaak verweven met de ontstaansgeschiedenis van het softwarehuis, dat door allerlei toevalligheden een combinatie heeft zien ontstaan, en daarop verder gebouwd heeft, nieuwe ontwikkelaars aangenomen heeft, etc.
Als niet-technische startup founder ben je daar dus, nietsvermoedend, aan overgeleverd. En het is pas later dat je ermee geconfronteerd wordt. Alleen al dit aspect kan tot enorme herinvesteringen leiden.
8. Je software wordt in een keurslijf gepropt — het hunne
Omdat de meeste ontwikkelingsbureaus codefabrieken zijn, is de kans groot dat ze hun eigen ontwikkelsjablonen, patronen, bibliotheken en best practices zullen gebruiken.
Deze zijn vaak zorgvuldig (intern) gedocumenteerd, en goed overdraagbaar naar hun vaak snel verlopende personeel. Dit maakt dat veel van dit soort zaken niet snel wijzigt, want dat kost de organisatie simpelweg te veel in bijwerken van documentatie, trainingen van nieuw personeel, enzovoorts.
9. Je hebt je eigen spullen niet in eigen beheer
Het ‘ontzorgen’ gaat vaak zo ver dat de volledige broncode van je eigen software, en het gehele zogenaamde Application Lifecycle Management (ALM), de tooling en historische data over hoe de applicatie gebouwd, getest, uitgerold en beheerd wordt, ‘weggemanaged’ zit bij de softwarepartner.
In de contractuele bepalingen staat natuurlijk wel dat het van jou is, maar er vrijelijk over kunnen beschikken, een expert inhuren en laten meekijken, overdragen, het zijn allemaal complexe zaken waar onnodige tijd aan verloren gaat, mocht het aan de orde komen.
10. Loslaten gaat gepaard met emotie
Hoe vreemd ook, er komen emoties los bij (de mensen van) het softwarebedrijf, zo gauw er gemorreld wordt aan de klus die men ooit heeft aangenomen. Misschien niet bij de accountmanager die het klappen van de zweep natuurlijk allang kent (uiteindelijk is ieder project eindig), maar wel bij de betrokkenen die zich onwillekeurig toch een beetje ‘eigenaar’ zijn gaan voelen van de code.
Die moeite met loslaten kan zich vertalen in een stoppen van de ‘meewerkstand’, een subtiel andere houding die onprofessioneel te noemen is, maar die ik helaas vaak tegenkom. Daardoor duren processen ineens veel langer, worden zaken niet ‘van harte’ gedaan en wordt er slecht op e-mails gereageerd. De zaken kunnen zelfs wat minder subtiel en zelfs vijandig worden.
Wat dan? Niet met softwarepartners werken?
Het is te kort door de bocht om dan maar te zeggen dat je nooit met een softwarepartner moet gaan werken. Deze bovenstaande observaties geven wellicht al wat houvast om het gesprek om een andere manier aan te gaan: kom, we gaan samenwerken, maar we willen wel een aantal goede afspraken maken…
Ja, het helpt om aan te geven dat toekomstige overdracht naar een insourced team essentieel is. Omdat we het, als we denken aan softwarepartnerships, vaak over langere termijnen hebben, zijn eenmalige afspraken slechts het begin van een oplossing.
Een expert in de arm nemen om je te laten vertegenwoordigen, is de consensus die ik langzaam zie ontstaan. In ieder geval in de discussie met mijn vakgenoten, die vaak ingevlogen worden door startups waar ‘iets aan de hand is’.
Zo heb ik zelf nogal wat startups in de problemen zien komen, en mocht ik de puinhoop in de keuken opruimen — of een nieuwe keuken bouwen. De meeste van deze startups gaven aan dat ze heel lang geen idee hadden van de problemen waarmee ze te maken zouden krijgen.
Hoe kan een expert dan helpen?
Voorkomen is beter dan genezen. Het hangt natuurlijk af van de fase waarin de expert erbij gehaald wordt.
Voorkomen
- De juiste softwarepartner selecteren. Eentje die gespecialiseerd is in het werken met jonge SaaS-bedrijven, en snapt dat deze, als ze groeien, zelfstandig verder willen, en voordat ze zover zijn, een technische tussenpersoon hebben.
- De Application Lifecycle Management (ALM) allereerst volledig in eigen beheer brengen, en de partner daarop laten werken.
- Meehelpen om een passende, toekomstbestendige architectuur op te zetten, waarmee de startup op ieder moment zonder de partner verder kan.
Genezen
- De zakelijke doelstellingen van de startup centraal stellen.
- Bedrijfsdoelstellingen vertalen naar technische roadmaps.
- Zorgen voor invoer van testbaarheid en automatische tests in de software.
- Vanuit regelmatig stakeholder-contact werken aan stabiel productdenken, om te zorgen voor minder projectachtige ad hoc aanpak.
- Coachen en uitdagen van de ontwikkelaars van partners met best practices voor SaaS.
- Kwaliteitsborging.
- Focus op continue kennisvastlegging.
Afscheid nemen
- Voorzichtig bij de softwarepartner inweken dat de samenwerking afgebouwd wordt, omdat de startup zelfstandig wil worden.
- Inzetten op de oplevering van goede highlevel documentatie van design/architectuur/flows/infrastructuur.
- In kaart brengen van afhankelijkheden, bijvoorbeeld naar gedeelde softwarebibliotheken van de softwarepartner.
- Een intern team opzetten, te beginnen met een ervaren Tech Lead.
- Zorgvuldige overdracht aan het intern team faciliteren, daarbij de risico’s minimaliserend.
Kosten
Het zal duidelijk zijn dat de keuze om er, naast een softwarepartner, ook nog een expert bij te halen, in eerste instantie de kosten lijkt te doen stijgen. Het tegendeel is echter waar, want een ervaren tussenpersoon zal zich op allerlei manieren terugverdienen:
- Betere architectuurbesluiten.
- Slimmere cloudopzet, met lagere operationele kosten en minder beheer.
- Betere build-or-buy-beslissingen.
- Efficiëntere bouw van componenten.
- Efficiënter proces.
- Betere communicatie, en minder lost in translation met de softwarepartner.
- Soepeler overdracht naar een insourced team.
- Minder desinvestering.
- Duurzamere keuzes in technologie.
Het hoeft op zich geen probleem te zijn om je software in eerste instantie volledig uit te besteden, maar wees je bewust van de valkuilen en de tijdelijkheid van de samenwerking (zelfs als je die nog niet kunt overzien). En betrek er liefst iemand bij die als technisch tussenpersoon vaker startups heeft begeleid, weet hoe softwarehuizen opereren, en jou naar hen toe kan vertegenwoordigen.
Je zult er veel kosten en ellende door besparen, en er later dankbaar voor zijn.
.
.
