What was the initial state of the enterprise application before the rebuild?

The original enterprise product was a Ruby on Rails monolith, developed a little over a year prior. It had undergone at least four major versions, accumulating features like workspaces, workflows, LangChain agents, document previews, chat, and search, which led to technical debt and an architecture that was not designed for its current state.

Why did Collide decide to rebuild their enterprise application?

Collide decided to rebuild because the existing application, despite numerous feature additions, had accumulated significant technical debt, dead code, and unused database columns. Building new features and security improvements on the old foundation would have hindered their development speed and efficiency.

What challenges did the previous application architecture present?

The previous architecture, a Ruby on Rails monolith, suffered from accumulated technical debt, dead code, and lingering unused database columns. Its design was not flexible enough to accommodate the rapid pace of change and new features, ultimately hindering the team's ability to build new functionalities quickly and securely.

What was the primary motivation for the rapid two-week rebuild?

The primary motivation for the rapid rebuild was to establish a clean, efficient foundation for an upcoming wave of major new features and security improvements. The team recognized that continuing to build on the existing, debt-laden architecture would impede their progress and speed.

How We Rebuilt Our Entire Enterprise App in Two Weeks