How Our Latest Acquisition Is Rebuilt From Scratch

In Summer this year, we made our second acquisition. You can read more about it at The Second Acquisition: Notehouse.

However, during the due diligence process, it became increasingly clear that the product’s foundation needed to be rebuilt from scratch. The application had been passed between several external engineering partners over the years, which typically results in technical debt building up to an unmanageable level.

We typically don’t do full rebuilds of our acquisitions, but in this case, we reached an agreement with the seller to account for this additional expense and ultimately decided to move ahead with the deal.

Now, a few weeks into the rebuilding process, I wanted to share some updates on our progress, the approach we’ve taken and what’s next for Notehouse.

Migrating a business

As with our first acquisition, Pxl, we opted for an asset deal this time as well.

Unlike a share deal, where a majority stake in a company is acquired, an asset deal involves transferring assets and all associated IP from one company to another. This approach simplifies many aspects — it’s typically faster, cheaper and involves minimal legal fees. (However, the larger the acquisition, the more likely a share deal becomes)

However, there is one clear downside of asset deals for SaaS businesses: the vendor’s identity changes for existing customers. This has downstream effects most notably on the payment provider — which is often Stripe.

We had already migrated Stripe for Pxl, so we had a solid understanding of how the process would need to work for Notehouse. Still, no two migrations are the same. We encountered a few minor challenges but ultimately completed everything smoothly after one or two late-night sessions.

In addition to migrating the company’s intangible assets, we also acquired a small team based in the US and Colombia who continue to support us with operations, customer support and IT maintenance of the current product.

Rewriting a software product

Rebuilding an application already daily used by hundreds of businesses and users is no easy task.

Beyond changes in software architecture and the overall stack, the most critical component is user experience. From working with the Notehouse team, we know the existing customer base is not particularly tech-savvy, so we must take extra care to avoid confusing them when launching the new application.

The general rules we follow:

• Keep the new design as close to it's original design as possible
• Maintain familiar workflows and navigation patterns
• Don't move buttons!! (this has become kind of a running gag already)

If I were to sum it up, I’d advise not getting too creative when doing a rebuild.

Beyond these UX challenges, we chose a modern stack based on TypeScript and React — not only because the old stack was outdated, but also because we integrated coding agents at the very core of the rebuilding process and these agents perform best with modern frameworks.

Coding agents

As a first step of the rebuild, we assessed the existing codebase and mapped out its features. We used Claude Code for this, and it worked really well.

Next, we mapped out all features as tickets in Notion and reviewed each one with the Notehouse team. The goal for every feature was to decide whether to keep it as is, remove it or improve it right away.

For developing the new codebase, we use Claude Code together with GitHub Issues as our preferred setup, connected through MCP and led by an experienced senior software engineer.

We haven’t yet implemented full auto-coding – where an issue is sent directly to Claude Code via GitHub and it generates a pull request – but that’s likely the next logical step for us to explore.

Realistically, without today’s coding agents dramatically improving development speed, we wouldn’t have moved forward with this deal.

The $200/month Claude Max subscription paid off right away — it’s basically a no-brainer for us, especially considering the time saved, the simpler tasks it handles with solid quality and the reduced need for back-and-forth between developers.

The new landing pages

We’re not only rebuilding the application but also redesigning the landing pages. From a UX perspective, this is where we can be more creative and focus on conversion optimization, which hadn’t been a major priority before.

It’s not just me, the entire Notehouse team was excited to see the visual changes take shape. Overall I think the new design makes the product feel more refined and mature.

Going live in Q1 2026

At the time of writing this update, the whole team is fully focused on development.
Our goal is to launch an internal test version by the end of 2025, followed by a public rollout in early Q1 2026.

Will these be my famous last words? I’ll keep you posted on the progress.