How I solo-built and maintained an entire business suite for a €30 million company for over a decade – and what I learnt about software

Erik Hazington — Tue, 27 Oct 2026 11:25:36 +0000

Today, I am still the only person working in IT at a globally operating private aviation company with 70 employees working from different locations around the world, 60 brands, 150 phone numbers and €30 million in revenue in 2025. We offer a 24/7 service in 14 languages for 30 different aviation services, and almost everything runs on the business suite that I built over the past 16 years and still maintain myself. In other words, we are one company operating as 60 different companies. Our unique multi-brand business model is the main reason why off-the-shelf software never worked for us. We also had no funding and thus no room for failure when we started.

How it started

It was December 2009 when four former employees of an air event agency started a new business together for private aviation services without investors. As usual in small teams, everyone was working in sales while owning other specific corporate roles. One became the CEO, another one was responsible for marketing, and the third one focused on office management and accounting. I took over IT because I was always interested in technology and problem-solving. Luckily, our main business idea wasn't new, so we could purchase the brand and four websites from our former employer, which had gone bankrupt, and continue the managed hosting service contract. We also took over the ugly, cluttered and cramped Microsoft Access application, which was our CRM at that time. Besides being an awful piece of software, it was a necessary starting point. And as with any successful company at that time, we did a lot with Excel, but fortunately, this isn't going to be either a Microsoft Excel or a Microsoft Access success story.

However, after setting up our local work environment, including the ISDN phone system and desktop PCs, I started my first actual "software project" in January 2010. Since everyone knew that the Access application needed at least an overhaul, I started improving the UI. I first added tabs and consistent spacing, grouped related elements and removed unnecessary ones. I also improved the labels. Over time, I continued improving the application and added new modules like a contract management tool that allowed us to create contracts as Word documents with different brands and layouts. This fixed many issues caused by editing copies of existing contracts. Since I was pretty good at Microsoft Excel, I also built a UI using VBA on top of our existing aircraft registry and partner spreadsheets to improve search, planning and data retrieval. We actually used this tool quite a lot to plan flights and estimate buying prices.

The cost of growing

Software is "living", and its main purpose is to solve human problems. This means that as your company grows and changes, your software must change, too.

In 2011, our team grew from four to seven employees, and the monolithic Microsoft Access application over our NAS became an unreliable bottleneck. Fortunately, there was a native solution that allowed me to split the application into a frontend running locally on the user's computer and a shared backend stored on the NAS. This drastically improved the reliability and performance of the application. But there was a downside – I now had to manage two different applications and distribute new frontend releases to every device. This was doable with seven employees, but it wasn't scalable. Some weeks after splitting the application, we replaced our desktop computers with notebooks and added docking stations to realize portable workplaces. We also started working from home more often, and so the requirements for our CRM application changed. In other words, being able to connect remotely to the backend became necessary.

But it's still 2011 and our head office was located in Germany, which simply means that our internet upload speed was terribly slow, and thus VPN wasn't stable enough to access the Microsoft Access backend remotely. VPN wasn't a solution. So I started researching another approach and learnt about managed LAMP web hosting services and the option to use MySQL through VBA as a SQL backend in the Microsoft Access frontend application. This wasn't straightforward, and I had no one to ask, but after reading documentation and fiddling around in my test application, I eventually managed to migrate from ACE SQL to MySQL over TCP, and damn, I was so proud of myself and I think this is when I started to love software development. A positive side effect: The backend over the NAS and VPN in general was no longer needed.

Within less than 18 months, our requirements, business needs and tools had changed significantly. And that's when I noticed something very important about software and its role in a business: Software is "living", and its main purpose is to solve human problems. Of course, it doesn't live in an animal way of living, but it evolves and changes with business needs driven by user and client expectations, as well as environmental requirements and regulations. In other words, corporate software systems never seem to be finished, and after doing this for over 16 years, they certainly never are.

My first web application

Our business model was special. Too special for off-the-shelf solutions. Further, every penny mattered, because there was no VC funding, so we couldn't put money on the table to solve complex problems. In fact, there wasn't even room for failure, which made every software project even more challenging.

A consequence of "living" software was that new solutions always opened doors for new opportunities, but it also made new problems visible. That's why migrating from ACE SQL to a web-based backend let us eventually realize how terrible the UI and performance of our managed CMS was, and how these problems negatively affected the performance of our websites. We asked our provider to fix these issues, and to make our websites available in other languages – but he couldn't. Since we had experienced how slow, unreliable and expensive our managed website provider was, we decided to look for alternatives. But it wasn't long before I noticed that native multi-site CMSs didn't actually exist the way we expected them to be. This realisation also explained why our current CMS was so terrible, and why our provider was so hesitant to make changes. It was a hacky disaster just to make our requirements possible. That's when I decided to build my own multi-site CMS in late 2011, because there was a perfect opportunity for such a project, as we had already planned to add two new brands and websites to our portfolio.

