Choosing, Keeping & Refactoring a Successful Startup's Tech Stack
"I say we go for a full refactoring of the app in React."
Our new dev was excited. Green and filled with confidence.
"This wouldn't be a smart decision," I replied as softly as I could (I didn't want to shut him off too harshly). After all, a part of me did share his enthusiasm. I, too, had read the React docs. I, too, would have loved to play around with it.
But another part of me—the one trying to run a successful business—knew better. Our startup's tech stack couldn't be changed on a whim. At least not anymore.
As developers, we love trying the new and discarding the old. A few months after shipping code we're proud of, we're quick to trade pride for shame. Amidst the explosion of new frameworks, we struggle not to scratch our refactoring itch.
Our industry sure celebrates the new, hip and "latest" across the board. As a business owner, however, I've had to embrace a drabber reality:
Successful startups inevitably end up with "boring" tech stacks.
That is true even for hypergrowth startups.
Eventually, I explained the ins and outs of this statement to the dev who suggested a React refactor of our web app. Today, however, I want to address this issue in a more structured format.
In this post, I'll discuss:
How to choose a technology stack for your startup's web app
Why successful businesses end up with "old" tech stacks
Why resisting the urge to refactor makes business sense
When and how you should refactor your web application
I'll use our own story at Snipcart to illustrate my thoughts, coupled with actionable insights.
Pre-startup days
Before launching Snipcart, I was leading web development in a cool Québec City web shop. I did mostly client work. The fun part? Trying out new technologies in real life projects. My bosses trusted their engineers, so each project launch meant the opportunity to try fresh stacks. I mostly orbited around the .NET stack, building my first project with ASP.NET MVC (in beta), and another using Nancy, an awesome open source web framework in .NET.
A couple years flew by. As my hairline began receding, I knew I needed a change from client work. I wanted to focus on a product. Fellow entrepreneurs inspired me. I knew my experimentation scope would narrow, but I was ready for new challenges. Truly scaling a project, for instance. It may sound buzzwordy, but back then I hadn't had the chance to design a system capable of handling hundreds thousands of simultaneous requests. I decided Snipcart would be that system and began exploring my tech stack options.
Choosing your startup's tech stack
Say you've gone through your genius "aha" moment, lean canvas & piles of wire-framing. Like every other fledgling startup, you reach the crucial crossroads that is picking your tech stack.
Before giving in to the array of shiny logos, blog posts and GitHub stars trying to lure you into The Coolness, take heed of the following advice:
1. Pick a technology you're comfortable with
This one's simple, really: do not mess around with stuff you don't already know. Point blank. Keep the glossy new JS frameworks for your 14th personal site/side project, unless you're just shooting for a proof of concept. If you want to build something serious, go for familiarity. Doesn't matter if it's old, boring, uncool, etc. There's no one best technology stack for web applications.
In 2013, when I started working on Snipcart, I chose .NET for the backend. Why? Because I enjoyed working in C# and it was the stack I was the most efficient with. I knew It'd allow me to craft something solid.
As for the frontend, we picked Backbone. SPAs were relatively new to me, and a colleague had already shipped decent projects with it. Back then (jeez I sound old), options were way more limited. Knockout, Angular, Ember & Backbone were the big players. I had no particularly fond memories of my time with Angular, so I cast it aside.
Backbone, on the other hand, was more of a pattern than a framework to me. Sure, you had boilerplate to put together, but after that, it was easy to build on top of it.
2. Pick tech stacks supported by strong communities
If you're the only developer kicking off the project, this is critical advice. A day will come when you're alone in the dark, staring in utter despair at one senseless error code. When that day comes, you don't want to be roaming through ghost forums and silent chat rooms, believe me.
The cool, beta three-month-old framework might not have a rich help structure around it. That's another plus for picking "boring" techs: LOTS of girls and guys have struggled and shipped with them over the years. Like it or not, but documentation and help abound in the ASP.NET realm. ;)
3. Make sure your web app stack scales
The most important scaling choice to make isn't just about how many potential requests you'll handle. By picking a stack you understand, you'll be able to design an application that's easy to build upon. Keep in mind that you won't always be the only one navigating through the codebase. If you're successful, new, different people will be working in the code.
So remember:
A good tech stack is one that scales faster than the people required to maintain it. [source]
In the beginning, I didn't really bother with scaling issues. I was too excited to just ship my own product. So I developed Snipcart the way I would've coded client projects (mistake): a single database & a web app containing everything. Truth is I never expected it to grow as it did. It didn't occur to me that our database could be the single point of failure in our project. I had never encountered such wonderful problems in client projects. So yes, I wish I had thought about scaling earlier! However, refactoring our architecture wasn't too painful since: we had picked technologies we were comfortable with. :)
4. Consider hiring pros & cons
This one's kind of a double-edged sword.
On the one hand, picking a more "traditional" stack will grant you access to a wider basin of qualified developers. On the other, picking cutting edge technologies might attract new, killer talent.
Needless to say, I tend to lean towards the former! In startup mode, you can't afford to hire an employee who needs months of ramping up to use a fringe framework. If you plan on quickly scaling the team, this is a key consideration. With Snipcart for instance, most developers fresh out of school had already worked with .NET. This definitely helped for our first hire.
However, I'll admit that having a "boring" stack can work against you (gets less and less boring with tools like VS Code, though!).
For our second hire, .NET put us at a disadvantage: we had found the perfect candidate, who, in the end, decided that our MS stack was a no-go for him. At this point, my tech stack choice cost us a potentially great addition to the team.
Like I said, double-edged sword.
(Luckily for us, we found a new developer not long ago with solid .NET experience, and he enjoys working with us thus far!)
Success & sticking to your tech stack
Still runnin' smoothly? Do not ditch.
Let's fast forward on all the hard work it actually takes to make it and pretend you just did. You blazed through product/market fit, breakeven point, and started generating profits. Your Stripe dashboard finally looks appealing.
You're "successful" now. And that probably means:
You've been working your ass off for a while—there's no such thing as overnight success.
You've been constantly shipping code with the tools you initially chose—and some aren't cool anymore.
You've got real, paying users using your platform—read: SUPPORT & MAINTENANCE.
See, when you scale, new constraints emerge. Support slows development velocity. Revenue growth means new hires (more training & management) + new expenditures (salaries, marketing, hosting). Profitability becomes an operational challenge.
You're accountable to clients, employees and sometimes investors who all depend on your sustained success. As business imperatives trump technical concerns, your priority becomes crystal clear: keeping the company in business. And guess what? Spending hours of time on refactoring your frontend with the latest framework probably won't help you do that.
The real cost of refactoring is time not spent fixing bugs, shipping features, helping customers, and nurturing leads. These are the things that'll keep you in business.
So the real challenge becomes learning to deal with the technical decisions you've made to get here. Most times, the simple answer is to stick to your stack and focus on the business. Yes, your web application's code may look "old." But you're not alone: big, successful products still run old technologies!
Take us for instance: we're still using tech that we could label "old." Backbone is still the "backbone" of our frontend application. No, it's not the coolest JS framework available. However, it works just fine, and a full rewrite would put an insanely costly pressure on operations.
Don't get me wrong: I'm not suggesting you avoid refactoring at all cost. Products must evolve, but should do so inside the tight frame of business imperatives. Which brings us to our next point.
When does refactoring your web app make sense?
Refactoring is part of a healthy dev process and sure brings important benefits: sexier stacks for hiring, better code maintainability, increased app performance for users, etc.
As long as refactoring doesn't negatively impact the business, I'm all for it. Like I said, products must also evolve. Just recently, for instance, we began shifting our frontend development to a more powerful framework (Vue.js).
What we're doing, though, is progressive refactoring. Tools like Vue are perfect for that: they let you introduce a new tech in your stack without forcing you to throw away existing code. This incremental approach to refactoring has proven successful for us thus far—we did something similar a few years ago when we moved from RequireJS to Webpack. Progressive refactoring is, overall, more costly in development time than a full re-write. However, it doesn't stall business operations, which must remain a priority.
When NOT refactoring ends up negatively affecting the business, then you should start considering it more seriously. A few important "time to refactor" flags to lookout for:
Parts of the code become impossibly messy or hard to maintain
Technical debt begins manifesting itself through increased support requests & churn rate
Deployment, testing & bug fixing are taking longer than they should
New developers' time-to-autonomy (shipping in production) escalates
Finding qualified developers to work on your app becomes arduous
Maintaining the architecture becomes ridiculously expensive
Note how "let's try a new stack!" and "that code isn't clean enough!" aren't listed here. Or, as Dan McKinley puts it:
One of the most worthwhile exercises I recommend here is to consider how you would solve your immediate problem without adding anything new. First, posing this question should detect the situation where the "problem" is that someone really wants to use the technology. If that is the case, you should immediately abort.
Technology for its own sake is snake oil.
This killer StackExchange answer lists even more refactoring flags you should be sensitive to.
BONUS: Where to use all these new technologies
A desire to play with shiny new toys is only natural. It comes with the active curiosity residing in any good developer. At Snipcart, every dev does lots of self-learning. Like many others, we read blogs and try to keep up with latest trends. Of course, we can't use most of these up-and-coming tools in our core project. However, we run a developer-centric blog that covers all sorts of dev topics and tools. For us, this is a perfect playing field for experimentations. It allows us to quench our thirst for novelty, offers value to our community, all without compromising our "money" product!
For startuppers, there are a few other areas where using hip tech makes sense:
Marketing side-projects
Internal tools (analytics, comms, management, etc.)
Marketing website / blog
These are all potent areas where you can experiment and learn new skills and stacks. And they will all benefit your core business. So find the one that works for you!
Takeaways & closing thoughts
Ouff, long post, heh? Before going back to my startup life, I'd like to leave you with the key takeaways here:
Technical decision-making isn't just about technologies—it's mostly about the business.
When picking a tech stack, consider: familiarity, community, hiring, scalability.
Try as much as possible to adopt a progressive approach to refactoring your stack.
Keep an eye out for relevant refactoring flags: development deceleration, talent scarcity, customer frustration.
And finally: remember that the best technology stack for startups is your own grey matter. At the end of the day, architecture decisions & craftsmanship will eclipse tech choices.
→ Explore startups & SaaS technology stacks examples on StackShare.io.
→ Learn how to choose a stack for client work.
If you've enjoyed this post, please, take a second to share it on Twitter. It'd mean a lot to us! Questions, insights, insults? Comments are all yours.
