Skip to content

What I build

Full-stack systems

Records in a database, roles over them, reporting out. Built end to end and handed to you.

What this is

I build the systems a business runs on rather than the page it advertises with: role-based dashboards, database-backed records, admin screens and reporting your staff can use. That means owning the whole line — the data layer, the API over it, and the interface on top — instead of handing off at the boundary.

How it is built

Next.js with server components and route handlers, or Laravel where a PHP host is the constraint. SQLite and Cloudflare D1 for small, fast systems; Postgres where the data outgrows that. Authentication and roles are designed with the schema, not bolted on afterwards, because who may see which record is a data question before it is a screen question.

  • A schema with its constraints in the database, not only in the validator
  • An API that validates every field and rejects clearly, with parameterised queries throughout
  • Roles that decide what a request may read and write, enforced server-side
  • Reporting derived from the records at read time, so the numbers cannot drift from the data

What is shipped, and what that demonstrates

The deployment monitor on this site is this pattern running end to end in public: a collector writing through an authenticated API into a database, SQL deriving every figure at read time, and a dashboard rendering it. A point-of-sale system, a booking system or an internal admin tool is the same shape of problem — records, roles over them, reporting out — with a different domain on top. PLINTH shows the server-rendered half of it in Laravel, with collection filters, configurators and account screens.

Being straight about what is a demonstration

The storefronts and account flows on this site are labelled as interface work, because that is what they are: there is no sign-in, billing or recurring order behind them. The monitor is the opposite — it is a real system with real recorded data and public source. I would rather you knew which is which before you hired me than after.

What you get

  • A data model designed for the records you actually keep
  • Authentication and role-based access enforced on the server
  • Admin and operator screens built for the people who use them daily
  • Reporting and exports derived from the records themselves
  • Deployed into your accounts, with the source handed over

What it does not include

  • Payment hardware and card-present terminals are vendor integrations, scoped per project.
  • Compliance regimes — PCI, HIPAA and similar — are not something I certify. If your system falls under one, that belongs in the brief on day one.
  • I build and hand over; running the system in production afterwards is a separate arrangement.

The work behind it

Shipped, live, and open in a new tab

Scope, timing and support

What you can expect, before you ask

Typical delivery

Web Systems & POS
about 3 weeks · 6 revision rounds
Custom Package
quoted per project

Web Systems & POS carries a published timing because it is a defined tier. Anything that outgrows it — a bespoke system, or one that has to meet payment hardware, an accounting package or an existing codebase — is quoted per project instead.

Typical, not a guarantee — a timeline is agreed with the brief, and it starts when the content and access I need are in hand.

After handover

30 days of bug fixes after handover

The same on every package — it does not scale with the tier.

Covered

  • Anything inside the agreed scope that does not work the way it was agreed.

Not covered

  • New features, content changes and design changes — those are new work, quoted separately.
  • Anything that was never in the agreed scope.
  • Breakage caused by third parties or by editing the delivered code yourself: hosting changes, expired services, dependency changes outside the build I handed over.

The 30 days run from handover. Ongoing support and maintenance are available separately.

Hosting, domains and paid services

Every account is in your name. You own the domain, the hosting and the data; I configure and deploy into them. Nothing is held on my accounts.

You pay third parties directly. Nothing is billed through me.

Many projects run comfortably on free tiers — Vercel, Cloudflare — and I will use them where they genuinely fit. A site with real traffic or heavier requirements may need a paid plan, and I will say so before we start rather than after.

  • Domains always cost money. There is no free tier for a real domain.
  • Paid APIs and services are pass-through, billed to your account.
  • Licensed fonts and stock imagery are pass-through.

Send these six things and the quote means something

  1. What records the system keeps, and who creates themOrders, stock, staff, students, bookings. The records are the schema, and the schema is most of the build.
  2. Who may see and change whatRoles are a data question before they are a screen question, so they belong in the brief rather than in a later change request.
  3. Who uses it day to day, and on whatA counter tablet used by rotating staff is a different interface from an office desktop used by two people.
  4. What has to come out of itDashboards, exports, printed tickets, a daily summary. Reporting decides how the records have to be stored.
  5. Whether it replaces something that already existsExisting data has to be migrated, and existing habits usually shape the screens.
  6. Your deadline, and anything it has to integrate withPayment hardware, an accounting package or an existing API all change the plan. None of them is a problem if I know early.

Also available

Other services

What happens next

Send the six answers above — two lines each is plenty. I reply with what I would build, how long it would take and what it would cost, usually within a day.

Start a brief