Product types
Before building anything, the most important question is where it's going to live. The product type defines technical constraints, timelines, costs, and what's actually possible.
Web app
Runs in the browser via a URL, no installation required. Updates automatically. The most common starting point and the fastest to launch.
Mobile app
Lives in the App Store or Play Store. Has direct access to device resources like camera, GPS, and push notifications, but requires Apple or Google approval for every update.
Desktop app
An executable program installed on the computer. Can work offline and access local systems and processes. Common in internal tools and enterprise software.
PWA (Progressive Web App)
A web app that behaves like mobile: it can be installed from the browser, receive notifications, and work offline in some cases. The middle ground between web and mobile without going through the app stores.
The three layers of any product
Every digital product has three layers. Understanding which one a problem or new feature lives in is the difference between a productive conversation with tech and one that takes twice as long.
Frontend
Everything the user sees and interacts with. Displays screens, captures actions, and gives immediate feedback. The validations that actually matter don't live here: if they only exist in the frontend, a technically savvy user can bypass them.
Backend
The brain of the system. Decides what can happen and when: business rules, permissions, roles, integrations with external services, flow orchestration. When something "can't be done" technically, the limit is almost always here.
Database
The memory of the system. Stores user data, states, action history, and relationships between entities. It's the source of truth of the product. If something doesn't reach the database, it doesn't exist.
Architecture
Concepts that come up in product conversations and are worth understanding before they appear in a critical meeting.
API
The mechanism by which two systems communicate. Integrating an external service —payments, emails, or AI— means connecting to its API. That connection has costs, usage limits, and dependencies that need to be considered from a product perspective.
Endpoint
A specific address within an API. If the API is the building, the endpoint is the exact door you knock on. When a developer says "we need to create an endpoint for that," it means building the connection point that allows that action to happen.
Authentication vs. Authorization
Authentication is verifying who you are (login, biometrics, magic link). Authorization is deciding what you can do once the system knows who you are (permissions, roles, access to certain sections). They're two distinct problems and are designed separately.
State
The information the system holds at a given moment that can change. An order can be "pending," "in transit," or "delivered." Designing the possible states of an entity and the transitions between them is one of the most important product jobs, and one of the easiest to overlook until an edge case hits production.
Webhook
How an external service notifies your system that something happened, without your system having to keep asking. When Stripe confirms a payment, it sends a webhook. It's the mechanism behind most real-time integrations.
Development workflow
The path from an idea to production has concrete steps. Understanding them helps give realistic timelines, diagnose where something is stuck, and know what to ask.
The basic flow
The developer writes code in an editor (today typically Cursor or Claude Code), saves it to a local repository, syncs it to GitHub, and from there a deployment is made to production via platforms like Vercel. "It's done" and "it's in production" are two different things.
Local
Where development and experimentation happen without risk. Nothing that happens here affects real users.
Staging
The validation environment before production. Where complete flows are tested, bugs are caught, and product, design, and tech align before anything ships.
Production
Where the product lives. Real users, real impact, real metrics. Making changes directly in production without going through the other environments is the cause of most avoidable incidents.
Git and version control
Git records every change made to the code: who made it, when, and why. It's the complete history of the project. GitHub is the platform where that history lives online and where teams collaborate.
Branch
A copy of the code where work happens in isolation without affecting the rest. Main is the code in production. Staging is the validation environment. Feature branches are temporary: created for a specific feature and deleted once integrated.
Commit
A confirmation of changes with a descriptive message. "fix: correct email validation in registration" means something to anyone three weeks later. "changes" means nothing to anyone.
Pull / Push
Pull brings changes from the remote repository to your local copy. Push sends your local changes to the remote repository.
Pull Request
A formal proposal to merge changes from a branch into the main codebase. Another team member reviews and approves it before it's merged. It's where changes are documented — what changed and why.
Merge conflict
Happens when two people modified the same part of the code in different branches and Git can't automatically decide which version to keep. One of the most common reasons why something "simple" takes longer than expected.
Operations
What happens after something ships to production. Ignoring this layer is one of the most common mistakes in growing teams.
Bug vs. technical debt
A bug is incorrect behavior: something that should work one way and doesn't. Technical debt is code that works but was written in a way that makes future changes more expensive. Both consume team capacity, but they're prioritized differently.
Deploy
Publishing a new version of the code to production. Understanding the team's deploy cycle matters for giving realistic timelines externally.
Rollback
Reverting to a previous version when something goes wrong. It's the backup plan for any deploy and one of the reasons version control exists.
Feature flag
A mechanism to enable or disable a feature without a new deploy. Useful for gradual rollouts, tests with a percentage of users, or quickly turning something off if it fails. Reduces the risk of any launch.
Logs
Real-time records of what's happening in the system. When there's a production incident, logs are the first source of diagnosis.
Database
The most ignored layer in product conversations and the one that hurts most when poorly designed. Database decisions are the hardest to reverse.
SQL vs. NoSQL
The two main families of databases. SQL databases (like PostgreSQL) organize information in tables with defined relationships — ideal when data has clear structure. NoSQL databases (like MongoDB) store information in flexible documents without a fixed schema. Most consumer products use SQL.
Schema
The definition of how data is organized: what tables exist, what fields each has, and how they relate. Changing the schema after there's data in production is one of the most delicate tasks in development.
Migration
The process of modifying the schema of a database that already has data. One of the most common reasons why something that seems simple from product requires more time than expected.
Index
A structure that speeds up database searches. Performance problems —slow pages, slow searches, dashboards that won't load— frequently originate in missing or poorly designed indexes.
Query
A request to the database. When a screen shows information, there are one or more queries behind it. Screens with cross-filters or dashboards with aggregations are more expensive to build and serve than simple ones.
Transaction
A set of operations that execute as a unit: either all happen, or none do. In financial products or any system where data integrity is critical, understanding whether operations are correctly transactioned is a product question, not just an engineering one.
Backup
A copy of the database state at a given moment. The frequency of backups and the time it takes to restore the system define the worst-case scenario for any failure.
Security
Not just an engineering topic. Many security decisions are made by product without realizing it: what data is collected, where it's stored, who can see it, and how the system is accessed.
HTTPS / SSL
The protocol that encrypts communication between the user's browser and the server. It's not optional or a technical detail: it's the minimum floor for any product with real users.
Environment variables
How sensitive credentials and configurations are stored outside the code: external API keys, database passwords, authentication tokens. If those keys are written directly into the code and the repository is public, anyone can see them.
OAuth
The standard behind "Login with Google" or "Login with GitHub." Reduces registration friction and eliminates the responsibility of storing passwords, but creates a dependency on the external provider.
Password hashing
When a user creates a password, the system shouldn't store it as-is: it should store a transformed, irreversible version. If the database is compromised, no one can recover the original passwords.
Encryption
Transforming data to make it unreadable without the correct key. In products with sensitive data —health, finance, personal information— encryption at rest is often a regulatory requirement, not just a good practice.
Rate limiting
A mechanism that limits how many requests a user or system can make in a period of time. Protects against automated attacks and bots. From a product standpoint, it matters because it affects legitimate user experience: the message and recovery flow need to be designed.
Principle of least privilege
Every user, system, or process should only have access to what it needs to function, and nothing more. The right guiding principle for designing who can see what and who can do what.
Performance and scalability
Performance is how fast the system responds today. Scalability is whether it will keep responding the same way with ten times more users. Different problems, solved differently — but both start with product decisions.
Latency
The time between a user doing something and the system responding. Past 200ms users start perceiving slowness. Past one second, abandonment rates rise measurably.
Caching
Temporarily storing the result of an expensive operation so it doesn't have to be repeated every time. One of the most effective performance optimizations and one that generates the most subtle bugs when poorly implemented, because a stale cache shows incorrect information.
CDN (Content Delivery Network)
A network of geographically distributed servers that serve static files and images from the point closest to the user. Reduces latency and improves experience without changing anything in the application code.
Load time vs. response time
Response time is how long the server takes to process a request and return data. Load time is how long until the screen is fully visible and interactive for the user. A screen can have fast response time and slow load time if the frontend loads many heavy resources.
Horizontal vs. vertical scaling
Vertical scaling is adding more resources to the same server. Horizontal scaling is adding more servers that distribute the load. Horizontal is more flexible and is the model large systems use, but requires the architecture to be designed to support it from the start.
Bottleneck
The point in the system that limits overall performance. Optimizing anything else without fixing the bottleneck doesn't change real performance. Identifying it is the first step before any optimization work.
Async vs. sync
Sync means the system waits for an operation to finish before continuing. Async means the operation starts and the system keeps going without waiting. Sending a confirmation email synchronously makes the user wait. Asynchronously, the screen appears immediately and the email is sent in the background.
AI in product
No longer a future topic. AI is in the architecture of most new products, and understanding how it works technically changes how you design, what you can promise, and where the real limits are.
LLM (Large Language Model)
The type of model behind ChatGPT, Claude, or Gemini. It doesn't execute step-by-step instructions: it predicts the most probable continuation of a text based on its training. Output is never 100% deterministic. It has no memory between conversations unless you explicitly provide it. Designing with LLMs means accepting variability and building mechanisms to manage it.
Context
The information you pass to the model in each call. An LLM doesn't remember previous conversations or know your system: what it knows at any moment is exactly what's in its context. The architecture of an AI product is largely the architecture of what information to feed the model, when, and in what format. Context has a size limit and a cost: more context, more expensive and slower.
Prompt
The instruction you give the model. In a real product there are three layers: the system prompt defines the model's role and constraints for the entire session; context prompts are built dynamically with data from the current moment; the user prompt is what the person types. Output quality depends more on the first two layers than the third.
RAG (Retrieval Augmented Generation)
The technique that solves the problem of an LLM not knowing your internal information. Instead of retraining the model, a system is built that finds the relevant information when needed and injects it into the context. The model doesn't "know" anything about your company: it reads it in the context of that specific call.
Embeddings
How text is converted into numbers so a system can find semantically similar information, not just exact word matches. When you search "how do I cancel my subscription" and the system finds "how to deactivate your plan," it's because both phrases have nearby embeddings. The technology behind RAG and most semantic search systems.
Agent
An AI system that doesn't just respond but acts. It receives an objective, decides what steps to take, executes actions, evaluates the result, and decides what to do next. The difference from a question-answering LLM is autonomy over the sequence. Most complex AI products are multi-agent systems, where specialized agents collaborate coordinated by an orchestrator.
Hallucination
When an LLM generates information that looks correct but is false. Not intentional: a consequence of how text prediction works. In a support chatbot it's an experience problem. In a system making business decisions it's an operational risk. Designing with AI means knowing where it can occur and building mechanisms to detect or contain it.
Fine-tuning
The process of retraining a base model with your own data so it adopts a specific behavior, tone, or knowledge. More costly and complex than RAG, but useful when the problem isn't about information but about style or logic that can't be solved with prompts. Most product cases get resolved first with RAG and good prompts.
from021.io — get technical asap, from zero to one