Last week I saw a company running their entire operation on a Microsoft Access database. One concurrent user. Maintained by a retired programmer living in Spain for 1,000 per year.

My first instinct: this is a ticking time bomb.

So naturally I went into a big discussion with my dad, a senior architect, soon retiring, who’s spent decades cleaning up IT messes in enterprise environments. His take? That system has been running for over two decades. It does exactly what they need. Total cost of ownership: practically zero.

Meanwhile, there’s me. 28, highly driven, wanting to do it right. Hexagonal architecture. Clean layers. Dependency inversion so you can swap anything on the fly. Modular code where adding a feature means adding a file, not a six-month impact analysis. No schema changes breaking half the system.

Two very different stories.

The young developer vs. the senior architect

The young developer sees fragility, technical debt, and a single point of failure that could collapse tomorrow. They’ll out-innovate you in a few years! Rewrite everything! Fresh, modern, clean!

The senior architect sees a solved problem, a happy client, and a graveyard of expensive replacements that performed worse than what they replaced.

Here’s what this son-dad discussion has landed on: both roles are right, but about different time horizons.

The old system works until it doesn’t. And when it fails, the cost is catastrophic.

The new system is “better” until it isn’t. And when it ships, it’s often slower, buggier, and 10x more expensive.

The uncomfortable middle

I’ve seen spaghetti code built in a week running in production for 30 years. I’ve also seen enterprise codebases where changing a single enum takes 8 months with a full team because every line you touch knocks over three other systems. Legacy - gotta love it.

Most developers over-build. Most managers under-invest. The sweet spot is a boring, pragmatic middle that neither side finds exciting.

And maybe that’s exactly why it works.

What this means for what I’m building

I’m building Convivo, a cohousing management platform, with hexagonal architecture, automated import guards, and test-enforced layer boundaries. By the metrics my dad would use, this is over-engineering for a product that hasn’t launched yet.

But here’s the difference: I’m not replacing a working system. I’m building for a market that has no system at all. Belgian cohousing communities manage their finances in spreadsheets. There is no Access database to respect. There is no retired programmer in Spain keeping the lights on. There’s nothing.

When you’re replacing something that works, the burden of proof is on the replacement. When you’re building something new, the burden is on getting the foundation right - because the €1,000/year maintenance guy for your system is future you, and future you will either thank present you or curse present you for the next two decades.

The architecture isn’t about being modern. It’s about making sure that when I need to swap Supabase for another database, or Stripe for another payment provider, or add a fourth authentication method, I change one file instead of fifty. That’s not over-engineering. That’s the lesson from every Access database that eventually did fail: the cost of change is the only cost that compounds.

The invoice

But if the man in Spain stops picking up the phone one day, that invoice is coming. And it won’t be 1,000 this time.

Vorige week zag ik een bedrijf dat hun volledige operatie draaide op een Microsoft Access database. Eén gebruiker tegelijk. Onderhouden door een gepensioneerde programmeur in Spanje voor 1.000 euro per jaar.

Mijn eerste reactie: dit is een tikkende tijdbom.

Dus natuurlijk belandde ik in een stevige discussie met mijn vader - een senior architect, binnenkort met pensioen, die decennia heeft besteed aan het opruimen van IT-puinhopen in enterprise-omgevingen. Zijn kijk? Dat systeem draait al meer dan twintig jaar. Het doet precies wat ze nodig hebben. Total cost of ownership: praktisch nul.

En dan heb je mij. 28, gedreven, het wil goed doen. Hexagonal architecture. Schone lagen. Dependency inversion zodat je alles kunt uitwisselen. Modulaire code waar een nieuwe feature toevoegen betekent: een bestand toevoegen, niet een impactanalyse van zes maanden. Geen schema-wijzigingen die de helft van het systeem breken.

Twee totaal verschillende verhalen.

De jonge developer vs. de senior architect

De jonge developer ziet kwetsbaarheid, technische schuld en een single point of failure dat morgen kan instorten. Ze lopen je binnen een paar jaar voorbij! Herschrijf alles! Fris, modern, clean!

De senior architect ziet een opgelost probleem, een tevreden klant, en een kerkhof vol dure vervangingen die slechter presteerden dan wat ze vervingen.

Dit is waar onze vader-zoon-discussie op uitkwam: beide perspectieven kloppen, maar over verschillende tijdshorizonten.

Het oude systeem werkt tot het niet meer werkt. En als het faalt, is de schade catastrofaal.

Het nieuwe systeem is “beter” tot het dat niet is. En als het live gaat, is het vaak trager, buggier, en tien keer zo duur.

Het ongemakkelijke midden

Ik heb spaghetticode gezien die in een week gebouwd is en dertig jaar in productie draait. Ik heb ook enterprise-codebases gezien waar het wijzigen van een enkele enum acht maanden duurt met een volledig team, omdat elke regel die je aanraakt drie andere systemen omver gooit. Legacy - je moet ervan houden.

De meeste developers bouwen te veel. De meeste managers investeren te weinig. De sweet spot is een saai, pragmatisch midden dat geen van beide partijen spannend vindt.

En misschien is dat precies waarom het werkt.

Wat dit betekent voor wat ik bouw

Ik bouw Convivo, een platform voor cohousingbeheer, met hexagonal architecture, geautomatiseerde import guards en test-enforced layer boundaries. Naar de maatstaven die mijn vader zou hanteren is dit over-engineering voor een product dat nog niet gelanceerd is.

Maar hier zit het verschil: ik vervang geen werkend systeem. Ik bouw voor een markt die helemaal geen systeem heeft. Belgische cohousing-gemeenschappen beheren hun financien in spreadsheets. Er is geen Access database om te respecteren. Er is geen gepensioneerde programmeur in Spanje die de boel draaiende houdt. Er is niks.

Als je iets vervangt dat werkt, ligt de bewijslast bij de vervanging. Als je iets nieuws bouwt, ligt de bewijslast bij het goed leggen van het fundament - want de man die jouw systeem voor 1.000 euro per jaar onderhoudt, dat ben jij in de toekomst. En toekomstige jij gaat huidige jij ofwel bedanken ofwel vervloeken voor de komende twintig jaar.

De architectuur gaat niet over modern zijn. Het gaat erom dat wanneer ik Supabase moet inwisselen voor een andere database, of Stripe voor een andere betaalprovider, of een vierde authenticatiemethode moet toevoegen, ik een bestand wijzig in plaats van vijftig. Dat is geen over-engineering. Dat is de les van elke Access database die uiteindelijk wel faalde: de kosten van verandering zijn de enige kosten die exponentieel groeien.

De factuur

Maar als die man in Spanje op een dag niet meer opneemt, komt die factuur. En het wordt geen 1.000 euro dit keer.