A citizen service portal has a harder brief than almost any commercial product. It must work for a user on a five-year-old phone, on an intermittent connection, possibly with a screen reader, possibly in a language other than the one the developers speak.
That drives concrete choices: server-rendered pages so the first paint does not wait on JavaScript, form state persisted so a dropped connection does not lose twenty minutes of typing, and a real translation workflow rather than machine output pasted into a JSON file.
Accessibility has to be tested with assistive technology, not only with an automated scanner. Scanners catch missing labels; they do not catch a focus order that makes a form impossible to complete by keyboard.
The payoff is measurable in the operations data. When the portal genuinely works, counter footfall falls, and staff time moves from data entry to the field verification work that actually needed a human.
Working on something like this?
We are happy to review an architecture, sanity-check an approach or tell you honestly that you do not need an external partner for it.
Talk to an engineer