Why we build our own technology

When you start building something, the shortest road always looks the same: take the tools everyone uses, put them together and go. It often works. But what you build that way looks like everything else, and it depends on choices other people made.

We chose a different road. The tools at the centre of our work, we build ourselves. Where building them makes no sense, we choose open software: software we can read, understand, change and grow along with Nimbune.

This isn’t about pride. It’s about control, and about quality.

A tool we built is a tool we know inside out. We know why it works, where it can break and how to make it better. When something goes wrong, we don’t wait for someone else to make it a priority: we fix it. When we need something new, we add it. Our work never stands still because of a decision taken somewhere else.

There is a deeper reason too. The way software is built is changing fast, and everyone’s tools are changing with it. If you only use the tools everyone has, you get the results everyone gets, at the same speed as everyone else. If you build your own, you get to decide where to be faster, more precise, more careful. That is where an ordinary product and a well-made one part ways.

Building your own technology has a cost, and we won’t pretend otherwise. It takes time at the start, exactly when running would feel easier. It means stopping to think before writing. It means looking after what you’ve built, for as long as you use it. That is why we don’t build everything: we build what is central. For the rest we use reliable services and the official tools of the platforms we publish on, and only where they are truly needed.

The line between the two isn’t always obvious, so we ask the question every time. Does this part make our work better than it could be otherwise? If the answer is yes, we build it. If it’s no, we pick the best open software or the most solid service there is, and move on.

The first result is Nimbune Core, the system we use every day to run every project: priorities with their reasons, decisions, memory, a stack checked every day and work sessions with AI. Around it sit the shared components that every product and every Enterprise Program project starts from. Nothing we build stays tied to a single project: it moves on to the next one, improves with use and joins the rest. Over time, tools turn into a way of working. And it’s that way of working, more than any single tool, that lets us build products meant for millions of people.

We’re at the beginning. Foundations take patience, and we’re laying them one at a time. But every piece we add makes us a little freer and a little more capable. It’s the reason we exist.