Corporate learning · Internal platform · 2026 — now
One engineer, every layer, three months to production
An internal training platform I built alone with AI: backend, frontend, database, DevOps and operations, live in three months and running without trouble since.
- 3
- months to production
- 400
- people using it
- 2000+
- automated tests
Context
The organization needed one place for its training: a programme catalogue, sessions, requests, a two-step approval, attendance and certificates, replacing an older system whose data we migrated. A product owner shaped the requirements and the screen mockups. All the engineering was mine.
What this usually takes
Backend developer
Frontend developer
Database administrator
DevOps engineer
Someone to run it after go-live
What it took
Me, with AI doing most of the typing
A product owner for requirements and mockups
Written rules that every change has to pass
People
Employees
Coaches
Managers
Admins
Front end
Next.js app
BFF, tokens stay on the server
Back end
.NET API
Worker with scheduled jobs
Data
PostgreSQL
Logs and audit in the database
Around it
Entra ID sign-in
HR user sync
Email queue
Who does what
AI writes most of the code. It doesn't decide what the code should do, and it doesn't decide when a change is done.
| Step | The agent | Me | Checked by |
|---|---|---|---|
| Start | Reads the issue, the logs and the data, and writes down the cause | I agree with the cause, or with the approach for a feature | |
| Test | Writes a test that fails without the change | I check it tests the right thing | The test must fail before the fix |
| Build | Writes the code and updates the docs in the same commit | I review the change | Unit and integration tests on a real PostgreSQL |
| Verify | Drives the feature in a browser with Playwright | I compare it with the rules | End-to-end tests |
| Ship | Opens a merge request with the evidence | I review and merge | CI, then development, test and production |
How the repository keeps it honest
- A start file for any agent or new developer. It says what not to break and in which order to read: the business rules, a generated map from each feature to its code and docs, the delivery cycle, the decision records, and only then the code.
- Numbered rules. The core business rules are written as invariants, such as "the waitlist is filled by an admin, never by the system". Each has a test, and a rule and its test can only change together.
- The cycle is checked in. A skill in the repository walks every change through the same steps. It has no rules of its own; it only enforces the order. A step counts only when it was actually run.
- Production is read-only. The agent can read logs and query data. It can't write anything.
When a waitlist bug reached production, the fix went through the same steps and left three things behind: a decision record, a numbered rule and a test. That bug can't come back without a test failing first.
Running it
- A self-hosted GitLab with its own runner, and CI/CD to separate development, test and production environments.
- Tagged releases with generated release notes.
- Structured logs in the database, archived on a schedule.
- Backups in tiers with a stated recovery point, and a weekly restore of production data into development, so restores are practised, not assumed.
- A daily read-only health check of production.
January
The base
sign-in, BFF, HR user sync, CI/CD
February
Training flows, calendar, the domain model written down
March
Domain clean-up and the test suites
April
Four languages, the remaining features, security and performance testing, go-live
Before go-live
Load- and stress-tested up to 300 concurrent users: no server errors, 95th percentile under 400 ms. Scanned with SonarQube, OWASP ZAP and a dependency audit.
Outcome
Live since the third month and used by around 400 people. Since go-live the changes have been bug fixes and cosmetic polish, nothing more.