Okay so I will eat my words when I ever said… “we can just build it ourselves” with a certain naivety and nonchalant attitude. It’s harder than it seems but I stand by that it was worth it.
You might have seen my rant recently about a piece of technology we'd been paying a significant amount of money for over the past six years. When we gave notice, the response was a simple, "Thanks for letting us know." It hit a nerve. After all that time, investment and partnership, it felt impersonal.
But this isn't really about that service provider. It's about the journey we went on as a team to bring a critical piece of technology in house and everything that comes with making that decision and a few learnings...
The idea had been sitting on our to do list for longer than I would care to admit. Like many businesses, we knew there were benefits to owning more of our tech stack, but it was always difficult to prioritise. We had clients to service, products to improve, sales targets to hit and a seemingly endless list of projects competing for attention. Bringing technology in house felt like one of those important but is it business critical initiatives that kept getting pushed into the next quarter.
What became immediately clear was that building something yourself is very different from buying it. When you purchase software, you're effectively outsourcing complexity. When you bring it in house, that complexity becomes yours to manage.
The first consideration was ownership. Who would be responsible for the product? Not just the development, but the ongoing maintenance, roadmap, support, security, infrastructure and future enhancements? A vendor takes care of a lot behind the scenes. Once you're on your own, there is nowhere to hide.
The second consideration was knowledge. We had spent years using the platform, but that didn't mean we fully understood every process, dependency and workflow. Before writing a single line of code, we had to map out exactly what the technology did, what problems it solved and what functionality users genuinely valued. Unsurprisingly, we discovered that some features were essential while others had barely been touched in years.
Then came the people element. Bringing technology in house isn't purely a technical project; it's a change management project. Internal teams need confidence that the new solution will work, stakeholders need visibility of progress and users need reassurance that they aren't losing functionality they've come to rely on. Communication became just as important as development.
There was also the financial aspect. On paper, replacing a licence fee with an internal solution can look like a straightforward cost saving exercise. The reality is more nuanced. Development costs money. Testing costs money. Ongoing support costs money. The real value comes from flexibility, control and the ability to innovate at your own pace rather than being tied to a vendor's roadmap.
Perhaps the biggest lesson was recognising that bringing technology in house is not a project with an end date. It's a capability. Once you own the technology, you're continuously improving it, refining it and adapting it to meet changing business needs.
Looking back, it was 100000% the right decision for us. We now have greater control, deeper understanding of our own processes and the ability to move faster when opportunities arise. But it's not a decision that should be made lightly. The technology itself is often the easiest part. The hard part is committing to the people, processes and long-term ownership that come with it.
That's the part nobody talks about when they say, "We should just build it ourselves."