At that time, I could code a little in Java, Turbo Pascal and VBA, but I never built a web application before or even a website. This made it an even bigger challenge, but I loved it! Since I found managed LAMP services during my web-based backend research for our Microsoft Access frontend application, I decided to go with PHP 5.3 after further research, because PHP seemed to be the standard for web applications and websites at the time. At least, PHP was offered by almost every provider and training resources were widely available for free. But I don't want to dig too deep into this CMS, because it was superseded by another application built from scratch in 2016, and my initial XML data-based approach was a terrible idea. However, I was able to build the multi-site CMS, and to host our two new websites in just a couple of weeks. In retrospect, I don't think that this solution was secure and enterprise-ready by today's standards, but it worked, was fast and stable, and solved our seemingly unique problem that established CMSs like Drupal, Joomla, WordPress or TYPO3 couldn't solve. In early 2012, I migrated the remaining websites to our own custom CMS, which resulted in a noticeable five-figure annual savings. Since our company grew organically, every saving mattered.

From CMS to business suite

Nobody planned to build a business suite, including me. It just happened as I kept solving one business problem after another.

This chapter continues from the same realization as before: Solved problems always seem to make new problems visible. It seems like an endless circle of solving problems and finding new ones. And this continuous process eventually led to the making of an entire business suite. Not because it was planned from the beginning, but because it turned into one.

For example, one annoying task we had was managing the login status of our different ring groups in the ISDN phone system (PBX) that represented our different brands. A related problem was configuring the call forwarding for after-hour services. Both settings were only possible through an outdated, unintuitive and slow web backend of the PBX or through shortcuts on the deskphone, which didn't have enough function keys to solve this problem. This meant, whenever someone forgot to log out of a ring group, someone had to move physically to the office and fix it. When after-hour services had to be handed over, someone had to go to the office, too. The backend of the PBX was also limiting access to one user at a time. But replacing the phone system wasn't something you could just do, so I thought about a technical solution that worked around the available web backend.

First, there was no REST API, but the request patterns were easy to understand and the response was simple to parse, too. So I bought a cheap mini-computer, placed it next to the phone system, and installed Ubuntu and LAMP on that machine. I then "hacked" – or better reverse-engineered – into the phone system to build my first REST API with PHP by the end of 2012. I managed to configure the firewall to limit direct access to the REST API to internal networks and the remote web server already running our custom multi-site CMS. Since I could now remotely control our phone system, I added new modules to the CMS to manage those nasty ring groups and call forwarding, too. Since those tasks were quite slow, I also added my first background tasks, because login could take between 30 and 60 seconds. By today's expectations, this solution wasn't great and the connection between mini-computer and the web server wasn't even encrypted. But it's 2012 and HTTPS wasn't really a thing yet. In other words, almost everything was unencrypted at this time. However, adding a PBX module to the web application turned our CMS into a multi-purpose web application or, in other words, to the first bare version of our business suite.

With a modular web application available, I suppose the next steps are obvious. We first added a call history to the business suite for better call insights, especially to improve missed call monitoring. Then I decided to move everything else to the web application, because maintaining three applications was tiring and time-consuming. I started with the flight planner and then migrated the Access CRM in early 2013 step by step. This went quite smoothly, but generating Word documents on the managed LAMP server was another tough challenge. That's why we continued to use a tiny Microsoft Access desktop application, whose sole purpose was to generate those Word documents. One year later, in early 2014, I finally dropped all applications based on Microsoft Access and Microsoft Excel. It wasn't an era, but the shift in just four years was huge.

Tech debt and building from scratch

I learnt from my mistakes how type safety, integrated refactorings, clean code, and tools impact productivity and maintainability. Once you stop caring and cleaning up from time to time, an application just dies. Regardless of how important it is.

As time moved on, the web application got better and better. It even ran on PHP 5.6 in 2015. But the truth is that I noticed how much harder it became to maintain the application. The codebase was never refactored and became messy. I mean, I didn't even know what refactoring was in 2015, but I felt the consequences of a messy codebase. New features took longer, and debugging and fixing bugs also took more time. So I decided to build the entire application from scratch, and retire the old one. Well, almost from scratch, because migrating a production database turned out to be not that simple, especially when the database was still used in another production application that had to be available 24/7 for eleven employees, and when you have never done something like this before. Side note: This means that the number of employees had almost tripled in less than six years, but it's still tiny compared to today.

