You've carefully planned your new business around user research, but then you throw it all away when you pick your tech stack by choosing something that isn't for users at all.

Development is the biggest opportunity for everything with a new product to go completely off the rails.

Every founder feels immense pressure to pick the right technology stack. It’s the first mission-critical decision you have to make about your business, and it’s a doozy.

Everyone seems to have a strong opinion about it too: make sure to pick a library that’s actively maintained; watch Google trends to ensure it isn’t waning in popularity; buy a nice, stable, secure server solution; pick a language that can support large scale so you don’t have to rebuild your app later; and so on.

But before you launch, none of this matters. Go reread Getting Real, I’ll wait.

Before launch, the only thing that matters is getting to launch with a product people want. The usual concerns about choosing the right tech stack really don’t help you launch sooner—they’re all about future-proofing the product before you even know if it’s viable. So the perfect tech stack can wait until later.

I propose to you a different way of choosing programming languages and frameworks for your new business: instead of worrying about the long term, think about the short term. Pick technology that lets you help your audience sooner.

Your tech stack should be an extension of your business’s goals. And at first, your goal is just to launch and get users. So pick tools based on that goal.

After all, what’s best for users: an app that’s stable enough for a million users, or an app they can use 5 months sooner? The answer is obvious.

As I enter development for Mod&Dot and I’m faced with learning new coding techniques to launch the app, I set some criteria for picking a technology stack that gets me to launch day faster. Because that’s what’s better for users.

How to choose the right tech stack for a solo founder

Even for an experienced html/css developer like myself, choosing which back end solution to pursue is daunting. I’ve encountered various tools over the years in client work: ruby, php, python, back end javascript, and many of their various frameworks and libraries.

Everyone says not to choose a language/library based on which has the most code samples or conveniences but instead to think about which will be the most stable foundation for the business. Which is actively maintained, has wide usage, etc.

But the problem is, they all are!

So how do I pick the right tools to learn, when they’re all great? I wrote down my goals and requirements, and chose tools that fit my situation best.

I’m not trying to start a new career as a developer or get a new job/clients. I’m trying to build my app as quickly as possible. So my decision for which language, framework, and tools to use comes down entirely to convenience and speed. Experienced developers might think this is short-sighted, but if my business grows, that’s a problem I can solve later. Right now, I just want to launch.

The Criteria

  1. Build a web app as quickly as possible. I care about an easy learning curve and development speed above all else.
  2. Reuse knowledge and techniques. I don’t want to have to learn multiple new frameworks or languages, and if I can build on skills I already have instead of starting from scratch, that’s a big advantage.
  3. Take care of more advanced concerns for me so I can focus on design and product quality. Managing servers, dealing with service worker queues, and learning large ecosystems of plugins and add-ons to accomplish basic tasks are all important things for other people to do. But I don’t want to mess with them. I want a tech stack that does as much of these things for me as possible, so I don’t have to learn about it or think about it.
  4. Must be cheap to host. Prior experience hosting an app on Heroku, even with practically no active users, was crazy expensive. I don’t want to burn too much cash up front since I’m funding this myself.
  5. Enjoyable to use. I’m going to be using these tools for a long time. It would be nice to enjoy that work, instead of using tools I don’t like because they look best on paper.

The Options

Ruby on Rails

I used Rails back in version 2.3.x for my first software product. It was great. I really like the Ruby syntax much better than Javascript or PHP. To see what Rails is like now, I browsed documentation, looked up gems for features I’d need, and watched some tutorials. Turns out that Rails has changed so much I would have to start over learning it, which would be totally fine.

Opinion: After some research, I feel that Rails forces me to know more advanced development concepts and be able to employ them well—MVC is especially hard. Knowing when to put things in controllers vs models was a huge rabbit hole for me last time. I never felt like I was doing it "Right", and it doesn’t seem like how Rails does MVC has changed in that regard. Also I have to plan out my database and worry about service workers. Overall Rails still feels like it’s meant for full-time-job developers, not people like me who want to only dip their toes in enough to accomplish something specific.

