The system I built, then rebuilt while it kept running

What the system has to do

Nitra Academy is not just a training company, it is a recognised examination centre. That distinction is the whole job. Diplomas get registered in Belgium's Central Diploma Register. VCA safety certificates stay valid for ten years and have to stay traceable. The companies that send their people here face annual audits, where an incomplete record can cost them their own certification.

So the system carries the full chain: a course catalogue, a company booking a session, who attended, who passed, the certificate that follows, and the lookup years later when someone needs proof. Four groups touch the same data: Nitra's own team, the contact people at client companies, the instructors, and the participants who end up holding the certificate.

Version one, and why low-code

Before the system, all of it lived in spreadsheets and manual steps. It worked, until the academy grew past forty courses and the admin started eating the time that should have gone into teaching.

I chose Zoho Creator because of the budget. Nitra is an SME, and it already ran on Zoho One: Creator came with that plan, hosting included, so the system added nothing to the monthly bill. It gave us a relational data model, workflow automation and a portal for external users. The price is the interface. Low-code limits what a screen can be, so I designed within those limits instead of fighting them, and what came out is genuinely useful to Nitra and to the companies that send their people there.

What ten years does to a system

A system in daily use collects history. Features get added under deadline, a payment provider gets swapped, a flow gets replaced but never removed. By 2026 the app held dead code, the remains of an old payment integration, an enrolment flow nobody used, and four separate forms doing the same job: issuing a certificate. Four forms means four places to change anything, and four chances to miss one.

The data had drifted too. Fields that filters depended on were empty on most records, so the overviews quietly told half-truths. Report criteria and permissions were wrong in places. None of this was visible from the outside: the app looked like it worked, and that is exactly why it was worth auditing.

The decision: not a big bang

The plan on the table was a rebuild from scratch, off low-code, in code of their own. I scoped it and started it, and the migration is where it broke down: a clean re-import of the live data could not be made to hold, and the cost of forcing it was going to be paid by a system people use every day, for a gain Nitra did not need yet.

So I changed course, which was the harder call and the right one. I rebuilt the app from the inside instead: the same platform, the same database, refactored in phases, with the users never asked to stop working. Choosing not to rebuild is the same skill as choosing to.

How it ran, in four phases

• Clear and secure. Dead code and the old payment integration out, permissions and roles corrected, so that everything after this stood on a floor I trusted.
• One data model. The four certificate forms became one form with a type field, and every existing certificate moved across to it.
• One place for the logic. Functions regrouped into namespaces that say what they are for, with the certificate logic living in exactly one of them. Companies can now also record certificates their people earned elsewhere, so a team overview is the whole truth.
• New capability. A certificate template that adapts to the type of training, a ZIP export, portal access that syncs itself, renewal detection, and public verification.

Each change was built in a development environment, published to a staging environment, and tested there with a demo account per profile, so every role was checked from the seat of the person who actually uses it. Nitra decided what went to production, and every deletion and migration had a backup behind it.

What each group got

• Nitra's team plans sessions with a start time, registers attendance and results, and issues certificates from one screen instead of four. Admin pages carry the numbers that used to need a manual count.
• Client companies see their whole team at a glance: who holds what, what expires when, which sessions are coming. They add their own employees, keep their own company details current, and record outside certificates themselves.
• Instructors get a simple inbox for attendance and results, and a mail a week before they teach with the session details and the participant list. If an outside instructor has no access to the course material, Nitra gets an automatic prompt to send it.
• Participants get a PDF certificate with a QR code. Anyone can scan it and verify it on the Nitra Academy site, against a signed code that cannot be invented. On a construction site, a certificate that proves itself is worth more than one that asks to be believed.

A fixed look, and a fixed vocabulary

The last pass was visual. The app now runs on a small design system: one accent colour, a calm surface that keeps attention on the data, and a fixed vocabulary, so the same thing carries the same name on every screen and in every mail. The documentation went with it: a changelog, a navigation map per user type, and the design system itself, so whoever works on this next does not have to guess.

How this was built, honestly

The pace of this rebuild came from building AI-assisted, and I would rather say that than let the speed look like magic. What AI did not decide: the phasing, what to delete, what to test, which roles to check from which seat, and what was allowed to go to production. That stayed with me and with Nitra. The judgement is the work; the typing is the part that got faster.

What I take from it

The instinct, when a system has grown crooked, is to start over. Starting over is also the option that puts everything you already learned in the bin and asks the client to wait. This one did not need that. It needed an audit, a floor you can trust, one model instead of four, and then the new capability on top of it.

Ten years in, the platform does more than it did, is simpler inside than it was, and it never stopped working for a day while that happened. That is the version of “design and build” I am proudest of.