Full-Stack Web App Development

Some problems are not websites. If you are tracking bookings in a spreadsheet that three people edit simultaneously, or emailing PDFs that should be a form, or copying data between two systems by hand every Monday, you have an application-shaped problem.

What I build

Client portals where customers log in and see their own data. Booking and scheduling systems. Internal dashboards that pull numbers from wherever they live and show them in one place. Multi-step forms with logic and file uploads. Small SaaS products.

The stack is React and Next.js on the front, with the backend chosen to fit — a managed database and API routes for most projects, something heavier when the workload justifies it.

Scoping before building

The most expensive thing in software is building the wrong thing well. So the first deliverable is never code: it is a written scope covering what the system does, what it explicitly does not do, and where the boundaries are.

That document is what keeps a project from doubling in size halfway through. It also means when you ask "can it also do X" — and you will — we can both see clearly whether X was in scope and what adding it costs.

About "vibe code"

AI tooling has made it fast to produce something that demos well. It has not made it fast to produce something that handles real users, real data and real failure states. A prototype that works on the happy path is perhaps 20% of a shippable application; the rest is validation, permissions, error handling, and the unglamorous work of making it not lose data.

I use AI tooling heavily and it makes me considerably faster. What it does not do is remove the need for someone to be accountable for the thing still working in six months. That accountability is most of what you are paying for.

You own it

Code lives in your repository. Deployment runs on your accounts. If you bring in another developer later, they get a normal codebase with normal tooling, not something only I can maintain.