Most application projects do not fail at the demo. The demo goes well — that is rather the point of a demo. They fail in the months afterwards, when the software meets people who did not build it, did not expect it, and are trying to do their jobs with it.
What separates a prototype from something a business can depend on is almost entirely invisible in a walkthrough. It is the bulk of what app development actually involves.
Authentication is not a login screen
A login form takes an afternoon. Authentication takes rather longer, because it includes everything around the form: password reset that cannot be used to take over an account, lockout after repeated failures, session expiry, and a reliable way to remove someone who has left.
That last one is the most commonly missing. Plenty of systems can add a user in a few clicks and have no defined path for removing one, which is how former employees keep access for months.
Permissions have to be designed before the screens
Who may see what, and who may change what, is an architectural decision. Decided up front, it shapes the data model and every query. Decided afterwards, it means revisiting every screen and every endpoint, and the retrofit is rarely complete — the gaps are the ones nobody thought to check.
The warning sign is the phrase "just give them admin for now". It is almost always permanent, and it is how an application ends up with no meaningful permission model at all.
Money has states, and all of them need designing
If the application handles payments, the happy path is the smallest part of the work. Pending, failed, partially refunded, refunded, disputed and reconciled are all states somebody has to design, display and test.
Alongside them you need an audit trail: a record of every change to an amount and who made it. Not for elegance — for the day a client disputes an invoice and the answer has to be verifiable rather than remembered.
POPIA is a build requirement, not a policy page
If the application stores personal information about people, the Protection of Personal Information Act shapes the engineering, not only the privacy notice. In practice that means four things exist in the build:
- A lawful basis for holding each category of personal information, written down.
- A retention period, and something that actually enforces it rather than a note saying it should be enforced.
- Deletion on request, which has to reach every copy — including backups, exports and the reporting database.
- Logging detailed enough to establish what was accessed, by whom, if a breach has to be reported.
A restore you have actually performed
Every project has backups. Far fewer have a restore that somebody has carried out, timed, and verified produced usable data.
Until that has happened, a backup is a hope. The question to ask is not "are we backed up" but "when did we last restore one, how long did it take, and what was missing".
Replacing a spreadsheet costs more than it looks
When software replaces an existing manual process, two costs are routinely left out of the estimate. The first is migration: the existing data has to arrive clean, and real operational data is never as tidy as the sample.
The second is the parallel run. SafeFile replaced exactly this kind of spreadsheet process, and the overlap was planned rather than discovered. For a period, both the old process and the new system operate side by side, because nobody abandons a working spreadsheet on the strength of a demo. That period is real work and it belongs in the plan.
What to ask of any proposal
A proposal that is silent on authentication, permissions, audit trails, deletion and restores is describing a prototype, whatever it is called. Not necessarily dishonestly — the unglamorous half is simply harder to make exciting in a document.
The useful question is not how much the application costs. It is which of these the price includes, and what the plan is for the ones it does not.
Frequently asked questions
Why is a production-ready build more expensive than a prototype?
Because most of the work is invisible in a demo. Authentication, permissions, audit trails, payment states, data migration and tested restores do not change what the screens look like, but they decide whether the software survives real users.
Can we start with a prototype and harden it later?
Sometimes, if the prototype is built knowing that is the plan. The things that cannot be deferred cheaply are the permission model and the data model, because both are assumed by every screen built on top of them.
Does POPIA apply to an internal business application?
If it holds personal information about identifiable people — including staff — then yes. The obligations are the same regardless of whether the application faces customers or sits behind your own login.
