Why We're Forcing Ourselves to Stop Rebuilding Our Product

As a technical founder it's my job to prioritize what to build, what to improve, and what to chuck away. A.k.a managing "the roadmap".

When you're working inside the product day-to-day, just how do you decide what needs the most attention? We're a bootstrapped team of three so our resources are pretty slim.

And while we're laser-focused on building and shipping great product, we're also perfectionists. I've learned in the last few years that this combination can be deadly.

I'm sure I can't be the only maker that sees their product and just wants to improve what's already there. It's never good enough for me and wanting to improve the existing product is part of my process.

So while making the service faster, more reliable, and easier to use might be great for our users, it's not so great for our emotional wellbeing. And not for our bottom line, either.

It's difficult for us to not try and fix things that aren't perfect, but also aren't actually broken.

But trying to fix what's not broken means we neglect our marketing. That means we're letting our customers down in some areas. When we're rebuilding, we're not building. New features aren't getting released.

I'm gonna tell you about the mistakes we've made. What's gone totally awry. Why we've gone down certain rabbit holes only to find more, but ultimately stuck with it and made it out the other end with something brilliant.

But mostly I'm gonna tell you about how we failed so you can watch out for chasing perfection yourself.

Time to change our stack?

At every startup, there comes a point where you need to think about scale and the technologies you use. Some questions come to mind:

• Is the tech stack I'm currently using gonna cut it or will it slow everything down?

• Is it better to rebuild for the future now rather than panicking and doing it wrong in a few months time?

• Is my current stack even going to be supported in a years time?

Around 6 months back we came to this crossroads.

I hacked together our initial frontend in Angular 1 (for non-technical folks, that's something that was cool 3 years ago—today not so much). I'd kept relatively up to date with security patches and updates, built out a bunch of developer tooling to make building Angular fun tolerable.

Our largest customer at the time had a few hundred articles. And Angular was flying. I couldn't understand why everyone was so hard on it—for us it was perfect.

...until it wasn't.

We started onboarding larger and larger accounts. Our frontend rendering starting slowing. Was this the start of the end for our current tech stack?

At this point, our largest account now has over 5000 articles. And Angular's not happy. Not one bit. We couldn't cope with customers this size. We accepted them prematurely. Partly through greed (they're big accounts) but mostly naivety.

We literally didn't realize how much our platform would struggle.

Optimize or die

Now, I know what you're thinking. There's ways to optimize everything. I feel 'ya. And we tried.

But at the end of the day after 3 years of my life working with Angular I didn't really want to spend any more time time hacking around its flaws. Angular was never the right tool for the job. It was just what I knew best. I decided it was time to jump ship.

Instead of making an informed tech decision I focused on speed of development. That was, in retrospect, dumb. Better to take a couple weeks learning something more appropriate for the job.

I'd heard about React, Vue, Angular 2 3 4 5, and I wanted something new and modern. Something that was heavily supported and had a great developer community.

In the end we chose React. It's a great fit for us, since we display a ton of data at a time. It's a pleasure to write, and the dev tooling's stellar.

We started the rewrite. Like any developer, I was cocky at the beginning. I thought it'd take maybe a month. Probably less. Easy.

It took 6 months.

Only maybe 2.5 of those were actually working on React. And I'll be honest—rewriting this app broke me.

I totally gave up. I stopped working on it for weeks at a time (focusing on literally any other HelpDocs task I could find instead). But eventually, 6 months down the line we've shipped it. And I have to say, it's pretty darn awesome.

We made a bunch of mistakes, but one was the worst

Right at the start I decided—against the advice of several incredibly smart peers and colleagues—to do a big bang rewrite. I'd branch off our code, write the whole app in React, then merge back in a couple weeks. How hard could it be?

Don't do this.

That's the single biggest reason this project was so soul-destroying.

Before HelpDocs I'd only ever done rewrites like this. Even at the start of our journey with this product I'd always rewritten things all at once.

It's always been fine, because the scope of the projects has been small. But now we have a fairly significant codebase things aren't so easy.

Making small changes takes a little while. Making big changes like this? Forever.

And with a big bang rewrite, we had all this React code hanging around in progress, but the only thing customers were integrating with was the old Angular.

Any bugs we fixed had to be fixed in Angular once, then again in React. Any new features had to be implemented twice.

It was hell.

Why carry on?

Now that I've waxed lyrical about how awful an experience it was, you might be wondering why we bothered at all. I mean, once I realized it was going to hell, we could'a stopped.

The problem is, we're product perfectionists. Marketing and sales we're not so great at, but product is our baby. We love building products that make customers happy. And we weren't proud of what we had.

Eventually our customers wouldn't be happy with it either. And if there's one thing I care about more than my own happiness, it's theirs.

I've used enough terrible web apps before to know I don't want HelpDocs be one of them.

We wanted to add a bunch of new things, and fighting against my former self's poor framework choice was counterproductive.

Adding new features in React will save us a ton of time. And from now on we can ship quicker than ever.

Time to stop rebuilding and start shipping

Despite all the heartache of rebuilding our admin app in React, I'd totally do it again. But the biggest lesson I learnt is to tone it down a little.

Don't go all in, especially when you're scaling at the same time. Instead, rewrite a little at a time. It may take longer, but having the flexibility to transition parts of our app when we wanted would've been a weight off of our minds.

Now we've got a solid, modern, framework to build our app on top of, it's time to get shipping. Stay tuned to see what we build next.