Definitie
Een tech stack is de verzameling technologieen waarop een applicatie is gebouwd: de programmeertaal, het framework, de database, de hostingomgeving en de tools eromheen. Stapel ze op (vandaar “stack”) en je hebt een beeld van waar de software uit bestaat, welke kennis nodig is om eraan te werken, en wat de implicaties zijn voor toekomstige keuzes.
Voor een webshop kan de stack bijvoorbeeld bestaan uit React (frontend), Node.js (backend), PostgreSQL (database), AWS (hosting) en Stripe (betalingen). Voor een ander platform is het PHP, Laravel, MySQL en een Nederlandse hoster. Beide werken, beide hebben voor- en nadelen, en de keuze bepaalt jaren vooruit waar jouw bedrijf afhankelijk van is.
Waarom het ertoe doet voor MKB
De tech stack van jouw maatwerk-software of SaaS-product bepaalt drie dingen op directieniveau: hoeveel partijen er beschikbaar zijn om eraan te werken, hoeveel onderhoud per jaar te verwachten valt, en hoe makkelijk je later kunt overstappen of integreren. Een exotische keuze met weinig ontwikkelaars in Nederland levert hogere uurtarieven, langere wachttijden en zwaardere lock-in op.
Tegelijk is de meest populaire stack niet altijd de beste keuze. Soms past een nichetechnologie precies bij wat jouw bedrijf doet. De kunst is niet om voor het populairste te kiezen, maar bewust te kiezen, met begrip van de gevolgen op vijf en tien jaar termijn.
Concreet voorbeeld
Een marketingbureau liet een klantportaal bouwen door een bevriende ontwikkelaar in een minder gangbare programmeertaal (Elixir). Snelle oplevering, alles werkte. Drie jaar later vertrok die ontwikkelaar. Bij het zoeken naar een opvolger bleek de Nederlandse markt voor Elixir-ontwikkelaars klein: vier kandidaten reageerden, allemaal met tarieven 30-40% boven het gemiddelde voor PHP of JavaScript-ontwikkelaars. Een gesprek over een mogelijke herbouw kwam op tafel.
Een onafhankelijke audit becijferde de kosten van migratie naar een standaard stack (Laravel + Vue) op circa €110.000 en zes maanden doorlooptijd. De keuze viel uiteindelijk op aanblijven bij Elixir met een vaste partner-overeenkomst, omdat de bestaande software stabiel draaide en herbouw veel geld zonder directe waarde toevoegde. Wel werd vanaf dat moment in het selectieproces voor nieuwe software de stack als expliciet criterium meegenomen: pas na een check op beschikbaarheid van ontwikkelaars in Nederland werd een leverancier serieus overwogen.
Misverstanden en valkuilen
- “De stack maakt niet uit, als het maar werkt.” Op de dag van oplevering klopt dat. Drie jaar later, bij de eerste opvolger of integratie, blijkt de stack juist een van de meest bepalende factoren voor doorgaande kosten en flexibiliteit.
- “Kies de nieuwste technologie, dan ben je toekomstvast.” Nieuwe technologie betekent vaak: weinig ontwikkelaars beschikbaar, weinig documentatie, en het risico dat het over twee jaar uit de mode is. Volwassen technologie met een grote community is meestal de veiligere keuze voor businessoftware.
- “De stack is een technische beslissing.” Het is een commerciele beslissing met technische details. Welke partijen kun je in de toekomst inschakelen, welke risico’s loop je, hoe makkelijk koppel je met andere systemen. Allemaal businessvragen die toch eerst aan de stack-keuze raken.
- “Eenmaal gekozen, voor altijd vast.” Niet helemaal. Onderdelen van de stack kunnen vervangen worden zonder de hele applicatie te herbouwen. Een database vervangen, een frontend vernieuwen, een hosting verhuizen: allemaal mogelijk, mits van tevoren met deze flexibiliteit ontworpen.
Wanneer moet je hiervan wakker liggen, wanneer niet
Wakker liggen: bij selectie van een nieuwe maatwerk-software-partner, of voordat een groot ontwikkeltraject begint. Op dat moment vastleggen welke stack gebruikt wordt en waarom, is goedkoper dan twee jaar later met de gevolgen leven. Ook bij bestaande software die op een exotische of verouderde stack draait en kritisch is voor de bedrijfsvoering: een audit en risico-inschatting is dan zinvol.
Niet wakker liggen: als jouw bedrijf vooral standaard SaaS-software gebruikt zonder maatwerk. De stack achter die diensten is de zorg van de leverancier en relevant alleen indirect (via beschikbaarheid en stabiliteit). Op directieniveau is het thema pas relevant zodra er bewust voor maatwerk of een eigen platform gekozen wordt.
Gerelateerde termen
- Frontend: het deel van de stack dat verantwoordelijk is voor de gebruikersinterface.
- Backend: het deel van de stack dat de logica, data en koppelingen verzorgt.
- Maatwerk software: bij elk maatwerk-traject is de stack-keuze een van de zwaarstwegende beslissingen.
- Vendor lock-in: een exotische of leverancier-specifieke stack vergroot de afhankelijkheid van die ene partij.
- Build vs buy: stack-keuze is direct relevant zodra de “build”-kant van die afweging serieus wordt overwogen.
- TCO: total cost of ownership wordt sterk bepaald door de gekozen stack en de beschikbaarheid van talent eromheen.