Availability, access control, audit trail and accessibility are not features to add later, they are the design constraints that shape the first architecture decision.
The four constraints that set the architecture
A public-facing portal that carries statutory or citizen-facing transactions has to prove four things continuously: it is available when people need it, only the right people can see the right records, every consequential action is attributable, and everyone can use it regardless of ability or device.
Each of these is an architectural decision, not a feature. Retrofitting any of them after launch typically costs more than the original build.
Availability is an operating model, not a number
A 99.9 percent target is meaningless without a defined maintenance window, a monitored health endpoint, alert routing to a named on-call owner, and a rehearsed restore. We size availability against the real business calendar, a licensing portal cannot be degraded in the two weeks before a renewal deadline, whatever the annual average says.
Access control belongs in the data layer
Role checks in the user interface are a convenience, not a control. Authorisation has to be enforced where the data is served, so that an API call crafted outside the browser fails the same way a hidden button does.
Design the role model against real organisational roles, applicant, reviewing officer, approver, auditor, delegated agent, and validate it with the people who hold those roles before writing the schema.
Audit trail: attributable, immutable, exportable
For every status change, approval, rejection, payment and data export, record who acted, what changed, when, and on whose behalf. Store it append-only, keep it for the statutory retention period, and make it exportable in a format an auditor can read without your help.
Accessibility and inclusion
WCAG 2.2 AA is the working baseline: keyboard operation, visible focus, colour contrast, meaningful labels, sensible error messages and a document structure a screen reader can navigate. Test with assistive technology, not only automated scans.
Inclusion goes further than compliance, low-bandwidth performance, mobile-first layouts, plain language, and where relevant, bilingual or right-to-left support decided before the design system is built.
Prove it before go-live
Load test to the peak volume, run an independent security assessment, complete an accessibility audit, rehearse the restore, and hand over runbooks and training. A portal that cannot demonstrate these on the day it launches will be asked to demonstrate them in far less forgiving circumstances later.