EPADS: Pakistan's federal e-procurement platform

Context

EPADS is Pakistan's federal e-procurement platform. Emenac Inc. delivered it under a government contract, and I led a team working on it during my time there.

I'm not going to publish internals of a government system, and I wouldn't want a client of mine to do it either. What I can describe is the shape of the work and what I took from it.

My role

I started at Emenac as a frontend developer and moved through full stack to senior engineer and project lead. On EPADS I led a team. That meant planning the work, reviewing code, deciding what shipped and when, and talking to the people who depended on the result.

What a system like this has to do

Procurement software has an unusual set of constraints.

Every action has to be traceable. Someone will ask who approved what, months or years later.
Different people need different views of the same record: officers, vendors and auditors.
It handles vendor identity and compliance checks, so it talks to other systems that you don't control.
Mistakes are public. A bug in a shopping cart annoys a customer. A bug in a tender process can end up in front of an auditor.

The stack

The platform ran on React for the interface and PHP with MySQL on the server side, with WebSockets for live updates. That is not a fashionable list. It was the right one for a team that had to hire for it, host it on government infrastructure and maintain it for years.

I'm repeating this because people ask whether I'd have chosen differently. For that project, no. Choosing the stack your client's people can actually maintain is part of the job.

What I took from it

Boring stacks survive. Government systems outlive the people who build them. Pick technology that will still have maintainers in ten years.
Other people's systems fail. If your platform depends on an external service, design for the day it is slow or down. Show the user a clear state instead of a spinner that never ends.
Audit trails are a feature, not a bolt-on. Retrofitting them is far harder than building them from the first table.
Real-time features need honest reconnect logic. Connections drop. The hard part is not opening the socket, it's what the screen shows when it comes back.

What I'd do again

Write down the rules for who can do what before writing any screens. On a project with many stakeholders, the permissions model is the product.

Context

EPADS is Pakistan's federal e-procurement platform. Emenac Inc. delivered it under a government contract, and I led a team working on it during my time there.

I'm not going to publish internals of a government system, and I wouldn't want a client of mine to do it either. What I can describe is the shape of the work and what I took from it.

What a system like this has to do

Procurement software has an unusual set of constraints.

Every action has to be traceable. Someone will ask who approved what, months or years later.

Different people need different views of the same record: officers, vendors and auditors.

It handles vendor identity and compliance checks, so it talks to other systems that you don't control.

Mistakes are public. A bug in a shopping cart annoys a customer. A bug in a tender process can end up in front of an auditor.

The stack

I'm repeating this because people ask whether I'd have chosen differently. For that project, no. Choosing the stack your client's people can actually maintain is part of the job.

What I took from it

Boring stacks survive. Government systems outlive the people who build them. Pick technology that will still have maintainers in ten years.

Other people's systems fail. If your platform depends on an external service, design for the day it is slow or down. Show the user a clear state instead of a spinner that never ends.

Audit trails are a feature, not a bolt-on. Retrofitting them is far harder than building them from the first table.

Real-time features need honest reconnect logic. Connections drop. The hard part is not opening the socket, it's what the screen shows when it comes back.