A portal can take the application. That doesn’t mean the service works.

The portal launches, and people can finally apply online. Then the application lands in an inbox, gets copied into a spreadsheet and waits for someone to check eligibility by hand. The applicant can’t see where it is, so they call. Staff can’t easily fix a mistake, so it waits for IT.

From outside, the service is digital. From inside, it’s the same paperwork with a new front door.

What a complete service needs

A real digital service connects the public experience to the system behind it: identity, eligibility rules, review, decisions, exceptions, status, notifications, administration, integrations and someone who owns it in production. If any of those is missing, people fill the gap by hand.

And programs often try to modernize everything at once, before a single service works end to end.

Modernize one service far enough to operate

We start with one service journey that can be separated from the wider program and take it all the way to production:

1. We write the service model: who’s involved, the rules, the states, the decisions, the exceptions and the outcomes.
2. We build the journey: the citizen, partner or operator experience, accounts and eligibility, application, review, decision, status and notifications, plus a bounded set of integrations.
3. We deploy it working: admin and correction tools, audit context, an agreed security and monitoring baseline, and acceptance evidence against what was written down.

The delivery plan is set once the service boundary, rules, security constraints, integrations and procurement path are understood. The first stage ends in a service people can use, not a strategy document or a portal mockup.

Built at national scale

For Kazakhstan’s e-government services I built the shared interface layer behind citizen accounts and data access, working with roughly 50 backend engineers and public-sector stakeholders. The wider citizen-service ecosystem reports more than 15 million registered users.

At AuditBoard I worked inside an enterprise audit, compliance and risk platform where workflows, services and deployment had to stay correct together. And as Scoutbase’s fractional CTO, I carried a safety app for 4,000+ maritime workers from workflow design to ongoing operation.

“Kuan’s expertise paved the way for our growth and enabled us to acquire the trust of external investors and, as a consequence of that, additional funding.”

Is this right for you?

It works best when:

• One citizen, customer, partner or operator service can be separated from the wider program.
• A responsible sponsor can define the users, rules, decisions and outcomes.
• The decision-makers and system owners are reachable, and identity, data, hosting and security constraints can be examined.
• A sponsor, the service owner and the data or security owners can give it 2 to 4 hours a week between them.

It isn’t the right fit if the plan is to replace a national platform in one small engagement, if the policy or rules haven’t been decided, or if there’s no sponsor or route to delivery authority.

What happens next

Describe the first service: who uses it, how applications are reviewed and decided, the systems involved and where it breaks today. It starts with two quick questions, and then you can book a fit call or keep writing.