Most software projects don't fail because of bad code. They fail because nobody wrote down, precisely, what the system actually needed to do before anyone started building.
I've spent close to a decade working inside institutional IT — procurement, technical evaluation, and building internal systems that are still running years later. Along the way I've seen the same pattern repeat: a system gets commissioned, development starts quickly, and only months in does it become clear that nobody had actually defined the roles, the approval logic, or the edge cases the business depended on.
So when I sat down to plan a Leave Management System, I did it the other way around. No code first. Just the specification — written entirely from operational experience, not copied from a template.
What "the specification" actually meant
Writing a real functional specification means answering questions most people skip past:
- Who are the actual roles in this process, and what can each of them see and do? (Applicant, shadow officer, two levels of approving officer, and an administrator — each with a different dashboard and different permissions.)
- What happens in the messy cases, not just the clean ones? What if the assigned shadow officer is unavailable? Who do they hand the request to, and what happens to the audit trail when they do?
- How is every record uniquely and traceably identified? (In this case, a generated ID combining the institute code, section code, employee number, and a running sequence — so every application is traceable on sight, on paper or in the system.)
- What has to happen automatically versus what needs a human decision? (Leave balances should deduct only once both approving officers have signed off — not before.)
- What does the institution need to report on later — by employee, by month, by designation, across a date range — and in what form: summary or full detail?
The final specification ran far beyond a simple leave request form. It covered user roles, workflow logic, data structures, approval hierarchies, notification rules, leave-policy configuration by designation, an annual holiday calendar, reporting requirements, input validation, audit logging, security controls aligned with recognised web application guidelines, and exception handling for every point where a request could stall or be redirected. By the time development began, very little was left to interpretation.
None of this is technical in the coding sense. It's operational knowledge, written down precisely enough that someone else — or something else — could build it without guessing.
The logic was human. The typing was assisted.
I used modern AI coding assistance to translate the specification into a working system — much the way a typewriter turns handwritten drafts into a finished document. The tool did the typing. The logic — the roles, the escalation paths, the approval sequence, the reporting structure — was entirely mine, grounded in years of watching how these processes actually break down inside real institutions.
Within a relatively short development cycle, that specification had evolved into a functioning prototype: registration and administrator verification, role-based dashboards, the full shadow-officer handoff logic, two-stage approval with automatic balance deduction, a configurable holiday and leave-policy calendar, and filterable summary and detail reports — including a printable leave slip and an audit log of every action taken.
The lesson wasn't that AI could generate code quickly — that's no longer surprising. The real lesson was that the quality of the outcome depended almost entirely on the quality of the specification behind it. A vague brief produces a generic system. A precise one, grounded in real institutional experience, produces something close to what an organisation would actually need to run.
Why this matters beyond one system
Many professionals understand how organisations actually work — approval hierarchies, procurement rules, audit requirements, compliance obligations, and the operational exceptions that don't show up in a textbook. Fewer can translate that knowledge into a structured specification that a developer, or an AI tool, can build from accurately.
Conversely, many capable developers can implement a specification faithfully but aren't in a position to discover the missing business rules mid-project — that's not their job, and it's unreasonable to expect it of them.
That disconnect is where many projects begin to fail — long before the first line of code is written.
Is this for you?
This applies directly if any of the following sound familiar:
- Your HR or administrative team is still tracking leave, approvals, or requests on paper or in scattered spreadsheets.
- Your approval process runs on "just send an email to the boss" rather than a defined, traceable path.
- You've bought off-the-shelf software before, and it didn't quite fit how your organisation is actually structured.
Where this goes from here
Whether development is carried out by an internal team, an external vendor, or increasingly by AI, the quality of the specification remains the single biggest predictor of a project's success. It's the part most projects rush through — and often the part that matters most.
If you're planning a new internal system, or modernising an existing one, I'd be interested to hear how you're approaching the specification stage. Contact us : Contact Us
AI generated prototype based on our specification.....
