Odoo Studio vs custom code — wanneer wat
Studio is briljant voor de juiste klus en een trage val voor de verkeerde. We gebruiken beide op elk klantproject — dit artikel is het kader dat we toepassen om te beslissen wat waar gaat.
Odoo Studio is de low-code-laag waarmee je velden, schermen, rapporten en automatiseringen bouwt zonder Python. Het is echt nuttig — en echt misbruikt. De meeste technische schuld die we mogen opruimen is Studio-wildgroei die ongecontroleerd is gegroeid.
We zijn niet anti-Studio. Met discipline gebruikt versnelt het levering, geeft het businessusers macht en houdt het kleine maatwerk uit de dev-backlog. Zonder discipline produceert het ongedocumenteerde logica, broze upgrades en een configuratie die niemand in jaar drie nog snapt.
Dit artikel is de vuistregel die onze consultants toepassen: waar Studio wint, waar code wint, waar de lijn schuift met teamvolwassenheid en hoe we de grens beheren doorheen ons klantenbestand.
Waar Studio het juiste antwoord is
Studio is op zijn best voor kleine, additieve, goed afgebakende wijzigingen die schoon mappen op bestaande Odoo-concepten: enkele extra velden, een aangepaste view, een custom rapport, een eenvoudige automatisering. Anders blijven die wekenlang in een backlog hangen.
We duwen sterk voor Studio in deze gevallen. Dat zet het maatwerk in de juiste handen (de businessuser dichtst bij de nood) en houdt het devteam gefocust op wat echt code vraagt.
- Enkele custom velden aan bestaande modellen toevoegen
- Velden in een bestaande view herordenen of hernoemen
- Een klein custom rapport of printtemplate bouwen
- Een eenvoudige automatisering (status → e-mail) wiren
- Een lichtgewicht nieuw model voor een interne use case
Waar custom code het juiste antwoord is
Code wint zodra logica complex wordt, hergebruik telt, de wijziging meerdere modules raakt of het integratievlak niet triviaal is. Alles wat je gedekt wil door tests, code-reviewed en versie-gecontroleerd hoort thuis in een echte module.
Wordt een Studio-wijziging moeilijk in één paragraaf uit te leggen of moeilijk op een sandbox te reproduceren, dan is ze Studio ontgroeid. Vroeg refactoren naar module spaart een veel zwaardere refactor later.
- Logica over meerdere modellen of modules
- Integraties met externe systemen voorbij eenvoudige webhooks
- Alles wat unit- of integratietests vraagt
- Performance-gevoelige code (batchjobs, rapporten op grote data)
- Elke wijziging die een junior niet zonder review zou mogen aanpassen
Het grijze gebied — en hoe het netjes te houden
Sommige wijzigingen starten in Studio en groeien er stilletjes uit. Het klassieke geurtje is wanneer een Studio-automatisering een andere triggert, of wanneer Studio-velden in custom rapporten opduiken. Dan trekken we een lijn en migreren naar module.
De discipline is niet 'nooit Studio voor x'; ze is 'wanneer Studio-wijziging y drempel z passeert, promoot naar module'. Documenteer de drempel één keer en je voert niet elke kwartaal dezelfde discussie.
- Studio-automatisering geketend aan andere Studio-automatisering
- Studio-velden in niet-triviale custom rapporten
- Studio-logica die naar meerdere databases moet
- Alles wat een key user vreest aan te raken
- Maatwerk dat een single point of failure werd
Governance — het ontbrekende stuk op de meeste projecten
Studio zonder governance produceert wildgroei. Elk project dat we auditen heeft minstens één ongedocumenteerde Studio-wijziging van een power user van drie jaar geleden die niemand durft aanraken. Vermijd dat met een kleine maar echte governance-bar vanaf dag één.
Governance betekent geen bureaucratie — een gedeeld register, een driemaandelijkse opkuis en een expliciete eigenaar van Studio-wijzigingen per module. Een halve dag per kwartaal volstaat.
- Houd een Studio-wijzigingsregister per module
- Benoem een eigenaar per module die wijzigingen reviewt
- Driemaandelijkse opkuis-pas op wildgroei
- Documenteer elke Studio-wijziging in één lijn
- Test op sandbox voor je in productie toepast
De drempelregel die we bij Flydoo hanteren
Onze interne regel is eenvoudig: raakt een wijziging meer dan twee modules, heeft ze conditionele logica voorbij één 'als', of moet ze naar meer dan één database — dan hoort ze in code. Anders is Studio prima.
- Raakt meer dan twee modules → module
- Meer dan één conditie → module
- Naar meerdere databases → module
- Heeft tests nodig → module
- Anders → Studio is het juiste antwoord
Studio-fouten die we blijven opruimen
Vijf patronen die we in bijna elke audit vinden.
- Bedrijfskritische workflows in Studio bouwen zonder register of eigenaar.
- Geketende Studio-automatiseringen die niemand end-to-end kan debuggen.
- Studio-wijzigingen handmatig over databases deployen in plaats van als module.
- Studio-wijzigingen als 'gratis' beschouwen — geen test, geen review, geen doc.
- Pas naar code promoten nadat het in productie brak.
Hoe meet je dat de grens gezond is
Cijfers per module op klantprojecten.
- Aantal Studio-wijzigingen per module — moet plateau bereiken, niet eeuwig groeien.
- Volledigheid van het Studio-register — elke wijziging gedocumenteerd.
- Aantal Studio→code-promoties per jaar — klein maar niet nul.
- Tijd om een Studio-incident te debuggen — afgebakend, niet 'we weten niet'.
- Aantal ongedocumenteerde Studio-wijzigingen — nul na de eerste opkuis.
Hoe Flydoo Studio-governance doet
Elk klantproject start met een eenpagina Studio-policy: wie wat mag wijzigen, wat geregistreerd wordt en de promotiedrempel naar code. We co-bezitten het register met de IT-lead van de klant en reviewen het driemaandelijks.
Wanneer een Studio-wijziging de drempel passeert, plannen we de promotie naar een module in de volgende sprint. We laten nooit een keten Studio-automatiseringen groeien tot één van ons de enige is die het snapt.
- Eenpagina Studio-policy op elk project
- Studio-register co-bezit met de IT-lead
- Driemaandelijkse Studio-review in de agenda
- Promotie naar code gepland zodra een wijziging de drempel passeert
- Kennis delen — nooit één persoon de enige expert
Voor je een Studio-wijziging goedkeurt
Loop deze korte lijst voor je opslaan klikt.
- Wijziging beschreven in één paragraaf
- Eigenaar per module geïdentificeerd
- Wijziging eerst op sandbox getest
- Entry toegevoegd aan Studio-register
- Drempelregel toegepast — onder de drempel, Studio; erboven, plan een module
- Backout-plan gedocumenteerd voor niet-triviale wijzigingen
- Driemaandelijkse review-datum in agenda
Studio en code zijn partners, geen rivalen
Studio is het juiste antwoord voor het juiste type wijziging. Custom code voor de rest. De teams die winnen kiezen bewust, documenteren keuzes en reviewen de grens regelmatig.
Ruim je Studio-wildgroei op, dan is dat niet de schuld van Studio — wel van het ontbreken van governance. Zet de policy, het register en de driemaandelijkse review op en de tool begint weer terug te verdienen.
We doen graag een eendaagse Studio-audit op om het even welke productie-Odoo en zeggen welke wijzigingen blijven, gepromoot worden of weg moeten.
Veelgestelde vragen
Is Studio 'production-grade'?
Ja — Odoo ondersteunt Studio officieel voor productie. Het risico is niet de tool; het is ongedocumenteerde wildgroei. Met register, eigenaar en drempelregel is Studio een legitiem onderdeel van een productie-Odoo.
Overleven Studio-wijzigingen een upgrade?
De meeste wel, sommige breken. Test Studio-wijzigingen altijd op een sandbox-upgrade voor je productie. Wijzigingen op deprecated velden of verwijderde views moeten elke minor release worden gereviewd.
Kan ik Studio-wijzigingen versie-controleren?
Studio-wijzigingen leven in de database, niet in een Git-repo, dus ze worden niet zoals een module versie-gecontroleerd. Je kunt ze exporteren en de export tracken, maar het propere pad voor serieuze governance is kritieke wijzigingen naar een code-module promoten.
Wie zou Studio moeten bezitten in ons team?
Kies een power user per module die het businessdomein goed kent. Koppel hem aan een ontwikkelaar voor de zwaardere wijzigingen. Zonder benoemde eigenaar worden Studio-beslissingen 'wie het dichtst bij het toetsenbord zit' en start de wildgroei.
Wanneer migreer ik een Studio-wijziging naar een module?
Pas de drempelregel toe: meer dan twee modules geraakt, meer dan één conditie, deployment naar meerdere databases of nood aan tests — promoten naar module. Anders in Studio laten. Houd de regel zichtbaar zodat het gesprek kort is.
Wil u bespreken wat dit betekent voor uw eigen Odoo-project? We praten er graag over.