There's never been a better time to build software. If you're a founder, a solo dev, or just someone who wants to turn ideas into products quickly, the tooling has finally caught up with the way most of us think: fast, iterative, and visual.
At work and on my personal projects I actively utilize Claude Code, and previously Cursor, to build real software. At work, I built production Java Spring and Golang applications deployed on AWS, while for my personal projects I use a dramatically different stack.
How to Decide on a Tech Stack?
My general philosophy on tech stacks has always been to choose the stack that gives you the easiest way to accomplish your goals. This meant that if I wanted to build an application that interfaced with the Ethereum network I'd pick Golang because it had the best library support. When building interactive websites, I go straight for Next.js for the ease of building full stack react applications with everything built in (like server side rendering). If I wanted to build an application that did intense data processing, I'd pick up Python because of the deep toolset like numpy or pandas.
In the vibe coding era, my philosophy hasn't necessarily changed, but my stacks have seemed to condense into three common cases depending on what I'm building:
Building a Webapp with a Simple Backend
For simple webapps like CRUD applications, SaaS MVPs, or even the site you're currently reading, I reach for Next.js and Supabase every time. This combination lets you build highly interactive applications without wrestling with infrastructure complexity or deployment headaches. Supabase gives you a hosted Postgres database with built-in authentication, real-time subscriptions, and auto-generated APIs, essentially a complete backend-as-a-service. There's some complexity in setting up row-level security to control who can access your data, but once you get the hang of it, it's an efficient way to develop apps!
Building a Webapp with a Complex Backend or an API Product
- Frontend: Next.js
- Backend: FastAPI (Python)
- Database: Postgres
- Hosting: Vercel for Frontend, Render for Backend
At my day job, I write exclusively Golang-based API services. Golang is fast, has compile-time safety, and has solid library support for crypto applications. When I've been developing complex backends for my personal applications I've really been leaning into the Python ecosystem.
FastAPI is my backend of choice, it's a high-performance backend framework that lets you rapidly prototype your backend services. Combined with a standard Postgres database for direct connection and less complex security needs, it proves to be a great stack to iterate on quickly.
Python Ecosystem
The Python ecosystem has evolved a lot since I last used it in 2017. You can now do typing in Python, FastAPI provides blazing fast speeds compared to traditional Flask applications and comes with automatic generation of Redoc/OpenAPI specs as well, and there is a new generation of fast efficient linters and alternatives to pip for dependencies.
I've recently been following a new company called Astral which is developing many of these Python developer utilities (funnily enough in Rust):
- Ruff gives you an extremely fast linter and formatter. I use this before every commit to improve code quality.
- uv is a pip / virtualenv alternative that lets you manage your python ecosystem with ease.
Case Study: ChillATC
One example of something I've used this stack for is ChillATC, which combines Lofi music from Spotify with LiveATC feeds.
- I built this app when a site I was already enjoying, LofiATC, got blocked by LiveATC. I did some investigation and noticed that they were getting a simple CORS blocking from LiveATC's feeds when looking at the network tab.
- Using FastAPI as the backend I built a simple backend app to listen to the audio streams from LiveATC and propagate them to my app so CORS could never be an issue. It also proved extremely reliable because I could build in complex retries and utilize multiple server addresses as needed.
Building a Mobile App
Recently I've been experimenting with building a mobile app to allow general aviation pilots to get AI-enhanced weather briefings. Most pilots predominantly use iPads for their flight briefings today through applications like ForeFlight or Garmin Pilot so I thought it was best to keep the form factor the same.
It's been quite a while since I explored iOS apps. I remember experimenting with Objective-C more than a decade ago. The development environment (XCode) was clunky, the iteration loop felt slow, and I never ended up building much there. A few years ago I took another crack at it with the Ionic framework which allowed using more familiar web standards; this still felt clunky though.
I'm glad to see how much the ecosystem has evolved with the use of React Native combined with Expo. Expo is a full toolkit for writing iOS and Android applications in a way that makes it feel like you're building web-based applications. You can utilize Expo Go, an application on iOS that hot reloads your application on your actual device while you develop it. When you pair this hot-reload capability with Claude Code to quickly generate UIs and API integrations, the developer experience becomes incredibly smooth, far exceeding my expectations for mobile development. Beyond that, Expo runs build pipelines and can submit your apps directly to the app store for you so you never have to use XCode if you don't want to.
Combining this with my standard FastAPI backend has made a killer combo for building full mobile apps.
Your Turn to Build
You now have three proven stacks that can take you from idea to production. No more analysis paralysis. No more endless configuration. Just pick the stack that matches your project:
- Web app? Next.js + Supabase + Vercel
- Complex backend? FastAPI + Postgres + Render
- Mobile app? Expo + FastAPI + Postgres
The barrier to building real software has never been lower. With these tools and AI assistance, you can compete with teams 10x your size. The only question left is: what will you build first?
And my one final tip: don't start with AWS, if you need it one day you'll be able to migrate (for example) but it's not the place to start!