Hoe je een techniekkeuze beoordeelt zonder zelf ontwikkelaar te zijn
Er bestaat geen beste techniek, alleen een techniek die past bij wat er moet gebeuren. Een opdrachtgever hoeft de namen niet te kennen — wel de vier vragen waarmee je een voorstel toetst.
01
Waarom één vaste stack een waarschuwing is
Elk bureau heeft gereedschap waar het goed in is, en dat is prima. Het wordt een probleem zodra elk project in dezelfde vorm geduwd wordt: een eenvoudige brochuresite die een volledige applicatie wordt omdat dat de standaard is, of een complexe toepassing die in een pakket geperst wordt omdat dat het bekende systeem is.
Het gevolg is zelden zichtbaar bij oplevering. Het komt later: een wens die 'niet kan', onderhoud dat duurder uitpakt dan verwacht, of een verhuizing die op niets uitloopt omdat alles verweven zit met één keuze.
Een goed voorstel legt daarom uit waaróm iets gekozen is, in termen van jouw project. 'Dat doen wij altijd zo' is geen reden; 'dit past omdat je voorraad realtime moet kloppen en je zelf pagina's wilt kunnen maken' wel.
02
Vier vragen die een keuze toetsen
De eerste: wie kan hier straks nog aan werken? Techniek met een grote gemeenschap eromheen is makkelijker te bemensen dan iets zeldzaams, hoe elegant dat ook is. Vraag hoeveel ontwikkelaars in Nederland hiermee werken.
De tweede: wat gebeurt er bij groei? Als het aantal bezoekers, producten of gebruikers verdubbelt, wat verandert er dan aan kosten en snelheid? Op die vraag hoort een concreet antwoord te komen, geen geruststelling.
De derde: wat kan ik zelf? Teksten, prijzen, foto's, openingstijden — dat hoort zonder ontwikkelaar te kunnen. Wat je niet zelf kunt aanpassen, verandert in de praktijk nooit meer.
De vierde: hoe kom ik hier weg? Wie de code beheert, waar de inhoud staat en of die te exporteren is. Niet omdat je van plan bent te vertrekken, maar omdat het antwoord veel zegt over hoe de samenwerking bedoeld is.
03
Wat wél overal geldt
Los van de gekozen route zijn er eisen die altijd redelijk zijn. De site of app laadt snel op een gewone telefoon met matig bereik. De inhoud is te beheren zonder ontwikkelaar. Er is een omgeving om iets te testen voordat het live staat. Er zijn back-ups die daadwerkelijk zijn teruggezet.
En er is documentatie: hoe je het draaiend krijgt, welke externe diensten meedoen en waar de gegevens staan. Niet honderd pagina's, wel genoeg dat een ander het kan overnemen zonder jou te bellen.
Wie die lijst hardop uitspreekt bij het eerste gesprek, filtert een hoop ellende weg — ongeacht welke namen er later in de offerte staan.
- Vraag naar het waarom van een keuze, in termen van jouw project
- Toets op beschikbaarheid van mensen, groei, zelf kunnen beheren en vertrekmogelijkheid
- Snelheid op een gewone telefoon is een eis, geen bonus
- Testomgeving, geteste back-ups en documentatie horen erbij
Korte vragen bij dit onderwerp
Moet ik weten welke programmeertaal er gebruikt wordt?
Nee. Wel of er mensen mee werken, of je het kunt meenemen en of het past bij wat de site of app moet doen. De naam zelf zegt weinig; wat je ermee kunt en wie het kan onderhouden zegt alles.
Is nieuwere techniek beter?
Niet automatisch. Nieuw betekent minder mensen die het kennen en meer verandering onderweg. Beproefd betekent voorspelbaar maar soms trager in nieuwe mogelijkheden. Wat telt is de match met jouw eisen en de zekerheid dat er over een paar jaar nog iemand aan kan werken.
Kennisbank
Een vraag die hier niet bij staat?
Stel hem gerust. Plaincodelab antwoordt ook als het antwoord is dat je iets niet nodig hebt.