Hosting: Hosting Rails apps is expensive! Heroku and similar are cool, but pricey. Most hosting options definitely don’t seem like they’re meant for scrappy little businesses like mine. On launch day I’d be losing money. Or I’d have to set up my own servers which sounds like a nightmare.

Laravel

I have built many custom WordPress themes and have written more PHP than I ever thought I would because of it. I have never loved the PHP syntax, but Laravel seems to make it much nicer.

I watched "The Laravel Sell" and a few tutorials on Laracasts and read the Laravel getting started documentation. There is a lot to see in the ecosystem and community: Laracasts is amazing, and there are lots of interesting services to explore. Many written by the Laravel core team.

Hosting: Forge looks extremely cool and really appeals to this designer a lot. The ways it seems to simplify the usual hosting frustrations, deployment, etc are very on track with what I’m looking for. And, the pricing is great.

Opinion: While Laravel is seriously impressive, I ended up seeing it as similar to Rails for my purposes. I feel this would still require me to learn advanced concepts rather than handling much of that for me. Right on the homepage I see object classes, inheritance, etc. I don’t care about that stuff. I want to know how I can build out my design quickly and effectively, not how cool this flavor of syntax is. I’m probably misunderstanding a lot of it, and I am really too ignorant to criticize. But that’s the problem. I feel like experienced developers see why this is so cool and it would be a great place to start a dev career, but for me, the learning curve seems too steep.

SPA JavaScript Libraries

I read lots of articles comparing the popular frameworks: React, Angular, and Vue. I also looked at Meteor, GraphQL, Vulcan.js, and others. Overall I felt there was a lot more support and training surrounding the "big 3" and that they would be easier for me to learn.

Using JavaScript would also save me from having to learn multiple languages and/or frameworks since I’m committed to building a Chrome extension for Mod&Dot, which must be JavaScript. Learning just 1 language is a HUGE advantage, and that alone has me leaning toward JavaScript.

However, to use any of these JS libraries (frameworks? developers are always lecturing on which is a library vs a framework and I honestly don’t understand the semantics) I’d need to learn Typescript or ES6, Webpack, and Babel, which I know nothing about. That said, these would be the core syntax I’d be using, so that seems no different from learning a new Ruby or Php syntax.

Angular

The way Angular 2.0 launched with breaking changes, completely rewritten, and how it seemed to take so many of my developer friends by surprise made me hesitant to commit to it. Learning new tools is a huge investment for me and I want that investment to pay off for the long term.

That said, I read the documentation, browsed source code samples, watched tutorials, and tried to give it an honest chance.

Opinion: Surprisingly this gave me a similar impression to Rails and Laravel. It’s still an MVC framework. Angular is a broad, full-featured, and opinionated solution. The component syntax with writing HTML inside of JavaScript seems awkward and there seems to be lots of extra syntax to do simple things. Angular looks intimidating, and I feel it wouldn’t remove the major roadblocks I’ve faced in the past.

(I’m starting to think maybe I have unrealistic expectations.)

React

Framer X uses React. How cool would it be to design my app in Framer, then get a bunch of pre-written components practically for free? I want that.

I read a bunch of React documentation, browsed lots of content on React For Designers, and looked at Framer’s React code examples.

After all that, I still didn’t understand exactly how I’d use the code coming from Framer, and it seems like there is a lot to learn about how the large React ecosystem is connected. The more I dug into it, the more confused I became.

Opinion: It’s very cool how you can just drop React into a page and start tinkering. You don’t have to set up a huge application structure to get started. But I will need to build a full app, and as I learned more about that, the syntax reminds me of why I have always disliked JavaScript. It’s really messy looking. Classes extending classes. The HTML inside the JavaScript is odd. And the huge variety of plugins and options seems like it would take a lot of time and effort to figure out. How do I even begin picking a library for each use case when I’ve never done this before? Overall it’s intimidating and I still feel like there should be an easier solution.

Vue

I’ve been curious about Vue ever since a developer sprinkled a little of it into a client project, and I looked at the source code seeing how brief the JavaScript was and thought "How in the world did he do that, what is this new JS devilry?"

I read the Vue getting started guide, took the first 5-6 lessons of the free Vue 2 course on Laracasts, and checked out a list of awesome Vue resources.

