ValidationPortal

What it is

ValidationPortal is the internal web tool I built at Eseye and looked after until I left in March 2024. It started as a lookup screen on the support desk and grew into the front end that about forty people used every day, across support, finance, sales, technical consultancy, customer success and dispatch.

I wrote it in Perl (a language I did not know when I started it), and I ran the Linux server it lived on as well.

The problem

When I started on the support team, answering most questions about a SIM meant writing SQL by hand against several databases. That needed specialist knowledge of which system held what, it was easy to get wrong, and it was slow when a customer was waiting.

So the first version did one thing: show what was going on with a SIM, in one place. Then the next most common question got a page, and then the next one.

What it grew into

• One view of a SIM. Look it up by any identifier you happen to have, and see its connection state, sessions, messages and history from every system on one page, with each value showing which system it came from.
• Live diagnostics. Test a device in real time with pings, SMS and USSD, so support could see the problem rather than guess at it.
• SIM lifecycle. Provisioning and deprovisioning, and IMSI (International Mobile Subscriber Identity) allocation and loading, including over the air.
• Network steering. PLMN (Public Land Mobile Network) steering, so a device prefers the network it should.
• Credit control. Cashflow reporting, flagging late payers, suspending accounts (and telling support first), and bulk enabling or disabling services so a customer could not run past their credit limit.
• Roles and permissions, so each team saw what it needed and nothing it should not.

None of that was planned up front. Each piece arrived because a team kept asking for the same thing, and building the page was quicker than answering the question again.

It outlived its replacement

Eseye rebuilt its platform over several years, and the first attempt at replacing the old tooling was a JavaScript and Node rewrite, shipped piece by piece. Each piece did its job slightly less well than the thing it replaced, so people kept falling back, the cut-over never finished, and the Perl tool I had built carried on doing the work.

What I took from it: a replacement has to land at least as good as the thing it displaces, or the old path never dies and you end up running both.

Six months after I left, Eseye's COO wrote that the tools I built "have proved invaluable and continue to be used in the business to this day".

Handing it over

Before I left I wrote a handover pack for the next developer and for the people using it: page-by-page documentation, 19 walkthrough videos, flow diagrams and API collections. A tool forty people rely on should not depend on one person remembering how it works.