# The Non-Technical Founder's Tech Stack Cheat Sheet
A client asked me last year to explain what "full-stack JavaScript" meant. I spent 10 minutes explaining. She then asked why she should care. I didn't have a good answer.
The truth is most non-technical founders don't need to understand tech stacks in detail. But you do need enough context to evaluate whether your developer's choices make sense for your product, and to understand the hiring implications of each choice.
This is that cheat sheet. Plain English. No depth beyond what you actually need.
The Basics: What a Tech Stack Actually Is
Your product has several layers that all need to be built. The "tech stack" is the collection of tools and programming languages used to build each layer. The main layers are:
Frontend: what users see and interact with (the visual interface in their browser or phone)
Backend: the server-side logic (processes data, enforces business rules, manages security)
Database: where your data is stored
Infrastructure: the cloud services that run everything
Every product has all of these layers. The choices made in each layer affect your hiring costs, your development speed, and how easy it is to change things later.
Frontend: What's Rendering Your Interface
Web Frontends
React is the most popular choice for web frontends by a large margin. Large talent pool, extensive ecosystem, well-suited for complex interactive interfaces. If you're not sure what to pick for a web frontend and your developer has React experience, React is usually the right answer.
When to use it: almost any web application that has complex user interactions, dynamic data, or needs to feel like an app rather than a website.
Vue.js is React's main alternative. Slightly easier to learn, similar capabilities. The talent pool is smaller than React but still substantial. Some developers prefer it because the code is more readable. Good choice if your developer has Vue expertise.
When to use it: same situations as React. Choose based on your developer's experience, not ideology.
Next.js is built on top of React and adds features that are important for content-heavy sites: server-side rendering (pages load faster for users and rank better on Google), built-in routing, and easier deployment. If your product needs strong SEO - a blog, a marketing site, a content platform - Next.js is usually better than plain React.
When to use it: marketing sites, content platforms, SEO-dependent products, e-commerce where Google ranking matters.
Plain HTML/CSS/JavaScript (no framework) is the right choice for simple, mostly-static sites that don't have complex interactivity. If your site is primarily content with a contact form, there's no reason to add framework complexity.
When to use it: landing pages, simple marketing sites, documentation.
Mobile Frontends
Flutter (by Google) lets you build one codebase that runs on both iOS and Android. Good performance, growing ecosystem, faster to develop than maintaining two separate native apps. The main limitation: some complex native phone features are harder to implement.
When to use it: most consumer apps, B2B apps, anything where cross-platform is important and you don't have extremely complex native hardware requirements.
React Native (by Meta) also lets you build one codebase for iOS and Android. More mature than Flutter, larger talent pool, easier if your team already knows React. Performance is slightly behind Flutter for complex animations but fine for most apps.
When to use it: same situations as Flutter. Choose based on team expertise.
Native (Swift for iOS, Kotlin for Android) means building two separate apps. 2x the development cost, but maximum performance and access to every platform feature. Rarely the right first choice for startups.
When to use it: apps with complex graphics, games, apps that deeply integrate with phone hardware (camera, sensors), or when you've already launched cross-platform and performance is a documented problem.
Backend: Where the Logic Lives
Languages and Frameworks
Python/Django or Python/FastAPI is my most common recommendation for startup backends. Large talent pool, fast development speed, excellent ecosystem for data and machine learning, readable code. Django is "batteries included" - it comes with authentication, admin interface, database tools built in. FastAPI is better for building APIs that need to be fast.
When to use it: most startup backends, especially if your product involves data processing, machine learning, or complex business logic.
Node.js (JavaScript on the server) makes sense when your team already uses JavaScript for the frontend. Sharing a language between frontend and backend reduces the number of context switches developers have to make. Good for real-time features (chat, live updates).
When to use it: real-time products, teams with strong JavaScript expertise, products where frontend and backend share a lot of data structures.
Ruby on Rails was the dominant startup framework for a decade and built Twitter, GitHub, and Shopify in their early stages. Still excellent for moving fast on standard web applications. The talent pool has shrunk but the remaining Rails developers are often very senior.
When to use it: standard web applications where speed-to-market is critical and you can find Rails expertise.
Go is a language designed for performance and simplicity. Lower development speed than Python or Rails but much better performance at scale. Good choice if you know you'll need to handle very high traffic.
When to use it: infrastructure tools, high-performance APIs, when you've already validated your product and need to scale.
Database: Where Your Data Lives
The Main Decision: SQL vs NoSQL
SQL databases (PostgreSQL, MySQL) store data in structured tables with defined relationships. They've been around for 50 years and are excellent for most startup use cases. PostgreSQL is my default recommendation.
When to use it: any product with relational data (users, orders, products, etc.), financial applications, anything where data integrity is critical.
NoSQL databases (MongoDB, DynamoDB) store data as flexible documents without rigid structure. Useful when your data doesn't fit well into tables or changes shape frequently.
When to use it: products with highly variable data structures, content platforms, applications that need extreme read/write performance at scale. Most startups don't need NoSQL and should start with PostgreSQL.
Redis is a fast, in-memory database used as a cache (storing frequently-accessed data for faster retrieval) and for real-time features (pub/sub messaging). Almost every production application eventually adds Redis. Budget for it.
Infrastructure: Where It All Runs
AWS (Amazon Web Services) is the market leader. Largest ecosystem, most tutorials, most developers know it. More complex to configure but can handle anything.
Google Cloud Platform is strong for products using machine learning (Google's AI services are best-in-class) and products that need to scale globally.
Heroku (now owned by Salesforce) and Railway are deployment platforms that abstract away infrastructure complexity. Much easier to start with, slightly higher cost at scale, good for early-stage products where developer time is more valuable than infrastructure optimization.
When to use Heroku/Railway: early-stage products, founders who don't have a DevOps specialist. Move to AWS/GCP when you have product-market fit and the infrastructure costs start to matter.
The Only Advice That Matters
Pick the stack your developer knows well. A great developer with an unfamiliar stack will be slower and produce worse results than a good developer with a familiar stack.
The best stack is not the most fashionable one or the one that the biggest companies use. It's the one your team can build and maintain effectively for your specific product.
When I start with a new client, I always ask: what have you shipped with this stack before? The answer matters far more than the stack itself.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr