Level Up

Cheatcodes for Building

Lay of the land

Every application that works in production — from a dashboard to a trading system to an internal tool — sits on the same set of layers. Miss one and it either doesn't run, doesn't persist, or nobody can reach it

This is the lay of the land. Each row below is a chapter. Once you understand these layers, you can build and ship anything — the Stack page shows what reusable modules look like on top of this foundation

Packages like requests, flask, supabase, python-pptx, and jinja2 are all tools that sit in these layers. Learning to compose them is how you go from scripts to applications

Version Control

The save system for code. Every change tracked, every mistake reversible

Git — Local Version Control

• Commits — save points. Every commit is a checkpoint you can load back to. Broke something? git revert. Want to try a risky approach? Branch, experiment, merge if it works
• Branches — parallel universes. main is your stable build. Feature branches let you experiment without corrupting your save file
• Diffs — every change is tracked line-by-line. You can see exactly what changed, when, and why. git diff shows you the delta, git log shows the history

GitHub — Collaboration + Automation

• Remote repository — your code lives in the cloud. Push your commits, pull others' changes. Everyone works from the same source of truth
• Pull requests — propose changes, get review, merge. The entire open source ecosystem runs on this loop: fork → branch → commit → PR → review → merge
• GitHub Actions — automates testing and deployment. Push to main, it runs your tests and deploys. No manual steps. This is CI/CD (continuous integration / continuous deployment)

If you've ever saved before a boss fight, died, and loaded back in — you already understand version control

Database

Anything that needs to survive a restart needs a database

When to Use What

Key Concepts

• Decide early: what's ephemeral (cache, session) vs. what's permanent (users, content, transactions). AI-generated apps skip this and break later
• Start with hosted Postgres (Supabase, Neon, Railway). You get a REST API, a dashboard, and row-level security without managing a server
• Migrations — schema changes over time. Your database evolves as your app evolves. Tools like Alembic (Python) or Supabase's built-in migration system track these changes like version control for your data model

Data Feeds as a Layer

Beyond storage, you often need to pull data from external sources — APIs, market feeds, web scraping results. The pattern is the same: define an adapter that normalizes external data into a consistent format your app expects. Think of it as a data access layer — one interface, many backends

Whether you're pulling stock prices, weather data, or CRM contacts — wrap external APIs in a consistent adapter. Your app code never changes when you swap the data source

Search & Indexing

How applications find things in large datasets

Every application eventually needs search. It starts simple — finding an exact string in a file — and scales up to understanding what a user means. Each approach below adds a layer of sophistication, and knowing when to reach for which one is a system design essential

Regex (Pattern Matching)

The most basic form of search: Ctrl+F, but in code. Regular expressions (regex) let you define a pattern instead of a fixed string, so you can match things like “any email address” or “a date in YYYY-MM-DD format” without listing every possible value

• Built into every language. Python’s re module, JavaScript’s /pattern/ literals, grep in the terminal. Zero dependencies, zero infrastructure
• Great for structured patterns — phone numbers, URLs, log lines, CSV parsing. Anywhere the thing you’re looking for has a predictable shape
• Not search in the product sense. Regex scans text sequentially — it doesn’t rank results, handle typos, or scale to millions of documents. When you need those things, you reach for the approaches below

Bag of Words (Keyword Search)

The simplest approach: count which words appear in a document and match them against the query. If someone searches “python flask deploy”, find documents containing those exact words

• TF-IDF (Term Frequency – Inverse Document Frequency) — weighs words by how often they appear in a document vs. how common they are across all documents. “Deploy” in a cooking blog is more meaningful than “deploy” in a DevOps wiki
• Fast and predictable. Postgres has built-in full-text search. No ML models, no embeddings, no GPU. Works well when users know what words they’re looking for
• Breaks on synonyms. Searching “deploy” won’t find documents about “shipping to production”. It matches tokens, not meaning

Vector Search (Semantic / Cosine Similarity)

Instead of matching words, convert text into a vector (a list of numbers that represents its meaning) and find documents whose vectors point in a similar direction. This is cosine similarity — measuring the angle between two vectors in high-dimensional space

• Embeddings — a model (like OpenAI’s text-embedding-3-small) converts text into a vector of 1,536 numbers. Texts with similar meaning have similar vectors, even if they use completely different words
• Cosine similarity — measures how aligned two vectors are. 1.0 = identical meaning, 0 = unrelated. It ignores magnitude and only cares about direction, which is why longer documents don’t automatically score higher
• Vector databases — Pinecone, Weaviate, pgvector (Postgres extension), Chroma. They store embeddings and run nearest-neighbor search efficiently using indexes like HNSW

When to Use What

This is the foundation behind RAG (Retrieval-Augmented Generation) — the pattern where you search your own data, pull the most relevant chunks, and feed them to an LLM as context. Every AI-powered search, chatbot, or knowledge base uses some version of this

Hosting & Environments

Getting code off your laptop and onto the internet

Environments

Before you deploy, you need isolated environments. Every project gets its own set of packages — break one project's dependencies and the rest don't care

Default to venv. Tools like uv make it blazing fast. Reach for conda when you need CUDA drivers or compiled scientific libraries. Never install packages globally

Deploying

Frontend vs. Backend

• Frontend — static sites and SPAs go to Vercel or Netlify. Free tier, instant deploys, CDN-backed. Don't overthink this
• Backend — APIs and services need a server. Options range from managed platforms (Railway, Render) to self-hosted PaaS (Dokku on a $12/month droplet). CI/CD via GitHub Actions — push to main, it deploys. No manual steps

Containers

A Dockerfile packages your app with all its dependencies into a reproducible image. "Works on my machine" stops being a problem because the container is the machine. Every modern hosting platform runs containers

Domains & Routing

How the internet finds your app

• Domain — a human-readable address (yourapp.com). You buy one from a registrar (Cloudflare, Squarespace, Namecheap). ~$10/year
• DNS — the phonebook that translates your domain to your server's IP address. An A record points a domain to an IP. A CNAME points one domain to another. Update these in your registrar's dashboard
• SSL — the padlock icon. Encrypts traffic between users and your server. Free via Let's Encrypt. Most hosting platforms handle this automatically
• Subdomains — api.yourapp.com, dashboard.yourapp.com. Each can point to a different service. The reverse proxy (nginx) reads the hostname and routes to the right container

Buy a domain, point it at your server, let the hosting platform handle SSL. That's it. The complexity is in the initial setup, not ongoing maintenance

Auth

Who can access what

Authentication vs. Authorization

• Authentication — who are you? (login, password, OAuth)
• Authorization — what can you do? (roles, permissions, groups)

Options

Decorators

A decorator is a one-line wrapper you put above a function to change its behavior. In Python, it’s the @something syntax. The function still works the same way — the decorator just runs extra logic before (or after) it executes. Think of it as a bouncer at the door: the party inside doesn’t change, but now only the right people get in

• @login_required — wraps any route. The auth logic runs before your code. No if-statements, no repeated checks. One line locks a page, an API endpoint, or an entire section of your app
• @role_required("admin") — same pattern, finer control. Only users with the “admin” role get through. Stack decorators to combine rules — @login_required + @group_required("client-x")
• Start with Supabase Auth or a managed provider unless you have a specific reason to roll your own. Auth demands 100% correctness — a 95% solution still leaks access

Scheduled Jobs

Code that runs when you’re not watching is where production gets real

The gap between “it works when I run it” and “it runs reliably at 3 AM every day” is the entire discipline of data engineering

When to Use What

Data Engineering — The ETL Pattern

Data pipelines are just scheduled jobs with dependencies and quality gates

• Extract — pull data from source systems (APIs, databases, files, scraped pages). Write adapters that normalize messy inputs into a consistent schema
• Transform — clean, deduplicate, enrich, aggregate. This is where domain knowledge lives. A good transform makes downstream consumers simple
• Load — write to the destination (data warehouse, Postgres, S3). Idempotent writes — running the same job twice shouldn’t corrupt your data
• Monitor — data quality checks, row count assertions, freshness alerts. The pipeline that fails silently is worse than the one that never runs

Workers & Scale

Workers process jobs. Load balancers distribute traffic. Two different problems.

Workers

Background processes that pull jobs from a queue and execute them. For anything too slow for a request/response cycle — sending emails, processing uploads, running ML inference, generating reports

Workers vs. async: workers handle CPU-bound or long-running jobs in separate processes. Async handles I/O-bound concurrency within a single process — waiting on APIs, databases, or file reads in parallel without blocking. Use both: async inside your app for fast I/O, workers for heavy background jobs

Load Balancing

Distributing incoming requests across multiple instances of your app. For when a single server can’t handle the traffic or you need zero-downtime deploys

• Workers scale compute — add more workers to process more jobs in parallel. Each worker is independent
• Load balancers scale traffic — add more app instances behind a balancer to handle more concurrent requests
• You need workers first — most apps hit background processing limits before they hit traffic limits. A single server with 4 workers handles more real-world load than you’d expect

System Design Interviews

Approach it like a case interview — structure first, then depth

A system design interview tests whether you can decompose an ambiguous problem into layers, make defensible trade-offs, and communicate your reasoning. The format maps directly to case interviews: you’re given a vague prompt, you structure the problem, you go deep where it matters, and you present back. The domain is different. The muscle is the same

The Framework

Common prompts

Evaluation criteria

• Structured thinking — decomposed before solving
• Trade-off awareness — named costs of every decision
• Depth on the crux — went deep on the hardest part
• Communication — legible to someone not in the room
• Prioritization — MVP first, scale later

The structured problem-solving, communication, and orchestration that made you a good consultant will make you the ideal forward deployed engineer