How we shipped a state payment platform in four months

In 2019 a state asked us to build a super app.

Payments. Parking. Bus tickets. Council bills. Utility accounts. One app, for an entire state. The kind of scope a well-funded product company would give eighteen months and a team of forty.

We had four months. We had a team you could fit around one table. And it was 2019, so there was no AI to write the boilerplate, no Copilot, no Claude. Just people and a calendar that was already losing.

We shipped it. PahangGo launched on 23 October 2019 in Bentong. Cashless parking went live across Kuantan, Bentong and Cameron Highlands, replacing the paper coupon on the dashboard. By the following year the state was reporting collections of around RM800,000 a month through it: land tax, quit rent, utility bills, parking.

Two of those things were firsts, and they still stand out to me. It was the first time anyone in the state could check and pay a water bill from a phone instead of standing in a counter queue. And it was the first time anyone in the state could pay for parking online at all. That second one sounds small written down. Standing in a car park watching it happen, it was the moment the state’s digitalisation effort stopped being a slide in someone’s strategy deck and became a real thing an ordinary resident used without thinking about it. I am still proud of that.

I have been asked how, roughly a hundred times, usually at conferences, usually by someone who wants to hear that we worked very hard. We did work very hard. That is not the answer. Plenty of teams work very hard and ship nothing.

Here is the actual answer.

There was no team yet

Before any of this, there was no team to speak of. There was me and one finance person. A CEO and a director, on paper, of a company that did not yet have anything built to show for itself.

Everyone else who touched that four month build, I hired and handpicked myself, engineers and outsourcers both, one at a time, usually because I already half knew them or someone I trusted vouched for them. There was no process for it. There was no time to build one.

Two of those hires are worth telling on their own, separate from the app entirely.

One was a graphic designer with no product or UX background, nothing on her CV that said she could do this kind of work. I trained her on the job, on that project and the ones after it, until UI and UX design became her actual profession. She has built a career on it since, across several companies, entirely her own now. That is one of the things from this whole period I am more proud of than the app itself, most days.

The other was a programmer I brought on part time, who stayed on with us project after project long enough that the arrangement stopped making sense as anything other than permanent. He is a CTO at a state digital agency now.

Neither of those two people show up in a case study about shipping fast. They are the actual return on those four months, and I did not see that clearly until years later.

We cut two thirds of the scope before writing any code

The brief had somewhere north of forty features. I sat down and worked out, honestly, what we could build properly in four months. The number was closer to twelve.

So the first real work was not engineering. It was going back to the client and saying no to most of what they asked for.

That conversation is the whole job. Everyone talks about execution. Execution is downstream of scope. If you accept an impossible scope, you have already failed, and everything afterwards is just the slow public discovery of a decision you made on day one.

The method was blunt. For every feature, one question: if this is missing on launch day, does a citizen notice, and does anyone care?

Parking payments. Yes. People park every day and hate fumbling for a coupon.

Council bill payments. Yes. It is the reason most people would ever open a government app at all.

A gamified rewards system with tiered badges. No. Nobody has ever opened a government app hoping for badges.

We killed the badges. We killed about twenty-five other things. Some were the client’s favourites, and saying so cost me two uncomfortable meetings.

Those two meetings bought us the project.

We built for a 58 year old on a mid range Android

Here is the assumption that kills most government apps: the team building it looks nothing like the people using it.

Our team was young, urban, on new iPhones, on fast wifi. Our actual user was in her fifties, on a mid range Android three years old, on patchy mobile data, in a town two hours from the capital. She had never used a super app. She was not going to explore. If it did not work in the first thirty seconds, she was gone, and she was going back to the coupon.

So we made unfashionable choices.

Big tap targets. The kind a designer calls ugly. Text you could read without your glasses. No hamburger menu, because she does not know what those three lines mean. No onboarding carousel, because she will skip it or quit. No clever gestures. Nothing hidden.

We tested on the cheapest Android phone we could buy, not the best one. If it was smooth there, it was smooth everywhere.

