How a project actually runs.
Five steps, none of them decorative. This is how my placements were run and how I run my own builds.
- 01
Figure out what it actually is
A conversation before an estimate. What it has to do, who keeps it running afterwards, and what happens if it takes off.
Most bad builds start with a bad decision made early and defended later. Before I write anything, I want to know who's editing this in a year, what data it touches, and where you expect it to grow.
This is also where we decide the right approach for the job. If the honest answer is the simple, cheap one, I'll say so instead of talking you into something bigger.
- 02
Make a plan with room in it
A plan you can change your mind against, without restarting the whole thing.
I write plans that can take a change of mind. That's a habit from Buro CITE, where the plan had to leave room to re-optimise instead of forcing a restart every time something moved.
You get the scope, the order things happen in, and what's clearly out of scope. So a request later on is a chat, not an argument.
- 03
Build in the open, bit by bit
Working software you can look at, not silence followed by a big reveal.
Agile and Scrum are how I was trained and how my degree runs its data labs. In practice that's short cycles and something you can click on early, instead of a long quiet stretch that ends in a surprise.
The quality checks run the whole time: type checking, linting, tests where they earn their keep, and a real browser check for anything with a screen.
- 04
Make it safe to run
Backups, containers, and the boring work that stops a bad week.
Regular backups so nothing gets lost, containers so it runs the same everywhere, and deployment I can explain to whoever ends up looking after it.
Keeping projects stable and running across every phase was an actual part of my job at Buro CITE, not something I bolted on at the end.
- 05
Hand it over properly
Docs and a handover aimed at whoever stays, not at me.
If only I can maintain it, the build failed. You get docs written for whoever picks it up next, and where it makes sense, a setup your own team can keep editing without me.
I'm happy to stick around afterwards, but that should be your choice, not something I built you into needing.
The things people ask before the first call.
Languages
Dutch is my first language. English is what I use for docs and code.
Where
Based in The Hague. Both of my internships were on-site with Dutch firms.
How I communicate
Direct, and structured. I'd rather flag a problem early than hand you a clean status and a nasty surprise later.
Got something you want built?
I'm up for freelance work, internships and just building things together, whether that's a WordPress site, a dashboard or a full app. Email is the quickest way to reach me.