After a couple of weeks of planning the migration, I started to build the new application in January 2016. With almost five years of experience, I decided to go with PHP 7.0, use Composer as dependency manager, adapt PSR-4 autoloading and namespaces, and use the Zend Framework 2 (ZF2) as foundation for the MVC-based application. I also stopped picking up the phone and doing sales. While I fell behind in the internal sales ranking, I was now able to solely focus on managing the IT and building our business suite. In terms of roles, I was and still am the CIO and CTO, the product owner, project manager, designer, tester and full-stack software developer. But giving up on sales wasn't the only major shift. I also switched from Windows to macOS, and from NetBeans IDE to PhpStorm. All these changes, especially the combination of PHP 7's strict typing support, its improved and more accessible ecosystem including PHPUnit, PHP-CS-Fixer and Composer, as well as the improved dev experience using a Unix-based OS and PhpStorm as an IDE were massive game-changers for my productivity. That's when I learnt about the importance of developer tools, standards and strict types for developer experience and productivity. About four months later, the new application was ready. It had a responsive UI for mobile devices and was built more modularly. I also stopped using FileZilla for manual deployments via FTP and wrote scripts to deploy new releases instead.

When managed web hosting became the bottleneck

Just like every solved problem opened up opportunities for other improvements, better skills and more experience allowed me to do more as well. So much more that standard managed web hosting services eventually hit a wall.

It wasn't long before I noticed that I outgrew the capabilities of our managed web server with every new feature I added or planned to add in 2018. But with almost eight years of experience, I was now confident enough to set up and host the application on my own root server. The MySQL database, however, was still an exception and provided via a managed service for a couple of years after self-hosting the application. There were always a couple of things I wanted to try, like using nginx instead of Apache httpd. But this wasn't easy, because when you chose a managed service, then it was the LAMP stack you got. So the first thing I did was replacing Apache with nginx, and I still think nginx is superior in every way. But nginx was just the beginning. The new server allowed me to create cron jobs using Linux binaries, and to integrate those binaries and other programming languages into my own application to solve certain problems more efficiently, like parsing an encrypted KeePass file. It also changed the way I deployed applications and thought about software in general. The sheer number of possibilities to solve various problems was enormous, and the impact on performance was massive as well.

Just to show how much had changed over those eight years, let me explain how the application had evolved by 2018. For example, I refactored the CMS into a headless CMS to avoid backend slowdowns caused by traffic peaks from SEO bots. The frontend now ran on another machine and served 40 different websites in more than five languages. Including the headless CMS, the business suite now contained a CRM to manage cases, clients and contracts; an ERP system for accounting and resource management; an ISDN PBX control system that was later replaced by a VoIP PBX with even more functionality and an integrated softphone; a flight planner, a knowledge base (wiki) and a calendar. I may have missed something, because there are so many more features available today that I can't remember when I added those other features. But the most noticeable feature was that having all modules in one application allowed me to deeply integrate their functionality. For example, when we open a case, we immediately see all related communication items like phone calls, emails and WhatsApp, as well as contracts, case events, flights and files.

The next level: Docker, PSRs, TypeScript and a bridge

It doesn't matter how much experience you have, there's always a next level and a next bottleneck, too. Even though frameworks gave me a direction and clear path when I started to rebuild the application, they eventually led to a vendor lock-in. To avoid unnecessary complexity and bloat, it's better to follow open standards and to use components instead of full-fledged frameworks.

I've already learnt the importance of clean code, tools and strict types the hard way. But Docker and PHP Standards Recommendations (PSR) hit differently. Containerization, in particular, is probably one of the most influential and important changes in the history of software-making. There was no more "but it works on my machine", because the app runtime was now part of the source code and behaved identically on every machine, including production. I also no longer needed VMs to test the impact of compiling a new PHP version. Docker allowed me to work with a minimal host that could be configured with a single configuration file and a script, while all my apps and services ran in containers. Version conflicts and the risk of breaking the host were just gone forever. Instead of compiling on a host machine and manually cleaning up, I could just build in a container and retry in a clean one. After moving to macOS and PhpStorm, the use of Docker was the second time a new tool made me significantly more productive and changed the way I build and think about software and security. This is also the reason why I started to develop only in isolated and least-privileged containers with self-compiled binaries in 2019. In general, Docker made me more aware of security and the importance of isolation and different levels of defence. But it wasn't only containers that changed the way I built software.

