We Fixed Our Own Broken Process. Here's What It Taught Us
  • href="https://axeno.co/" > Home /
  • href="https://axeno.co/insight" > insights /
  • href="https://axeno.co/insight#toggle-blog" > Blog /
  • We Fixed Our Own Broken Process. Here's What It Taught Us

We Fixed Our Own Broken Process. Here's What It Taught Us

Every consultancy says it is good at solving problems. We would rather show you how we think than tell you, so here is a story that had nothing to do with a client brief and everything to do with how the Axeno team operates when something is broken.

It starts with our own reimbursement process.

The problem was sitting on our own desks

For a long time, reimbursements at Axeno ran entirely on paper. Someone would fill out a physical form, add up their own totals by hand, submit it, and then wait.

That workflow carried three quiet costs that most teams learn to live with:

  • Manual math. Every claim depended on a person adding correctly under a deadline, so small errors slipped through.
  • A black box. Once a form went in, there was no way to see where it sat or when it would be cleared.
  • Duplicate records. Because nobody trusted a paper trail they could not track, people kept their own copies of everything, just in case a form went missing.
  • Accuracy by default. The app does the math, so human error at the calculation stage disappears.
  • Full visibility. Employees get real-time status tracking, so the black box becomes a live view of exactly where a claim stands.
  • One source of truth. All the data lives in one place, so nothing gets lost and nobody needs to hoard backup copies anymore.

None of this was catastrophic on any single day. That is exactly why it survived for so long. It was the kind of friction a team absorbs without questioning it.

We decided to question it.

The decision to build instead of tolerate

The easy path was to accept the bottleneck as a fact of office life. Instead, we treated our own reimbursement pain the same way we treat a client's broken customer journey. We mapped the workflow, found where it leaked time and trust, and built a solution to fix it end to end.

The result was ExpenZ, an in-house digital tool designed to handle the full lifecycle of a reimbursement, from submission to approval to payout.

We built it as a modern full-stack application. Flutter and Dart handle the mobile experience so it works smoothly across platforms, and Java with Spring Boot powers the server side for reliable processing behind the scenes.

The impact was immediate and practical.

  • Accuracy by default. The app does the math, so human error at the calculation stage disappears.
  • Full visibility. Employees get real-time status tracking, so the black box becomes a live view of exactly where a claim stands.
  • One source of truth. All the data lives in one place, so nothing gets lost and nobody needs to hoard backup copies anymore.

The real lesson came after launch

Here is the part of the story that changed how we think.

Building the app locally was only half the work. The steeper learning curve started when we took it live. Moving from a working prototype on a laptop to a secure, hosted product in production turned into a crash course in real-world deployment.

The team went deep on server hosting and worked through the architecture of public and private IP configurations to keep the backend properly protected. Building something that runs on your own machine is one skill. Standing it up in a live environment, where it has to survive contact with the open internet, is another entirely.

That transition also opened our eyes to a much wider security landscape. The app was built following sound practices from the start, and deploying it live still surfaced questions we had not fully appreciated before. We came away with a sharper understanding of data protection, the reality of threats like DDoS attacks, and the value of advanced architectural safeguards such as hardware-backed keystores and token rotation. Every one of those lessons now feeds directly into the next phase of what we are building.

Why this matters beyond one internal tool

There is a reason we are telling this story publicly rather than filing it away as an internal win.

The instinct behind ExpenZ is the same instinct we bring to every client engagement. We look at a process, find where it quietly costs people time and confidence, and rebuild it so the friction goes away. The willingness to fix our own workflow before anyone asked us to is the clearest example we have of how the team is wired.

Building ExpenZ came down to ownership. The code was the straightforward part. The lasting value was in taking a frustration nobody else had bothered to challenge and carrying it all the way through to a deployed, secure, genuinely useful product, learning the full end-to-end reality of shipping software along the way.

Sometimes the best projects start with your own daily annoyances. You just have to be the kind of team that decides to do something about them.