Lantara v2

The problem

Otorita IKN issues permits across 31 regulated sectors, from health and education to the environment. In most government systems, every permit type is hardcoded: its workflow, its form and its document list are written by a developer. When a regulation changes, someone has to change the code and ship a new release. In a city that is still being built, regulations change all the time.

Three groups use the system. Citizens and businesses apply, government staff review, and agency administrators set the rules. Those rules come from laws and ministerial decrees, not from engineers. So the core requirement was simple to state: an administrator with no technical background must be able to create a permit type, with its workflow, form and document checklist, from a screen.

What I built

Every permit type is data

I modelled permits as configuration: sectors, permit types, workflow stages, form fields and document requirements. Adding a permit type is data entry. An administrator can set up a six-stage health permit with twelve required documents and a custom form, and nobody touches the code.

When someone applies, the system stores a copy of the form as it was at that moment. If an administrator edits the form later, applications already under review keep the questions they were asked. Reviews stay fair and audits stay exact.

Permissions follow the workflow

Staff permissions are generated from the workflow itself, one per stage and permit type. The code never checks for a fixed role like "verifier". When an administrator adds a permit type, the reviewer slots for it exist straight away.

Deadlines staff can see

Each stage has a deadline in hours, and each permit type has a total in working days. A background job recalculates them against the government holiday calendar and sends alerts when a file is at risk. In the reviewer queue, cards turn from amber to red as the deadline gets close. Keyboard shortcuts let staff approve, return or reject a file without the mouse.

Reviews that hold up in a busy office

A reviewer can claim a file so two people never work on it at once. Idle claims release on their own, and every decision records who made it. Revision requests are per field, so the applicant sees exactly what to fix next to what they wrote before. Some permits need sign-off from two technical departments. I scoped reviewers per stage, so one person can't approve both halves of the same review.

A walk-in queue for the public service mall

Once the permit engine worked, a gap was obvious. It handled online applications that take days, but not a citizen who walks into the Public Service Mall and takes a ticket. I scoped and built MPP Antrean, a separate queue module with its own data and permissions. It covers kiosk tickets, QR check-in, counter triage, and calling, recalling and serving, all updated live. A citizen who booked online but arrives late joins the walk-in line by arrival time instead of losing the ticket.

Result

All four planned build phases shipped in about three weeks, followed by a security pass, an accessibility pass and the queue module. The system models about 2,200 KBLI business codes and starts from one command with demo data loaded. Anyone can scan the QR code on an issued permit to confirm it is authentic, without logging in. A public staging site is live, and production will run on Otorita IKN's own servers.