Systems

Production systems, built with AI

Deployable software a business can run on — not prototypes, not demos, not proofs of concept. The proof is what is already built and running, and every claim on this page has the artifact behind it.

What that means

“Production ready” is an empty phrase. This is the list behind it.

A technical buyer discounts the adjective instantly and they are right to. These are the unglamorous parts that decide whether a system survives contact with real users and real money, and most AI-built software fails at exactly this boundary.

Isolation at the database layer: Multi-tenant separation enforced by the database, not by application code that one missing filter can defeat.
Real authentication and roles: Permissions enforced on the server. An interface that hides a button is not a permission model.
Billing that matches entitlement: Subscriptions, tier changes and proration handled so what an account can do and what it was charged cannot drift apart, with webhook signatures verified rather than trusted.
Secrets managed properly: Held in the platform's secret store, scoped per environment, never in the repository.
Tests and static analysis in CI: Running on every change and gating the deploy, so a failing check stops a release instead of annotating it.
Observability and error tracking: Failures surface to me before your customer reports them to you.
A rollback path and a recovery plan: Written down and rehearsed, because the question is when rather than whether.
GDPR-aware data handling: Retention, export and deletion designed in at the schema, not retrofitted after a request arrives.
AI Act obligations settled at design time: Whether a system falls in scope of Regulation (EU) 2024/1689 at all, and which transparency and record-keeping duties follow, is decided before the build — including the decision not to put a model where it would create obligations without earning them.

This is the difference between a working demo and a system a business runs payroll-critical operations on.

The stack

Boring on purpose

The default is Next.js and TypeScript on Vercel, Postgres or Convex for data, Stripe for billing, and the Claude API where a system genuinely needs a model. Nothing here is chosen because it is new. It is chosen because it is well documented, widely known, and hireable — which matters more than elegance the day someone else has to maintain it.

The default is not automatic. One system on this page runs on PHP and MySQL, because its user is a volunteer treasurer in retirement and the stack had to be one that outlives me. Picking the right boring thing for a specific person is the judgement being sold.

Application
Data
Money
AI
Run

How it is made

Two fair objections

Every system here was delivered by directing AI coding agents against a written specification, rather than by a team of engineers. That is how one person ships systems at this scale, and it raises two fair objections. Both are answered here rather than avoided.

“So I am buying AI slop I cannot maintain.”

Code written fast has to be checked hard, and the checking is automated and continuous rather than a review at the end. The charity accounting system is the evidence: roughly 34,000 lines held at static analysis level 9 of 9 — the strictest the tool has, where no value of unknown type is allowed anywhere — plus end-to-end browser tests, and a fund schema that an external independent examiner reviewed during a statutory year end.

Static analysis at that level and an outside auditor are not things generated code passes by accident. AI-assisted delivery raises the verification bar rather than lowering it, because it has to.

“Then why do I need you? I will use Claude myself.”

You might, and for some things you should. But the agent builds whatever it is told to build, and the expensive failures are specification failures rather than typing failures: the wrong data model, the wrong assumption about who the actual user is, a rule everyone in the business knows and nobody wrote down. None of those announce themselves until the system is in use, by which point they are structural.

What you are buying is the judgement about what to build and the discipline to verify it. The implementation is a commodity. On the charity accounting system the decisive call was choosing a deliberately boring stack for a non-technical volunteer user — a judgement no coding agent makes unprompted, and the one that decided whether the system would still be usable in five years.

AI writes the systems. AI does not necessarily run inside them.

Build time and run time are separate decisions, made per project. Some of these systems have models in them by design. In the charity accounts and the disclosure validator there is nothing probabilistic anywhere near the numbers, because a probabilistic answer to whether a filing is valid is worth nothing. Knowing where not to put AI is part of what is being sold.

What the work actually is

Directing, specifying, reviewing and verifying AI agents — not hand-writing every line, and not prompting either. The architecture, the data modelling and the acceptance criteria are the deliverable. The code is what falls out of getting those right.