It was early in 2019, when I first learnt about other PSRs that are not PSR-4. Especially those PSRs with interfaces, like PSR-7, PSR-11, PSR-15 and PSR-16 made me realize that full frameworks might become a hard vendor lock-in. They force you to solve problems their way, even if you would have done it differently. Sometimes their preferred way is inefficient. I started to see how much bloat I was carrying in my vendor folders, and that frameworks often prevented me from upgrading to the latest PHP version. Many breaking changes resulted in large and unplanned refactorings, and this was a problem because I couldn't afford tech debt as the only person in IT, and I knew exactly what happens to applications without refactoring and modernization. So I abandoned ZF2 and MVC, and refactored the application to be based on PSR request action handlers, middleware and other component-based frameworks, like those from Symfony. This means that I still use some third-party libraries, but I stopped using them directly. Instead, I built my own library as a bridge with my own interfaces and services that wrap vendor logic as replaceable adapters. I know that it might sound like unnecessary extra work, but in the end, the extra time I spent planning how to use them and building my own interfaces and services was always worth it, because whenever a vendor introduced breaking changes or had to be replaced, I only modified my adapter, while the application code remained completely unchanged. As a result, the number of unplanned and large refactorings decreased significantly, and it was me who decided when a refactoring or upgrade was necessary.

Last but not least, I want to talk about TypeScript. While my app is primarily written in PHP, there is also a lot of JavaScript, CSS, Python and Bash involved. When I started building my application, interactive UIs with JavaScript were painful. That's why almost everyone used jQuery, even if it was too forgiving. The implementation of JavaScript was simply too fragmented across different browsers, so relying on JavaScript itself was not a good decision. However, with tools like NPM for JS libraries, Sass, Webpack, and TypeScript things changed in 2019. They allowed me to drop jQuery and build interactive user interfaces with strict types. While I was already aware of the importance of type safety, TypeScript just confirmed the positive impact of type strictness for reliability and maintainability of software. Risks like type mutations may not be a problem in small scripts, but they are deadly in large applications.

The app, tech stack and company today

Fortunately, we never lost data, and never had major downtimes or faced data breaches. The application has turned into a mature, stable, fast and feature-rich business suite. But if I'm honest, the application is just the byproduct of my journey. In the past 16 years, I improved my skills and understanding by solving new problems every day that were often far above my current capabilities. In other words, a good application depends on good developers.

16 years later, the company has grown to a global aviation company with 70 employees around the world. Since I am still the only person in IT, the main tech stack and application have not changed significantly since 2016, or more precisely since the first major refactoring in 2019, when I abandoned frameworks. Refactoring became part of my day-to-day work to ensure clean and DRY code. This was the foundation for keeping the app modern over the past seven years. As of today, the application runs on PHP 8.5 and uses many modern PHP features. I've added PHPStan to my toolset and I'm aiming to reach level eight by the end of 2027, while many libraries of my own framework already pass at level ten. The container is now based on Debian 13-slim and contains Swoole for the web API, Valkey, and ProxySQL. I also added more root servers to the stack and moved the SQL database and file server to a separate machine, along with automated and encrypted Borg backups, that is only reachable over a VPN from the application frontend and via SSH from my DEV machine. Everything is rootless. Over the years, my focus naturally shifted towards security, and every decision I make today starts with questions about security and architecture.

I also started using Traefik as a reverse proxy and for SSL termination. I created my own CI/CD tools and binaries for server management, and recently migrated from private GitHub repositories to Forgejo, including isolated and secure action runners. But not only did the infrastructure change, the application continued "living" and changed as well. It now offers an integrated softphone, a deeply integrated WhatsApp Business chat for 15 different numbers, a unified communication view for emails, calls and chats. Furthermore, it provides more than 100 statistics and insights, a multi-user, ACL-based password vault built on KeePass, with an autofill browser extension. I also self-host a LanguageTool server with my own client implementation that works without a browser extension, time tracking that complies with European law, a web fax module (yeah, still necessary), passkey support and some other unique features and security implementations, especially in the email client. I even considered documentation and built an automated system based on AsciiDoc and Hugo.

In other words, the application matured into an all-in-one business suite with a total of more than 600,000 handwritten lines of code in various programming languages (I know LOC is a terrible metric), utilizing every possible OS-based optimization I know. As of today, the worst P99 response time in real-world simulations is about 500 ms (with hey), but most modules respond in under 250 ms, while the frontend has a P95 of at most 150 ms, based on the average number of visitors. Our hourly Borg backups are automated, encrypted and restorable. The app also reached high availability with 99.99 % uptime, while new versions are released automatically via Forgejo workflows in about 60 seconds. Excluding my own salary and communication costs, the application currently operates at 0.04 % of annual revenue for production use and development.

