About
The best code I've ever written started with a conversation, not a keyboard.
I'm a full-stack developer who builds complete digital products from the ground up. Not just frontends. Not just APIs. Complete systems — every layer, every platform, every edge case.
But here's what actually matters: I listen before I build. I've seen what happens when developers skip that step — the client ends up with a product that technically works but doesn't solve their problem. I've been brought in after that happens, and I've seen the frustration firsthand.
Over the past three years I've gone from building small projects to architecting a full-scale restaurant management platform — six interconnected systems, built entirely solo, for a client in Belgium. That project changed how I think about software, business, and what it means to actually deliver.
Process
How I Work
Listen & Understand
Before writing code, I become the user. I ask the questions that surface the real problem — not the surface-level request. Building starts when the client says "now you get it."
Architect
I think in systems, not features. How do pieces connect? What breaks under load? These answers come before implementation — because redesigning mid-project costs 10x more.
Build
Every function, endpoint, and component written with intention. Clean code isn't clever code — it's code another developer can read six months later and immediately understand.
Deliver
From database schema to deployment config, I own every layer. When I say it's done — it's deployed, tested, and ready for real users. No handoffs, no loose ends.
Services
What I can be hired to do
Everything below points at work you can read about on this site. I do not list a capability I cannot show you.
Custom business platforms
I build complete systems for businesses whose workflow does not fit off-the-shelf software. That usually means a customer-facing app, one or more internal dashboards, and the server that keeps them in step — designed around how the business actually runs rather than around a template.
- Requirements discovery, written down and confirmed before any code
- System architecture across every application in the platform
- The full build — frontend, backend, database, integrations
- Deployment, monitoring and handover documentation
Good fit for: Owners running a real operation on spreadsheets, WhatsApp, or a website that never quite fit.
Evidence:Restaurant Management System
Production-ready MVPs
I take a product idea to a first version that real users can use and you can keep building on. The goal is a small system built properly — authentication, data model, deployment and error handling done once, correctly — rather than a prototype that has to be thrown away when it works.
- A scoped first version, agreed before the build starts
- Authentication, data modelling and API design
- Deployed and running, not a demo on a laptop
- A codebase another developer can pick up
Good fit for: Founders who need to put something real in front of users without rebuilding it six months later.
Evidence:Restaurant Management System
APIs and backend systems
I design and build the server side — REST APIs, real-time systems, authentication, background jobs and the data model underneath them. This includes taking an existing backend that has outgrown its structure and reorganising it without stopping the business that depends on it.
- API design with validation and generated documentation
- Authentication and session handling built to current practice
- Real-time delivery where it earns its place
- Migration of existing systems, in steps, without downtime
Good fit for: Teams with a frontend and no backend, or a backend that has become difficult to change.
Evidence:Restaurant Management System
Performance and technical SEO
I find out why a site is slow and fix the causes. Most performance problems are structural — work happening on the client that belongs on the server, bundles carrying code nobody needs yet — so the work starts with measurement and ends with numbers you can check yourself.
- A measured diagnosis naming the actual causes
- The fixes, applied and re-measured
- Semantic markup, metadata and structured data
- Image delivery and loading strategy
Good fit for: Anyone whose site works but feels slow, or who is invisible in search and does not know why.
Evidence:Restaurant Management System
Currently building
A production backend, on my own terms
Alongside client work I'm building the backend for a product of my own. I'm not naming it yet — it isn't launched, and the name will probably change before it is.
What makes it worth mentioning is that nobody handed me the constraints. On client work the shape of the problem arrives with the brief. Here I had to decide what the system needed to be, and then justify those decisions to the only person who would have to live with them.
A modular monolith, not microservices
The realistic scale is hundreds of users at launch and low thousands in the first year. One service and one worker is the honest fit. Splitting it into microservices would buy operational complexity I would then have to pay for every day, in exchange for scaling I do not need.
Every vendor behind an adapter
The AI provider, the payment provider and the email provider each sit behind a service-layer interface chosen by configuration. None of them is load-bearing. Swapping any one of them is a config change and a new adapter, not a rewrite — which matters more for a small product than for a large one, because a small product cannot absorb a migration.
The right language for the work
Document parsing and PDF rendering are CPU-bound and deterministic — a poor fit for Node's event loop, where they block everything else. That work runs in a separate Go worker over a shared queue. I made myself write down the evidence for that before committing to a second language, because a polyglot codebase is a real cost.
Streaming without a real-time tier
User-facing streaming uses server-sent events. A full WebSocket tier was considered and deliberately excluded — long-running generation belongs in a background queue rather than holding a connection open, and the product has no genuine real-time requirement.
Compliance designed in, not bolted on
Personal data is encrypted at rest, every record is scoped to exactly one owner with no cross-user access, and access to personal data is logged. Card data is out of scope entirely, because a merchant-of-record owns it — an entire class of compliance burden removed by a decision rather than by effort.
It isn't launched, so there are no numbers to show. What I can offer is the reasoning behind each of those choices, and an honest account of the ones I would revisit.
Perspective
What I Believe
AI will create more opportunities, not fewer.
Everyone is talking about AI replacing developers. I think the opposite will happen. AI will dramatically increase what a single developer can accomplish — and the developers who understand business problems, not just syntax, will become more valuable than ever.
The demand for custom software is just getting started.
SaaS handles generic needs well. But every business has unique problems, unique workflows, unique constraints. The gap between what off-the-shelf software offers and what businesses actually need is growing. Developers who can fill that gap — independently, end to end — will be in very high demand.
Reliable beats perfect. Every time.
I used to chase perfection in every line of code. Now I know that shipping something reliable, well-tested, and good enough today is worth more than shipping something perfect next month. Knowing the difference between the two is itself a skill.
Working Style
How I Prefer to Work
- Remote-first — I do my best work with autonomy and deep focus
- Asynchronous communication — fewer meetings, more building
- Full ownership — I take a problem and come back with a working product
- Contract-based or flexible engagements — aligned incentives, clear scope
- Results over hours — I care about what gets shipped, not what time I logged in
Technology