The systems

Built and running

Ventures I have built or co-founded, plus a system built for a registered charity and reviewed by its independent examiner. Not a wall of logos that cannot be named. One entry is a prototype and is labelled as one: it is here because a model you can click through is what discovery produces, and it is the cheapest place to be wrong.

RPM
Live
Execution platform with AI advisors, at reallydoing.it
A subscription platform that turns a one-line ambition into a structured plan, then holds the user to executing it. Ten AI advisors, six pricing tiers, and team billing that has to survive people moving between plans.
- Next.js 16
- Convex
- Claude API
- Stripe
- Vercel
- Playwright
- Sentry
- PostHog
Donations, expenses and accounts for an international aid charity
Delivered, in use
Multi-currency donation, expense and accounting system
Donations in, expenses out and statutory accounts at the end, in several currencies, for an all-volunteer charity with nobody in finance. The primary user is a retired volunteer treasurer, and that constraint decided the technology.
- PHP 8.4
- MySQL 8
- PHPStan level 9
- Pest
- Playwright
- ~34k lines
ESMA securitisation disclosure validator
In build
Pre-submission validation against the ESMA disclosure templates
Takes a servicer's spreadsheet, maps it to the ESMA securitisation disclosure templates, validates it against a rule set, and emits XML that validates against the real schema. Four asset classes covered.
- Next.js
- TypeScript
- Zod
- xmllint-wasm
- Client-side only, no persistence
Hyve Vitals
Demo prototype
Patient experience intelligence for hospital groups
A clickable model of a patient-experience platform for a hospital group, built to test whether the domain had been understood before a line of production code was justified. Every figure in it is synthetic.
- Next.js 14
- TypeScript
- Tailwind CSS
- Recharts
- Typed data files, no backend

How to buy it

Four things, bought separately

Most consultancies hide this and make you book a call to find out how buying works. Here it is, so you can compare before you talk to me.

Discovery

from €7,500

Fixed price, one to two weeks

A standalone engagement that produces the specification, the data model, the system architecture and the acceptance criteria. It is a deliverable, not a sales call with slides at the end.

You own it outright and can take it anywhere, including to another builder. The thinking is the expensive part and you will have paid for it.

Build

typically €30,000–80,000

Fixed price, delivered in phases

Built against the discovery specification, in phases, at a fixed price. Scope changes are new scope and are priced separately rather than absorbed quietly and argued about later.

The repository, the documentation and the deployment pipeline transfer to you on final payment. Nothing is a black box and nothing depends on me to keep running.

Run it

Optional

from €750/month

Optional, priced to the response you need

Hosting, monitoring, upgrades and incident response, as a separate recurring line. You own the code throughout and can move it in-house whenever you want to.

A service, not a hostage arrangement.

Keep evolving it

Optional

from €2,500/month

Optional, a few days a month

Systems in real use accumulate changes. Most clients keep a few days a month because the system is working and they want more of it, not because something is wrong.

What you keep

The decisive question when you hire one person

What happens if I disappear. For a system you commission and pay for, the answer is that you already have everything: the repository, the documentation and the deployment pipeline transfer to you on final payment. Nothing is a black box and nothing depends on me to keep running.

The exception is stated plainly rather than buried. My own products — the SMS reactivation platform among them — are licensed and operated, not transferred. Your data in them is yours and can be exported in full on request; the platform itself is not something you take away.

Europe

European regulation as a design input

Auditability, data residency, retention and AI Act obligations are decided at the architecture stage, where they are cheap, rather than bolted on after a review, where they are not. That is the difference between a system built for this market and one adapted to it.

The evidence is on the pages themselves: a charity accounting system whose output an external independent examiner reviewed, and a disclosure validator built against a published regulatory schema. Neither is a compliance badge. Both are systems that had to survive somebody checking.

Start with a call

A scoping call, then a fixed-price discovery if it is worth doing. If what you need is smaller than a build, I will tell you that on the call.

Book a call pr@merakyconsulting.com