back to Jitbit Blog home About this blog

Thoughts on Tech Stacks for Bootstrapped Startups

by Alex Yumashev · Updated Apr 10 2019

So you're starting a bootstrapped web-based business and you're deciding on the tech stack. After running a software startup with zero funding for 13 years, here's what I have to say about this.

Warning: highly opinionated bald statements ahead.

Choosing your stack

There's a lot of (valid) reasons on why you should choose one stack (framework, programming language) over another. Like "check the ecosystem" or "think about future hires".

There's also a lot of shitty and meaningless advice like "put users before technology" or "go with opensource".

But the most crucial, the number one criteria is the ability to move fast. Period.

There once was a term - "RAD: Rapid Application Development" - which is rarely used these days (and has zero connection to our topic), but that's what you'll be doing - hopefully - for the next decade.

RAPID development.

Lightning fast changes. Quick pivoting. Redesigning your whole dashboard in one day. Locating a critical bug by simply glancing at your code. And fixing it using your mobile phone while riding the subway.

That's why the only working advice here is go with what you already know. Preferably something monolithic. Something that's been around for awhile. With minimum abstractions and minimum hype. But most importantly something you know best.

Why the "speed" obsession?

To minimize the time spent on "technical" challenges.

You will have plenty of "non-coding" stuff on your plate. Researching the market, validating your idea, interviewing potential customers, getting your first customers, then scaling the customer acquisition technique, then pivot, then pivot again, and then again?-?until you get to the product market fit...

Joel Test - the bootstrapped version

There's hardly anyone left who hasn't heard about Joel Test these days.

Here's the Joel's original list (you're supposed to answer "yes" to all of these):

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

Here's an edited list, considering you're (1) bootstrapping, (2) you're a team of 1-3 people and (3) it's freaking 2019 out there

  1. Do you use source control GitHub, GitLab or Bitbucket?
  2. Can you make a build run unit tests, make a build and deploy everything in one step?
  3. Do you make daily builds use CD/CI? It's OK if you're not, don't obsess over this one.
  4. Do you have a bug database? You probably do, see #1
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule a roadmap?
  7. Do you have a spec? (you obviously don't)
  8. Do programmers have quiet working conditions? (AKA "work remotely")
  9. Do you use the best tools money can buy?
  10. Do you have testers? Do you have both unit tests and UI-tests via Selenium, Phantom JS or a similar technology?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing? AKA do UX audits or simply show the app to your spouse

No microservices

(told you it's going to be opinionated)

Breaking down your app into smaller pieces looks so tempting. Hey, it worked for Google, Amazon and Facebook, it must work for you too! Except it won't.

The reason Google and Amazon are doing this is because when you reach a certain scale there's simply no other way to keep it all coordinated. It was a necessity, not a choice.

Do the exact opposite: avoid splitting your app into smaller objects for as long as you can. Unless you want your code to become an "un-unit-testable", "un-deployable", "un-monitorable" messy nightmare.

No JS frameworks

(unless it's what you already know best)

JS-frameworks are the new "Java Server Pages". JS-frameworks are the new "ASP.NET Web Forms". JS-frameworks are the new "BizTalk server", the new "JavaBeans".

You're probably too young to remember what are those anyway. I'm 42, so trust me. I've seen this before. Have a look at this code:

       This is message body
    <c:if test="${myVar > 2000}">
       <p>The variable is:  <c:out value="${myVar}"/><p>

Hey, you can even say the code is kinda readable! It even looks like some fancy modern framework, right?

Except it's not. It's JSP. Released back in fucking 1999.

Or this:

    <asp:DataGrid ID="Grid" runat="server" DataKeyField="EmpId" ForeColor="#333333">  
            <asp:BoundColumn HeaderText="EmpId" DataField="EmpId"> </asp:BoundColumn>  
            <asp:BoundColumn HeaderText="F_Name" DataField="F_Name"> </asp:BoundColumn>  
            <asp:BoundColumn HeaderText="L_Name" DataField="L_Name"> </asp:BoundColumn>  
        <FooterStyle BackColor="#990000" Font-Bold="True" ForeColor="White" />

This is "ASP.NET Web Forms", kids. Again, back from 2001

All these frameworks were started with good intentions, but ended up as shitty abstractions with their own "tags", their own "attributes", hidden logic and layers of "API" you had to fight your way through.

Things that were once trivial in HTML suddenly became messy workarounds. If - god forbid - you need to render anything that's not part of the framework - you're stuck, you use hacks and spaghetti-code.

That is why once the "normal" lightweight frameworks came along - like "ASP.NET MVC", "Ruby on Rails" and "Laravel" - everyone dumped the monstrous behemoths and never looked back.

The JS world is simply undergoing the same cycle right now. And we - the old farts - are finding this all very familiar.

So, yeah, no fancy JS frameworks. You can add an "invisible" frictionless JS-layer that plays nicely with your existing code (like Stimulus or even Vue). But server-side rendered HTML (with sprinkles of JavaScript) will always be - as @DHH has coined it - "a throwback to when a single programmer could make rapacious progress without getting stuck in layers of indirection" in this post.

If it's good enough for GitHub and Basecamp, it's good enough for you.

(UPD: just to be clear, by "JS frameworks" I mean libraries like Angular, Ember, React and other behemoths, not the lightweight ones, and not jQuery. And let me reiterate: if you are an expert in a JS-framework - go for it. Just don't "try it out because everyone else does")

"2.0" is always a bad idea

Now back to Joel. Rewriting your app from scratch is always a bad idea. It's one of the things you should never do. A rewrite won't magically solve any of your problems. But it will scare your existing users away.

Unless you're a funded startup of course, and you need to justify the new hires to the investors (in which case, the JS frameworks are a great idea).

Monitoring and handling bugs

Write tests after fixing bugs. If something's truly a critical and complex bug - it's something you don't want to ever see again. Write a test to prevent it.

Prioritize bugs and fix the ones that might hurt conversions first. Write a UI test that signs up for your SaaS app trial.

Track feature usage. I love killing features. If a feature is used by less than 0.5% of your users, we hide it from the UI to unclutter the app - we simply don't show the checkbox if the checkbox is "off".

Monitor exceptions and downtimes. Handling server-side exceptions and sending an email notification is generally easy. Handling client-side errors can be trickier, I'd recommend using a tool like Sentry (has a free entry plan).

Avoid the hype

As a general rule, don't chase the hype. Don't use Go, because it's the new cool thing. Don't use a NoSQL cluster because it's web scale, a relational database will work just fine. Being a cool kid is tempting (and using a cool technology can be a very important component of staying motivated), but there are other ways of keeping yourself excited (devops to name one).

As a startup your top priority is getting to market fast. Keep that in mind whenever you're making a decision and set realistic goals and milestones. Getting things done FAST is what you're looking for. Not "Facebook-scale".