About Me

I started by building websites.

Nothing particularly ambitious at first. A few pages, a few forms, some client requests, and a lot of figuring things out along the way. I learned by building — breaking things, fixing them, reading documentation, and eventually understanding why something worked instead of just making it work.

That habit never really changed.

Over time, websites turned into systems. Systems turned into products. And small problems started becoming engineering problems.

One of the bigger ones started with a simple question.

A friend runs a takeaway. At lunch it gets loud — not busy, loud — because the only way to tell a customer their food is ready is to shout a number across a room full of people doing the same. I said I could put the numbers on the TV.

That was a queue system, twenty commits and a weekend.

Then the shop asked whether the TV could also take the order. Then whether the kitchen could see it. Then whether it could print the receipt, remember regulars, track staff, handle offline orders, and take payment from a phone.

Fifteen months later, that became Rekio — a multi-tenant POS and operations platform with ten modules, a Flutter till, its own WebSocket infrastructure, kitchen and queue systems, reporting, offline capabilities, and a live branch processing hundreds of orders through a single counter.

The interesting part is not how many modules it has.

It is why they exist.

Almost every module started with someone standing behind a counter asking for something while the previous version was still running. The product evolved from real operational problems rather than a feature list written in advance.

And Rekio wasn't the only direction I explored.

I built SEO First CMS, an experiment around treating SEO as a system rather than a checklist — including a proven link-ranked list and the infrastructure around managing and measuring it.

I built Cmedia33, a custom Laravel-based platform where the payment model itself was part of the product: transactions were handled through wallet balances rather than a conventional payment gateway.

I built websites for businesses, internal systems for teams, dashboards, queue displays, custom forms, integrations, and the infrastructure needed to keep them running after deployment.

Each project pushed me a little further away from simply asking:

“How do I build this?”

and closer to:

“What is actually happening here, and what is the simplest system that solves it reliably?”

How I Work

Ground truth before remediation.
When something breaks in production, I measure it before I prescribe. Logs, database state, network behaviour, queues, infrastructure, and actual user flow come before assumptions. Some of the most useful bugs I have found were not the bug everyone initially thought was responsible.

Build around the user's mental model.
A cashier does not think in order_items. A restaurant owner does not think in database relations. A customer does not care which controller processed their request. The interface should speak the user's language, while the architecture handles the complexity underneath.

Verify the wiring, not just the halves.
A green backend test and a green frontend test can still produce a 500 when the two never actually meet. I care about the complete path — input, application logic, database, network, device, and the person eventually using the result.

Build, measure, then iterate.
I prefer working systems over perfect diagrams. Get something real in front of a real user, observe what happens, find where the assumptions were wrong, and improve from there.

Own the entire problem.
I am comfortable moving between schema design, backend, frontend, mobile, APIs, WebSockets, printers, deployment, server infrastructure, and the inevitable call when something stops working at 12:40pm.

I work across the stack because real products rarely respect the boundaries between it.

That end-to-end ownership is probably the most valuable thing I bring to a project — more than any individual technology on a list.