![](https://sdtimes.com/wp-content/uploads/2019/09/architect-1080589_640-490x325.jpg)
There’s a saying about perfectly architected systems: we’ve never heard of them, because those companies never get off the ground. When you first get going, the only thing you should focus on is finding product-market fit. Picking the stack that works right now, fast, is the right choice. Yet, once you reach critical mass, waiting too long to re-architect can torpedo your reliability and ability to grow.
So, how do you know when it’s time to pause and reinvest in your systems? What are the signs that it is time to break things apart? Knowing what this transition looks like, and accepting that every company that has velocity will eventually get here, will help you understand that retooling your system is a sign of success, not of failure
RELATED CONTENT: 3 pillars to lead your team through DevOps maturity
Two years ago at CircleCI, we fundamentally changed the guts of our product, and there’s no way for that to not be terrifying. It took six months to get this in front of the first customer, and another nine to get to GA. Because we work on and promote continuous integration and delivery, major releases scare us even more than your average software company. So swapping out the core of our entire platform was doubly dangerous: there was the inherently risky business of trying to recreate our product, except better, AND we had to work in the dark for months without the guiding light of constant validation.
So how did we know it was time to rebuild?
Our infrastructure’s efficiency was headed towards a local maximum. We could see the future of our own needs and our customers’, but we couldn’t see an incremental path towards that future. The global maximum was on a different hill and we needed to make a leap. We racked our brains, searching for a way to gradually update our platform, but we came up short. Eventually, we reached a grim conclusion: we’d have to embark on a treacherous journey — a complete re-platforming of our infrastructure.
Here’s what we learned along the way.
Before finding product-market fit, optimize for speed, not elegance. Pick a toolset and a process that helps you move as fast as possible, with the assumption that at some point you will have to rewrite everything. Don’t waste time scaling before you need to.
Many startups focus on the wrong things before finding product-market fit They waste time talking about the company they want to build. Instead, focus all of your energy on building the product that will support the company that you want to scale in the future. Once you have that, you can figure out how to build a sustainable path around that.
Fundamental architecture changes don’t happen incrementally. The inherently dangerous path we were on forced us to take a hard look at our principles: of all of the benefits of CI/CD, what could we keep? What would we have to toss out? How could we continue to make progress in other areas of the product while rewriting the core?
We could have been stubborn. But instead, we asked ourselves these questions, broke down our values and rebuilt them as we rebuilt CircleCI. We charged into this project because we knew what would be on the other side: better continuous delivery. And we believe in that philosophy so utterly that it made sense to temporarily embrace an opposing worldview. Ultimately, we had to make a giant leap so we could take small steps again, but towards a higher goal.
Customer feedback is key. And we learned from it. There were design flaws and architecture flaws and decisions that just didn’t even make any sense. But that’s exactly what we needed to know and we are so thankful to have customers who dove in and helped us figure it out.
When you are in the pure startup stage, in the very early days, you need to understand whether you are doing something customers actually want and that the market will accept and ignore everything else.
Constrain your scope. Throughout the process, we did our best to keep our focus narrow. We found appropriate seams to make important modifications while minimizing required changes elsewhere. We also exposed the new flow via branch-level configuration, so we could solicit real feedback without interrupting the day-to-day software delivery of our customers.
Give your team a clear definition of “done.” Admittedly, it was tempting to continue tinkering with the product forever, caught in a vortex of endless perfectionism. But we knew we needed to get back to our core philosophy: continuously delivering value to our customers. So we committed to this upgraded version as our default platform and have since built exciting, new things on top of it.
At the end of the day, it doesn’t matter how good the team is, or how cool the product is, or how elegant your technology is. If customers don’t want it, and the market rejects it, it doesn’t matter. Once you find product-market fit, you can start worrying about other pieces like your technology stack, organizational structure, and whether you have the right people in the right roles.
Andy Rachleff has a famous quote that talks about this: “When a great team meets a lousy market, market wins. When a lousy team meets a great market, market wins. When a great team meets a great market, something special happens.”