--- title: "What Five Years of Building a Company Taught Me About Software" description: "The principles that survived five years of running HMD Corporation and the assumptions that did not" date: 2025-08-10 category: Engineering readingTime: "3 min read" --- Five years of building software and running a company. A multinational holding company with four divisions. An acquisition. A team of developers. A few failures I do not talk about enough. This is what I actually learned. --- I have never regretted shipping too early. I have frequently regretted planning too long. The first version of HMD Payments had exactly three API endpoints. This website has been redesigned four times. None of those first versions were good, but all of them were shipped, and all of them taught me something that planning never could have. The market does not care about your architecture diagrams. It cares about whether your software solves a problem. You cannot know if it solves a problem until people use it. --- Every system you build reflects what you understood at the time. The early projects at HMD Developments were single-process applications. That was not a bad decision. It was the right decision for what we knew and what the projects needed at that point. The distributed, multi-service architectures came later because the requirements changed, not because we should have "done it right" from the start. I see junior developers agonise over architectural decisions for projects that do not have users yet. Build what works now. Rebuild when you understand the problem better. The second version will always be better than the first. That is how learning works. --- Not all technical debt is bad. Some of it is a strategic choice: shipping faster now in exchange for cleanup later. The key is knowing which debt to take on intentionally and which debt is accidental. Good debt sounds like this: "We will use a simple JSON file instead of a database for now." You know the limitation, you accept it, and you have a plan for when to upgrade. Bad debt sounds like this: "Why is this function 300 lines long and nobody knows what it does?" That was not a choice. That was neglect. I track technical debt explicitly. A `DEBT.md` file in each project lists known shortcuts, why they were taken, and when they should be addressed. Making debt visible prevents it from becoming invisible. --- Over five years, I have become increasingly aggressive about removing code. Every line is a liability. It can break, it needs maintenance, it increases cognitive load. Before adding a feature, I ask: "Can we solve this without code?" Sometimes the answer is a process change, a configuration update, or a conversation with the user about what they actually need versus what they asked for. The projects I am most proud of are the ones with the least code for their capability. --- Nobody has ever chosen Chat Guard because it is written in TypeScript. Nobody picked HMD Payments because we use PostgreSQL. Nobody visits this website because it runs on Next.js 15. Users care about three things. Does it work? Is it fast? Does it solve my problem? Technology choices matter for developer experience and operational capability. They do not matter for user adoption. Choose technologies that make your team productive and your system reliable. Stop optimising for CV-driven development. --- As HMD Developments grew, I had to decide what to do myself and what to delegate. The hardest part was not finding good people. It was letting go of control. The first time I reviewed a pull request and thought "I would have done this differently," but the code was correct, efficient, and well-tested, I had to resist the urge to request changes. Different does not mean wrong. My way is not the only way. It was humbling. --- I burned out once. It was not dramatic. No collapse, no breakdown. Just a gradual loss of interest, followed by decreased output, followed by mistakes in production. The truth is the journey has not been linear. Burnout happens when you consistently spend more energy than you recover. The fix is not motivational. It is structural. Set boundaries: no coding after 10 PM, no exceptions. Automate the tasks that drain you. Take breaks before you need them. Scheduled rest is cheaper than unscheduled burnout. --- Publishing code is not charity. It is communication. Every open source project I have released has made me a better developer. Code review from strangers is humbling. Issues from users reveal assumptions you did not know you had. Pull requests show you approaches you never considered. I covered the licensing side in [Open Source Licensing: What I Learned the Hard Way](/blog/open-source-licensing-lessons), but the human side matters just as much. Open source works when it is a conversation, not a donation. --- The habit of writing (blog posts, documentation, design documents, even this reflection) has compounded more than almost any technical skill. Clear writing requires clear thinking. If you cannot explain a system in plain language, you do not understand it well enough. I started this blog to share what I had learned. It became a tool for learning itself. Writing about a problem forces you to confront the gaps in your understanding. --- Five years from now, everything I know will be partially wrong. Frameworks will change. Conventions will evolve. The companies I am running today will look different tomorrow. The point was never to be right forever. The point was to keep building.