CTO on Demand for a National Permit Digitalisation Programme

Government technology projects have a reputation for overrunning schedules and producing systems that work in demonstrations and not in the field. A Malaysian government-linked technology agency was determined to be different. They were tasked with digitising a national permit application system that had been paper-based for thirty years — 180,000 applications per year, eleven permit categories, fourteen regulatory agencies as stakeholders. They had funding, a mandate, and fourteen months to go live. What they lacked was a CTO to lead it.

Nematix provided on-demand CTO leadership for ten months. The platform launched on schedule. Forty thousand permit applications were processed digitally in Q1 after launch.

The Situation

The permit system being digitised covered business operating licences, environmental permits, and import/export approvals across multiple sectors. The paper-based process required applicants to physically submit documents to a central office, which then routed them to the relevant regulatory agencies for review and approval. Average processing time was forty-two working days. For certain permit categories, it exceeded ninety days.

The agency had a team of twelve — project managers, business analysts, and a small technical team with application development experience. They had selected a technology stack (cloud-hosted web application, document management system, workflow engine) and engaged a development vendor. What they needed was senior technical leadership to make the right architectural decisions, manage the vendor, and provide the technical credibility that government stakeholder meetings required.

The fourteen-month timeline was a board-level commitment. Missing it would have political and commercial consequences for the agency.

The Challenge

Government technology engagements have specific challenges that private-sector projects don’t.

Fourteen regulatory agencies, fourteen sets of requirements. Each agency had its own workflow for reviewing permit applications, its own data requirements, and its own legacy systems that the new platform would need to integrate with or accommodate. Getting alignment across fourteen agencies — each with different levels of technical sophistication and different priorities — was as much a stakeholder management challenge as a technical one.

Security and compliance requirements. Government platforms in Malaysia operate under the Malaysian Government Security Classification (MGSC) framework. The platform handled business registration data, identity documents, and commercially sensitive permit applications. Data residency had to be in Malaysian government-approved cloud zones. Security architecture required formal approval from the relevant authorities before the platform could go live.

Vendor management without in-house technical oversight. The development vendor was a competent mid-sized technology firm. Without senior technical oversight, vendor decisions — on architecture, on scope changes, on testing coverage — would be driven by vendor interests rather than the agency’s. The CTO role was as much about managing the vendor as directing technical choices.

Applicant experience across a wide population. The 180,000 annual applicants included sophisticated enterprises with dedicated compliance teams and sole proprietors with limited digital literacy. The platform had to work for both, which shaped every UX decision.

Our Approach

Months 1–2: Technical architecture and governance framework

The engagement began with a full review of what had been designed to date: the vendor’s proposed architecture, the selected technology stack, and the integration approach for the fourteen agency systems.

Several architectural decisions were revisited: the document management approach (moved from database binary storage to an object storage layer with lifecycle management, improving performance and reducing long-term cost), the workflow engine selection (the initial choice was heavyweight for the use case — replaced with a lighter, more maintainable alternative), and the authentication approach (federated to MyDigital ID for applicants, agency staff on Entra ID).

A technical governance framework was established: architecture decision records for all significant choices, a vendor delivery cadence with fortnightly technical reviews, and a security review schedule aligned to the MGSC approval process.

Months 2–8: Platform build and agency integration

The Nematix on-demand CTO participated directly in the build: weekly vendor technical reviews, code quality standards and pull request review processes, and direct involvement in API design for agency integrations.

Fourteen agency integration specifications were developed — each describing the data flows, approval triggers, and notification events between the central platform and the agency’s internal systems. Three agencies had APIs the platform could connect to directly. Seven required custom integration adapters to their legacy databases. Four integrated via a structured email workflow (no system integration feasible within the timeline) with human handoffs tracked in the platform.

Security architecture was submitted to the relevant authority in month five and received approval in month seven — one month ahead of schedule, because the documentation was prepared with the approval criteria explicitly in mind from month one.

Months 9–10: User acceptance testing and launch preparation

UAT was conducted with actual applicants and agency officers across all eleven permit categories. One hundred and twenty test scenarios were run. Thirty-two issues were identified; twenty-eight resolved before go-live, four deferred to a post-launch patch (none affecting core permit submission or approval flows).

A phased launch was used: two permit categories went live in month ten, with the remaining nine following over the subsequent eight weeks as agency readiness was confirmed. This reduced the risk of a full simultaneous launch across all fourteen agencies while maintaining the board deadline.

Handover: month 10

The agency hired a permanent Head of Technology in month nine. The final month ran the Nematix CTO and the permanent hire in parallel — a structured handover covering system architecture, vendor relationships, open technical decisions, and the post-launch development roadmap. The handover was complete before the two high-priority permit categories went live.

Outcome

The 78% digital adoption in Q1 — across a population that included applicants with limited digital literacy — was the most significant indicator that the user experience decisions had been calibrated correctly.

Key Takeaways

Technical leadership is not the same as technical management. The vendor could manage its own project plan. What it couldn’t do was make architectural decisions that would hold up under five years of operation, navigate the security approval process with the credibility that regulators expected, or represent the agency’s technical interests in fourteen separate agency integration discussions. The CTO role required all three.

Phased launch reduces launch risk without extending the programme. Launching two of eleven permit categories on the board deadline — rather than all eleven simultaneously — preserved the headline commitment while managing the operational risk of full simultaneous go-live. The remaining nine categories followed at a pace the agencies could absorb.

Security approval is on the critical path — treat it that way. The MGSC approval process has a defined submission format and specific technical requirements. Starting with the approval criteria and designing the security architecture to meet them explicitly — not retrofitting compliance after the fact — produced an approval in month seven rather than the month eleven it would likely have taken otherwise.

This engagement draws on our Expertise as a Service and Strategy & Transformation capabilities. If your organisation is leading a significant technology programme and needs senior technical leadership, let’s talk.