Every one of those decisions made the app look less impressive in a pitch deck. Every one of them made it work in a car park in Cameron Highlands.

Distribution was the whole game

This is the part people skip, and it is the part that turned the thing into real money.

A government app does not get used because it is good. Plenty of good apps get used by nobody. It gets used because you solved distribution before you solved the product.

We started from one place. Where these people were already standing.

They were standing at council counters, paying bills. They were standing at parking bays, looking for a coupon. So that is where the app went. QR codes at the counter, with a human being next to it whose job was to help you install it. Signs at the parking bays, so you could scan and pay without downloading anything at all. The bill that arrived in the post had the app on it.

We did not run a big digital campaign. We put the app in the physical places where the problem was already annoying someone.

The enforcement mattered too, and it was not our doing. The councils committed to going fully cashless. When the coupon stops being an option, adoption is no longer a marketing problem. If we had shipped the same app without that commitment from the councils, the numbers would look very different. Anyone who tells you their growth was purely product-led is usually leaving out the part where somebody else removed the alternative.

But there was a part of it we could not delegate. The enforcement officers were the ones who had to use the thing every day, in the rain, on their own phones, standing next to a car. If it did not work for them, nothing else mattered. So I went to Cameron Highlands and tested it in the car park myself, with the officers, on the ground. Not a demo in a meeting room. The actual bay, the actual phone, the actual man in the high-vis vest who was going to have to do this four hundred times a week.

You find things there that no amount of testing finds. And the officers stop being an obstacle and start being the reason it works, because somebody bothered to show up.

What broke

I am not going to pretend it was clean.

Payment reconciliation. The single hardest thing in the build, and we underestimated it badly. Money moving between a citizen, a payment gateway, a bank, and a government account, with everyone’s records having to agree at the end of the day. When they did not agree, someone had to work out why, by hand. We spent more late nights on reconciliation than on everything else combined.

Day one load. It held, but only just, and only because we got conservative at the last minute and over provisioned.

A vendor who went quiet. One integration partner stopped responding for eleven days at the worst possible moment. We built a fallback. I now assume, on every project, that at least one external party will vanish. It is not cynicism, it is arithmetic.

Physical servers in eleven council offices. We installed on premise servers in eleven different local council offices, thinking that was how you integrate an entire state’s local authorities. It was not the right call. Most of those councils were nowhere near ready to run anything in the cloud, and at least one of them, the Kuantan office, still had its server sitting in a physical room with none of the environmental or access controls that deserves. That is real physical risk spread across eleven separate buildings, for the sake of an integration problem that had other, less exposed solutions. I would not do it that way again.

The thing I would not do again

We had no meaningful data governance.

Audit trails were thin. Access control was looser than it should have been. If you had asked me at the time who inside the organisation could read a given citizen’s payment history, I could have given you an answer, but not a confident one, and certainly not one backed by a log.

We got lucky. Nothing happened.

Under Malaysia’s PDPA as it is actually enforced today, we would not get lucky. The exposure on a system holding payment records and identity data for a whole state is not theoretical. It is the kind of thing that ends careers and costs real money.

I now run a company that does data protection and outsourced DPO work, and a large part of why is that project. I know exactly how easy it is to ship something at scale and leave the governance for later, because I did it, and it worked, and that is the dangerous part. Getting away with it teaches you the wrong lesson.

So the honest summary is this: the delivery was good, the distribution was better, and the governance was a gap we survived rather than solved.

What generalises

If you are trying to ship something ambitious with less time and less money than the problem deserves, three things.

Cut the scope before you start, and take the uncomfortable meeting. It is cheaper than the meeting you will otherwise have in month three.

Build for the person who is actually going to use it, not for the person in the room with you. They are almost never the same person.

Solve distribution first. A product nobody can find is not a product, it is a hobby.

And build the governance in from the beginning. Not because it is virtuous. Because retrofitting it costs ten times more, and one day you will not get lucky.

Then, four months after launch, COVID hit, and every assumption in this piece about car parks and council counters got tested in a way none of us had planned for. That is a different story.