How to OVER Engineer a Website // What is a Tech Stack?
Based on Fireship's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
A tech stack is best treated as three layers—front end, back end, and APIs/third-party services—rather than a single acronym.
Briefing
Choosing a tech stack early can make or break a startup build, because swapping it later is painful. A “tech stack” isn’t one thing—it’s a layered set of tools that together handle the user interface (front end), the server-side logic and data storage (back end), and the connections between them (APIs and third-party services). The core takeaway is that stack decisions should match real product needs, not acronym-chasing or “use everything” engineering.
The transcript starts with the classic LAMP stack—Linux, Apache, MySQL, and PHP—popularized in the late 1990s. In that era, building web apps often meant expensive commercial software, while LAMP offered a free, open-source alternative that later influenced frameworks like WordPress and Joomla. Today’s web development is easier in some ways, but modern stacks are far more complex because many vendors sell specialized “shovels” to startups.
To make the idea concrete, the transcript defines three layers. The front end includes tools for the user interface, typically a JavaScript framework for web (or iOS/Android/cross-platform tools like Flutter for mobile). The back end includes a server runtime (like Node.js or Python), a database for user-generated data, and often cloud infrastructure that can create vendor lock-in. The middle layer is APIs: communication mechanisms like REST or GraphQL plus essential third-party services such as Stripe (payments), Twilio (text messaging), and SendGrid (email). These services blur boundaries because they act like both backend and frontend dependencies.
Common stacks like MEAN (MongoDB, Express, Angular, Node) and variations such as MERN or “M”/“Mevan” are introduced largely as examples of how catchy acronyms drive adoption—even when the acronym doesn’t fully represent what a real project needs. A site like StackShare is suggested as a way to see what successful companies actually use.
Then comes the main exercise: over-engineer a hypothetical Myspace-like app. The front end starts with TypeScript on top of JavaScript, React for UI, Redux for state management, and Tailwind for styling (plus Sass and PostCSS for preprocessing and production cleanup). Webpack is added as the module bundler. The backend begins with MySQL for relational data, then adds Redis as an in-memory cache for speed. Node.js runs server code, Nest provides a TypeScript-friendly server framework, and TypeORM handles database access without raw SQL. An HTTP server like Nginx or Apache is included, then Docker standardizes the environment, Kubernetes orchestrates containers, and Amazon Web Services hosts the infrastructure. Terraform manages AWS provisioning, GitHub stores code, and GitHub Actions automates testing and redeployment.
For API and “don’t build it yourself” needs, GraphQL and Apollo are added, along with Stripe for payments, Auth0 for authentication, Amazon Rekognition for image moderation, and Twilio for messaging. The transcript’s punchline is that this stack is likely far more complex than necessary because end users only care about outcomes—performance, reliability, and usability—while infrastructure complexity becomes justified only after early product success.
The simplified “realistic” stack flips the approach: start with minimal tooling (even plain HTML), then add only what’s required. For a lightweight web app, it proposes Petite Vue instead of a heavy framework, Bootstrap instead of Tailwind, and Ionic for mobile packaging. For the backend, it recommends Firebase to handle a scalable document database and authentication, with optional Firebase Cloud Functions for server-side code. It also suggests skipping GraphQL unless the app truly needs complex multi-API composition, resulting in a “Petite Fire” stack aimed at speed and simplicity over maximum engineering overhead.
Cornell Notes
A tech stack is best understood as three layers: front end (UI tools), back end (server runtime, database, and often cloud infrastructure), and APIs (communication plus third-party services like Stripe, Twilio, and SendGrid). The transcript warns that stack changes later are costly, so early choices matter—but it also criticizes acronym-driven and over-engineered builds. A “maximal” Myspace-like example adds TypeScript, React, Redux, Tailwind, Webpack, MySQL, Redis, Node.js with Nest, TypeORM, Nginx/Apache, Docker, Kubernetes, AWS with Terraform, GitHub Actions, GraphQL/Apollo, and multiple third-party services. It then pivots to a leaner approach: start simple, add only what’s needed, and use Firebase (plus Cloud Functions) to avoid much of the infrastructure burden. The practical lesson is to optimize for product delivery first, complexity later.
What does “tech stack” mean in practical terms, beyond a catchy acronym?
Why do acronym stacks like LAMP or MEAN attract attention, and what’s the downside?
In the over-engineered Myspace-like build, what roles do the database and caching layers play?
How does the transcript justify adding infrastructure tools like Docker, Kubernetes, and Terraform?
What is the simplified alternative stack, and what complexity does it intentionally avoid?
Review Questions
- When does adding Kubernetes and CI/CD automation become justified in this framework of thinking?
- Compare the strengths of MySQL vs MongoDB/Firestore as described, and explain why caching with Redis is introduced.
- What criteria would make GraphQL worth keeping rather than removing in a simplified stack?
Key Points
- 1
A tech stack is best treated as three layers—front end, back end, and APIs/third-party services—rather than a single acronym.
- 2
Changing a stack later is costly, so early decisions should be driven by product needs, not popularity or memorability.
- 3
Over-engineering a full production setup (Docker, Kubernetes, AWS, Terraform, CI/CD) can be premature before the app proves demand.
- 4
Relational databases like MySQL fit relationship-heavy data, while Redis caching targets performance by storing frequently used data in memory.
- 5
Third-party APIs (payments, messaging, authentication, moderation) often belong in the stack because they replace complex capabilities that teams would otherwise build from scratch.
- 6
A lean approach—start simple, add only what’s required—can use Firebase and Cloud Functions to avoid managing servers and infrastructure early on.
- 7
GraphQL should be kept for complex composition needs; it can be removed for simpler apps to reduce complexity.