Opinion: While I’d been concerned maybe there wasn’t a simpler approach available, suddenly Vue just clicked for me. I understood everything I read and watched the first time. I can build on past jQuery experience, the Vue CLI generates my project structure for me, handles Webpack and Babel, and even includes a build process and development server. The Vue single file component syntax with HTML, JS, and CSS all placed separately and cleanly within a single file is just wonderful and looks so much cleaner that other JS I’ve seen.

Vue also removes so many of the tricky issues I was worried about with other libraries because there are official Vue libraries for state management and routing. I don’t have to make a decision between a dozen options. And as I dig deeper into advanced topics, I found myself wanting to learn more rather than having to backtrack because I was confused.

Hosting JS Apps

There are a million ways to host SPA JavaScript apps since they’re entirely client-side, and that is really cool. I can easily wrap my head around that and find an affordable option. I build static sites all the time, and this is comfortable for me.

But the big question with these is how to handle the back end. I need subscription billing, authentication, and obviously some way to store data.

After reading about serverless approaches, they sound extremely compelling. I want to limit the amount of new techniques and information I have to learn, and removing most of the back end complexity sounds awesome. That way, I wouldn’t really need to learn Node.js, which until now I had assumed would be a foregone conclusion if I pursued a JS SPA library.

Firebase – lots of free code samples give me a clear idea of how I could use it. Love cloud functions and how they handle worker queues for me. The free limits are extremely generous and would likely take me a long time to outgrow. I could probably host my app nearly for free for a long, long time.

Amazon Lambda – A developer friend said this is the main alternative to Firebase. Looked at some online training for it, and as always AWS is pretty dense and hard to learn. It’s also really cheap, but I felt it would be more difficult to learn than Firebase.

Serverless – I found this just because it uses the term "server-less" which I was researching. This seemed like an enterprise-focused thing and I didn’t understand it at all. Haha.

The Choice: Vue.js + Firebase

WhIle researching all of this took a couple full days, making the decision turned out to be really easy. here’s what really made the difference when I looked at Vue and Firebase:

  • Early code samples clicked immediately.
  • Digging deeper felt rewarding, not confusing.

Overall, these seemed the easiest to learn and get results quickly, which is my main goal.

Just to be sure, I also tested to see if I liked using them in a few ways before calling the decision made:

  • Completed another 5-6 lessons of the Laracasts Vue 2 course, this time following along and writing the code as I went.
  • Tried a couple of the Firebase code examples locally on my computer
  • Read a few blog posts about ES6 and Webpack to set my expectations

Overall the experience trying these tools was wonderful and enjoyable, and I’m confident these will help me become productive quickly.

Then, I learned it all in 1 week

After making the decision, i dove in quickly and devoured some online courses:

I bought 4 courses for $103 total:

Aside: buying Udemy courses was a tough call for me. I teach my own online design courses, and I want to support independent product makers as much as possible. But the problem I found was that most of those independent dev courses were too advanced for me. For example, I decided to save Adam Wathan’s Vue course for later. I really wanted to get it if only because of how much I admire Adam’s work, but the free lessons were just way over my head.

In 1 week of full time learning, I finished all 4 courses. I felt getting two courses on each topic was worthwhile as I got a couple different perspectives and examples for each technique I needed to learn. When I didn’t understand something (I’m looking at you, Promises and async/await), I had another lesson on it to get a 2nd chance to learn and that helped a lot. Wes’s Es6 course and one of the Vue courses with a ton of example apps (and even some Firebase stuff) really hit things home for me.

Week 4 was: intense

I took in a ton of new information this week, and I’m pretty tired. But overall I am really excited at the potential these new tools and knowledge give me. Can’t wait to start using them next week.

The real test will be whether I actually can be productive after just 1 week of learning. This all probably sounds ridiculous—how could I reasonably expect that 1 week of learning is enough? I think it’s gonna work, as naive as that sounds.

Of course I’m not done learning by a long shot; much of the learning will happen as I work on the new app and find new problems and knowledge gaps. I’ll make mistakes, and fix them. That’s where the real learning happens. But I think I know what I need to begin building Mod&Dot. Let’s see if the tools I picked really are as effective at saving me time as I hope.