How I survived as the only developer

I just couldn't afford technical debt, and systematically avoided it. Just like a clean and well-organized kitchen allows you to prepare meals faster, clean code principles and refactoring allowed me to move fast and efficiently without breaking things.

Before I answer the question of this chapter, let me first elaborate on my situation. I wasn't just the only person working in IT, responsible for every IT role and being available 24/7 for emergencies. I am also a self-taught developer who worked in sales and understands the business. As the only remaining co-founder, I am also act as a strategic adviser on business decisions. This was only the situation at work. There is also a personal life. I'm married, a father, and studied part-time over the past eight years, while still working full-time and being fully responsible for the entire IT. In other words, the situation was more difficult than writing and maintaining such an application as a single developer already is. And yes, I see my family every day and I usually get enough sleep. I even have vacation without fixing bugs. But how is this possible without burning out?

The answer is simple and strange at the same time. To make a long story short, the circumstances just forced me to be highly efficient. They forced me to optimize and automate my workflows, to keep my codebase clean, to avoid bugs, and to use SOLID principles, without knowing about them. I just couldn't afford technical debt and bugs, and fortunately, I learnt first-hand what it means to stop when your application has become unmaintainable. That's all from the developer's perspective. But I also understand the customer's perspective very well. The customer wants functioning software. That's it. But as I said before, software is "living", which means that "it works" is always only the beginning, just like the birth of a child is only the beginning of being a parent. When you create software that other people depend on, you can become responsible for a very long time. This means that clean code and architecture, as well as refactoring and modernization are essential if you want to move forward efficiently and fast without breaking things. Over time, you build a mental model of the application, so you can make decisions and fix issues faster, understand the consequences of features and how they might conflict with one another, and most importantly, know or at least understand what your users need and want.

Final thoughts and what I learnt

The codebase is the truth. And only if you understand the "truth", you can build a reliable, secure and maintainable application.

Before I wrap up, I would like to summarize what I've learnt. I won't repeat the refactoring and clean code part. I think it's clear now. But in the end, it's all about agency, understanding, analytical thinking, learning, and simply trying. And I think it's quite obvious. Just look at how much has changed in the last 10 years. If you look back at your work from even five years ago, it should be significantly different from what you do today. And I don't mean that AI now writes all the code for many developers; that's another story. The internet has changed, our tools have changed, technology in general has changed over and over again. Which leads to the conclusion that software engineering requires a unique skill set that allows you to adapt quickly, learn fast and solve new problems. Further, you must understand that you are responsible for what you are doing in your codebase. It simply doesn't matter how fast you can build when your application isn't reliable, secure and can't be maintained for years. Otherwise it's just abandonware.

There is also another thing to consider when you're dealing with feature requests as the maintainer of an application. Many of them have one thing in common, regardless of whether it's an internal or purchased application: Users tend to describe problems based on current solutions within a narrow context. This means that you cannot just implement feature requests without understanding the underlying problem and the application itself. For example, some changes would have caused significantly more work for other users without solving the user's actual problem. This is the reason why I always ask for the user's goal, and why I primarily work goal-driven. Sometimes the user is right, sometimes changing the process is the better solution, and sometimes the user is just wrong. Since you are responsible for the application, you must ask these questions, but beware: many users hate this because they came to you with a solution and the expectation that you just do it. But feature requests are not orders. Understanding what users really need is hard. Even for humans. And this is why I think that using AI to automatically process and build features based on user requests is a bad idea.

Last but not least, I truly believe that companies should own their internal core systems because business needs and requirements change all the time, so you need to be able to adapt quickly, and you need agency, too. Software, especially internal core systems, has become the operational foundation for every modern company. When these systems stop working, you have a serious problem. There are probably more lessons, like how understanding lower-level systems makes you a better developer when working in higher-level languages, or that you shouldn't be the only person in IT, but I think I've written enough.

P. S. You may wonder why I am still working alone in IT. The main reason is efficiency. While I was building the environment for a team, I couldn't focus on hiring. I also couldn't afford to lose time on training someone, because my time was quite limited as a one-man army, father and student. However, I reached multi-tenancy in my application this year, and thus can now let someone work on a copy of my application without production data. I also graduated this year, so I have more time available. In other words, by 2027, all requirements will be met to employ two more developers and my time as a solo developer might end.

DEV Community: Erik Hazington