PRD Mid-Prototype: Why Writing Requirements After the First Screen Works Better for RegTech

The conventional order is wrong. For regulated software, you should build the first screen before you write the requirements document.

This is not a claim that requirements don't matter. They matter more in regulated contexts than anywhere else: the regulation itself is a requirements document that carries legal force. The claim is about sequencing, and specifically about what you can and cannot know before you have a working implementation of something.

I arrived at this conclusion after building HousingGuard, a RegTech prototype for the Malaysian KPKT (Ministry of Housing and Local Government), in three sessions across two days. The PRD was written after the working prototype, not before it, and it was a better PRD for it.

The Standard Argument for Pre-Prototype PRDs

The conventional product process runs like this: write requirements, get alignment, build, test, ship. The PRD comes first because it defines what you're building. Building without a PRD is how you produce something nobody asked for.

This argument is correct in the general case. For underconstrained problems, products where the design space is open and the user needs are discoverable, writing requirements before building prevents expensive misdirection.

Regulated products are not underconstrained. The regulation is the constraint. If you are building a housing development disbursement platform in Malaysia, the Housing Development (Control and Licensing) Act 1966 and the Housing Development (Control and Licensing) Regulations 2015 define what must happen, in what sequence, with what documentation, with what parties' approval, at each transaction stage.

You do not have significant latitude on the core requirements. They are written down. In legislation.

The problem is that legislation is not a product specification. It describes obligations and prohibitions. It does not describe screens, data models, user flows, or decision boundaries. The translation from legislative text to product requirements is where the real specification work happens, and that translation is, in my experience, impossible to do well without a working prototype.

What You Cannot Know Until You Build

Three things become legible only when you have a working screen:

1. The data model the regulation actually implies.

Legislative text describes obligations: "the developer shall not receive any payment before..." The data model this implies is not obvious until you implement it. For HousingGuard, the regulatory schedule, the timeline of when each payment tranche can be released, tied to construction completion stages, required a more complex state machine than a plain reading of the regulation suggested.

The derivation chain became visible only when we had a screen that tried to display it. At that point, we discovered that the UI was displaying a result (drawdown permitted or not permitted) without surfacing the derivation. A non-technical regulator could not verify from the screen that the system was applying the correct logic.

The PRD written after building this screen could specify the derivation chain requirement precisely, with a worked example drawn from the implementation. A PRD written before building could not have specified this. The specification would have been generic: "system displays drawdown eligibility." The actual requirement is significantly more specific.

2. The interaction points where professional judgment is mandatory.

Regulated software has two types of steps: automated determination steps (the system calculates something) and professional judgment steps (a human decides something). Identifying which is which is harder than it appears, because the regulation often does not say explicitly.

For a disbursement platform, the system can automate the construction completion percentage calculation. There is a formula. It cannot automate the site supervisor's sign-off. That is a professional judgment with attendant liability, but the boundary between these is not always sharp. Some steps involve both: a calculation that the professional must then attest to.

Building a prototype forces this boundary into visibility. When you implement the screen where the supervisor approves, you immediately discover that the approval workflow requires different things depending on whether the developer has opted into the statutory scheme or a negotiated scheme. That distinction was in the regulation. It was invisible in the pre-prototype phase because we had not yet built the thing that made it matter.

3. The role-switching complexity.

HousingGuard has three user roles: developer (requesting disbursement), bank (approving disbursement), and regulator (auditing both). The interaction between these roles, specifically the read/write boundaries and the information asymmetries, turned out to be the most complex design problem in the system.

The viewer-auditor constraint is the load-bearing legal requirement: the KPKT auditor must be able to see everything but must not be able to modify anything. This sounds simple. Implementation reveals that it is not. Every screen must be designed with this constraint active. The audit trail must record not just what was changed but what was viewed by the auditor and when.

This could not have been specified in a pre-prototype PRD with the precision it required. The implementation forced the precision.

What the Mid-Prototype PRD Looks Like

A mid-prototype PRD is written from a working system, not toward an imagined one. This changes its structure:

The requirements are observable. Instead of "the system shall display disbursement eligibility," the requirement reads: "the system shall display the drawdown amount, the construction completion percentage on which it is based, the specific regulation clause that authorises the drawdown stage, and the consent records attached to this unit that satisfy the consent count requirement." The working screen is the specification source.

The edge cases are enumerated from reality, not imagination. Pre-prototype requirements can only imagine edge cases. Mid-prototype requirements list the edge cases discovered during implementation, and mark the ones that remain open. For a regulator reviewing the PRD, this distinction is critical. It tells them that the edge case was found and considered, not ignored.

The constraint architecture is explicit. The viewer-auditor constraint, the consent count formula, the derivation chain requirement. These appear in the PRD with specificity because they were encountered in implementation and resolved there. A pre-prototype PRD would list them as requirements without resolution. The mid-prototype PRD lists them as implemented features with the implementation documented.

The Counter-Argument and Why It Fails

The counter-argument is: if you build before writing requirements, you build the wrong thing.

In an underconstrained product space, this is true. In a regulated space, it is less likely to be true, because the regulation already constrains the design space significantly. The risk of building toward the wrong regulation clause is real, but it is managed by reading the relevant legislation before building the first screen, not by writing a PRD.

There is a second counter-argument: without a pre-prototype PRD, the build is uncontrolled. Developers make product decisions that belong to the product manager. Scope creep occurs.

This is a valid concern, and it is addressed differently. The solution is not a pre-prototype PRD. It is a plan-review step before build: a structured review of the proposed architecture by both a business lens and a technical lens, run before development begins. For HousingGuard, this was a CEO-lens and an Engineering-lens plan review run in parallel. The reviews shaped the build scope. The PRD then documented what the build produced and the requirements it revealed.

This is exactly the kind of scope management I cover in Scope Compression and 0→1: tight upfront alignment on what you are building, combined with flexibility on the specification that only implementation can produce.

The Sequencing That Actually Works

For regulated software, the right sequence is:

1. Legislation reading. Extract the mandatory requirements, the discretionary requirements, and the open interpretation questions. These are inputs to the plan, not the PRD.

2. Plan with dual review. Write the build plan (screen list, data model sketch, role definitions). Run a business-lens review and a technical-lens review concurrently. Resolve scope and stack questions before the first line of code.

3. Build to the plan. Implement the core flows. Expect discoveries. The role boundaries, derivation chains, and edge cases that weren't visible from the legislation will surface during implementation.

4. Write the PRD from the build. Document requirements from the working system. Use the implementation to specify precision that was impossible before. Mark open items explicitly.

5. Iterate with the PRD as the constraint. Once the PRD exists, it constrains further development. New features must justify themselves against the documented requirements.

This is not a rejection of requirements. It is a sequencing that matches the information available at each stage to the appropriate output.

The pre-prototype PRD assumes more information than exists. The mid-prototype PRD captures the information that the implementation has produced.

In regulated markets, where the cost of building the wrong thing is measured in regulatory non-compliance rather than just wasted developer time, getting the sequencing right matters.

You can see the same logic applied to sprint structure in How I Run 0→1 Product Sprints: the document should follow the work, not precede it.

KG is a product and finance advisor working across Malaysian PropTech and AI tooling. He builds regulated-market software at PEPS Ventures Berhad.