Tech stack decision making
Photo: unsplash
At the start of building my previous startup attempt, I made bleeding-edge decisions (at least bleeding-edge to me personally, since I “bled” in the process).
You probably are familiar with “tech debt” and “choose boring technology”, but this post is not about those. I am happy with the technical stack that I ended up shipping and this post is about the journey and the decision making process.
A common thread is this: I prioritised business goal over technical familiarity.
Old history
In 2011/2012 period, I tried building a startup on the side. Go language was pre-1.0, but I chose Go over the languages that I already knew at the time: Python and Ruby.
My business goal was to have a product that would not cost prohibitively to run with fast performance. Server cost back then was not as affordable as now, so Go ticked the boxes for me, although that meant I had to learn a new language. Fortunately, Go was really easy to pick up and be productive in.
Recent history
Fast forward to end of 2021 / early 2022 – a different startup attempt. I wanted to use Go again and this time my business goal was to minimise operations and this led me to 'serverless'.
There were several options for serverless + Go and Google Cloud Functions gave me a fairly balanced trade-off. Initial trial worked well, but then I found out that the networking side of thing added operational friction to get going.
At around the same time, I was experimenting with Cloudflare Workers and Pages. They worked beautifully and simple to set up. But I was not comfortable with Javascript (JS). It was possible to use another language in Workers and transpile it, but that would not work too well for me either.
Another consideration was that for the functionality that I wanted to build on the client side, the product would have better interactivity if I used a lot of JS on the browser. And to build that, I had to upgrade my rudimentary JS skill.
So if I had to use a lot of JS anyway, I might as well switched to JS and Cloudflare. And with that, I focused backend development in JS for Cloudflare Workers and frontend development in JS + React for Cloudflare Pages.
When I had built sufficient functionality for a minimum viable product (MVP), I had my doubts about the sustainability of what I had built. Was it robust enough to meet my goal of minimising operations?
Uh oh
At about the same time, the React library that I depended on switched from JS to Typescript (TS) in its new version. My web app could still work with the old version, but that got me into investigating TS.
Interesting. How hard can it be to rewrite into TS? (*)
I rewrote the code that was relevant to the aforementioned library from JS to TS in roughly a week. Given that I was learning as I stumbled along, I was happy with the one week delay.
And then I sort of “saw the light at the end of the tunnel”: migrating my app from JS to TS would minimise potential operations issue for me.
Replan
The business trade off was clear, improving the robustness of the product can pay back for itself in the long run, despite the schedule change.
So I rewrote the MVP in TS while deprioritising the rest of the product backlog. Unexpected benefit was that I was more productive coding in TS than when I was in JS.
A bit later in the project and being more comfortable with TS, I could confidently refactored the codebase into microservice-like model.
Additional tech
Data was at Supabase. Documentation was a bit lacking in a handful of places, but their product served me really well.
Cloudflare had everything else I needed but I added AWS Cloudfront as my image CDN and Imagekit to serve video. I added Cloudfront because Supabase object storage was in AWS and it was simpler to set up than Cloudflare. I used Imagekit, because it was also easier to use than Cloudflare. I wrote about Imagekit here.
That's it for the most part. Happy building!
(*) Related but completely different context: How hard can it be?