At madewithlove, we embrace brownfield software products. We believe that even the most outdated legacy code delivers value and needs to be cherished.
We often push back against the idea of complete rewrites and have been very vocal about the negative impact such a rewrite can have on a business. In 90% of cases, upgrading and improving the existing product gradually is better.
But sometimes, we hit these 1 in 10 scenarios, and Impact Us Today was such an exception.
The big advantage of a rewrite is the clarity of your path. You know exactly what you want to build. The entire product was built in a few months because we knew already where we needed to go.
Jef Daniels, CEO Impact Us Today
In this interview,
Andreas and CEO Jef Daniels discuss what led them to the decision to start from scratch and the lessons they learned along the way.
Impact Us Today is a platform that facilitates energy-efficient home renovations by connecting homeowners with qualified contractors. It offers an integrated system that translates homeowner queries into price quotes from reliable contractors, ensuring a smooth renovation process. The platform helps with energy-saving upgrades and supports cities, companies, cooperatives, and individual homeowners in their energy transition efforts.
Andreas: Hi Jef! I remember us advising on completely rewriting the platform. That was quite memorable. Can you walk us through the background of that decision?
Jef: Impact Us Today was founded in 2014, and like most startups, we’ve pivoted a lot while exploring the market. That meant introducing some historical baggage and carrying the weight of old decisions. When KBC joined as an investor, we asked madewithlove to perform technical due diligence to look at the product under the hood.
The main outcome of that audit was that we were running an old version of PHP that had reached end-of-life two or three years prior. The frameworks we used were also out of date, making a partial upgrade tough. On top of that, the original platform was written by two people who were no longer with the company, and there was little test automation. It felt like I inherited a piece of software that was hard and risky to change. A final factor was that Smooth Sailing challenged us to ask: do we need all of this? What is the core of the product? Do we need 100% of the feature set, or can we cut? Those factors made us decide to go for a full rewrite.
Droppping features
Andreas: Rebuilding something from scratch and dropping features means taking away existing functionality from users. That’s not always easy. How did you handle that?
Jef: Yes, that was a challenge. You don’t want to disappoint customers, but you can’t do everything at once, either. We serve three types of users and made the strategic decision to focus on one type while delivering a more basic first version for the others. One of these target audiences already had limited useful functionality in the original platform, and after stripping away all the product bloat, they were left with something rather barebones. That led to some frustration, but we managed to work that away post-release by focusing more on their needs.
Andreas: One of the main reasons we advise our customers against complete rewrites is opportunity cost. While your team is busy rewriting, they can’t deliver new features and improvements. You're remaining stationary for a while, allowing your competitors the opportunity to catch up. How did you handle that?
Jef: We could still evolve the existing platform, but we realized that this creates a sunk cost. Development on the legacy code base would not deliver long-term value. So, we intentionally considered the old platform end-of-life and measured the ROI for development tasks. If they didn’t deliver their value within the year, they didn’t make it to the backlog. We had to be very diligent about that. Given the outdated tech stack, we had some concerns regarding vulnerabilities, so most of our development on the legacy platform was security-related. We wanted to keep it as secure as possible while developing the new one. At a certain point, we decided to put the old platform behind a VPN, leading to even more friction for the existing users. It wasn’t a smooth experience, but we really wanted to keep the attack surface small. Ironically, this helped us convert users to the new platform where that extra friction didn’t exist.
Communication to clients
Andreas: How did you handle that migration? Did you announce the platform would shut down on a certain date? Did you pick a more gradual approach?
Jef: Yeah, that wasn’t easy either. We doubted for a long time whether we should transfer all the data or start from scratch. Given the fact that we dropped features and added new ones, it didn’t make sense to transfer everything. We didn’t want to transfer all the data from the old platform either. So, we made the tradeoff of running both products in parallel for a while. But that did pose problems for our customers. For example, contractors use our platform to manage projects, but the lead time of those projects could take months. So even now, 10 months after the release of the new platform, we are still handling projects in the old platform. This double maintenance is a drawback people need to consider when starting from scratch.
Andreas: That’s an interesting observation. People often believe that starting from scratch is quicker and easier because you can get rid of the old junk. But in reality, you’re seeing the additional workload of handling the old platform in parallel.
Jef: Yes, and ironically, we notice that the operational cost of the old platform doesn’t go down either. Even for a small number of users and projects, the hosting and maintenance costs remain the same. There is also the extra hassle of auditability overhead. Even if it were technically possible, we can’t just switch off the old platform overnight. Turns out it becomes an all-or-nothing thing. Either you get rid of the entire platform, or you keep the entire platform. Every step in the middle has development costs and overhead that aren’t worth it.
Andreas: When do you expect to sunset the legacy platform? When do you feel you can completely decommission the old one and switch to the new one?
Jef: We’re on track to finally switch off the old platform at the end of this year. So, that’s almost two years after starting the rewrite.
Andreas: That’s quite the journey. Is there anything you would do differently, knowing what you know today?
Jef: I really believe in “Release often. Release early”. Capturing early feedback is crucial when building software products. Yet, I feel like we treated this rewrite as waterfall-style project. We had partners that were interested in the new platform and would have loved to give early feedback, but we did not involve them enough. If I would do it over, I would involve early access users a lot faster.
Andreas: Some customers are creatures of habit. They are perfectly fine with the old platform and don’t really want to switch. Did you experience that as well?
Jef: Not really. We did have some customers who were reluctant to switch because they had developed custom integrations with our platform and third-party APIs. We needed to give them time to adapt those integrations and plan the switch well. That meant those customers weren’t ready to switch, and that caused some delays, of course.
Andreas: That’s another thing people underestimate. Switching everyone to a new platform on a Monday morning isn’t always feasible. There is often this transition period where you have to maintain and support two products simultaneously. How was that experience for your customers?
Jef: Yeah, that wasn’t always easy for our relationship with our customers. We had to ask them to work in two environments for a while, which is really asking a lot. Some of them don’t have a problem with that, but for others, the friction was tough to manage. We knew there were a few difficult months ahead, and we tried to communicate this as best as we could. We had elaborate spreadsheets and capacity plans to facilitate this transition.
Gradually keeping things up to date is a lot easier than doing the big moves. We’re not going to be in a position again where we are so behind that it becomes a huge endeavor to catch up again.
Jef Daniels, CEO Impact Us Today
So, how did it go?
Andreas: I can imagine those were a few rocky months. Did you encounter any positive surprises? Were there things that went more smoothly than expected?
Jef: The big advantage of a rewrite is the clarity of your path. You know exactly what you want to build. Agile software development spends a lot of time exploring possible solutions. You build, you tweak, you learn, and you refactor. But when rebuilding from scratch, you’ve already learned those lessons. The decisions have already been made, and that allows you to develop at breakneck speed. The entire product was built in a few months because we knew already where we needed to go. Now that we are back to product development, the exploration slows us down again. That’s healthy of course, but it was a real standout experience to see how fast we could develop.
Andreas: That makes sense. If you know exactly what to build, you can go really fast. You also don’t get bogged down by legacy code and old architectural decisions. That kind of pure feature building is powerful. Since you reimagined your product during this rewrite, you added some new features as well, right? How hard was it to strike the balance between rewrite and adding new functionality? I can imagine there is the temptation to add a lot of new features since you’re doing a big project anyway.
Jef: That temptation was definitely there. We had a clear vision of what we wanted to do, but as soon as the first users were onboarded on the new barebones platform, they started making feature requests.
It wasn’t always easy to push back and stick to the vision. We had to compromise here and there by adding new functionality we originally didn't want to build. I feel like we had a very well-defined, lean MVP in mind, but we ended up building around 10% of new user-driven features. Once users get active, it’s hard to ignore them and a lot of great ideas come from that early feedback. In the end, we delivered one month behind schedule and that was mainly because we added these user requests.
Andreas: One month behind schedule is pretty impressive for such a large project! We originally recommended the rewrite because the tech stack was very outdated. What do you do today to prevent this from happening again?
Jef: We now keep the room in the roadmap for operational work, and that’s something we picked up from madewithlove. Gradually keeping things up to date is a lot easier than doing the big moves, so we’re really diligent about that right now. We had a major framework update already in the last year that had quite the impact, but that was limited to a single week of work. That’s manageable. We’re not going to be in a position again where we are so behind that it becomes a huge endeavor to catch up again. We’re better organized today.