What launching Residex taught me about building products online.

If you travel between countries for work, have a second home or spend long periods abroad, keeping track of your days can become messy and stressful very quickly. One unplanned trip, a few extra days with family or a work visit you forgot about can change your position for the year.

I was working with an expatriate-advice company that helped clients understand their tax residency, but the process was entirely manual. Clients would verbally tell a consultant how many days they had spent in different countries, and the consultant would produce a Google Docs report outlining their position.

I thought: why not create an app where an adviser—or the client themselves—can add or upload travel data, log visits throughout a tax year and produce a document to help support their position with tax authorities? Better still, it could help them plan ahead: minimise tax exposure and spend the right amount of time in each country they visit.

With a clear friction point for advisers, I began developing Residex. I wanted individuals, advisers and firms to be able to track days, plan residency and produce useful outcomes when travelling between countries for work or pleasure.

I have seen people try to be careful with their residency, only to reach the end of the tax year and find that one extra trip to the UK put them over a threshold. That is why Residex is designed for more than retrospective tracking. Scenario Lab lets users test days and ties across countries, so they can map out the year ahead.

I started with Angular on the front end, partly because it was familiar. I have produced Angular courses and, ten years ago, it was the shiny new framework. Today, I would likely choose a cleaner, more forward-looking setup such as Next.js and React.

Angular is not bad. It is built for scale and it works—which is enough for an MVP. I used MongoDB for the database for the same reason of familiarity, though PostgreSQL may have been worth more serious consideration.

The lesson is simple: once you commit to a stack, changing course can become expensive in time, effort and money. Pick the stack that best serves the app, not simply the one that is familiar or fashionable.

The uncomfortable truth is that most people do not care about your app. They care about having their problem solved quickly, quietly and efficiently. Before I wrote any code, I emailed the company database to see who would be interested in the idea. The response was favourable, so I started building the MVP.

I had learned from a previous company not to build an entire product before testing the market and getting users. But I love building, so I kept adding. The early MVP gained a few paid users, which gave me confidence, but the feedback—particularly from individuals—was that they did not need every feature in the full Residex suite. Many simply wanted to track their days in different countries.

That led to a simpler, lower-priced standalone tracker. People who need more can move into the full product for planning, evidence-vault storage and reports.

The results so far have been encouraging. People like the tracking and residency-risk features; advisers value uploading client travel CSVs and using AI to interpret documents. I also suspect Scenario Lab may become a standalone product: a way to explore residency and plan future travel with tax in mind.

But the thing I keep coming back to is that most people do not need another spreadsheet. They need clarity. They need to know how many days they have spent somewhere, whether they are close to a limit and what an extra trip could mean before they book it.

You do not need to understand every tax rule before getting started. The first step is simply knowing where you have been and how many days you have spent there. Start simple, then use the planning tools, reports and evidence storage when you need them.