
A plain-language glossary of the software terms you actually need to know — so you can ask the right questions, spot the red flags, and have a real conversation with the people building your product.
If you've built something with Lovable, Bolt, Cursor, Replit, or any AI coding tool — you shipped. You identified a problem, built a solution, and got it into people's hands.
How your app is organized. Think of this as the floor plan of a building — where things go, how they connect, and whether the whole thing can stand up under pressure.
A single file doing way too much — UI, business logic, database calls, payments all crammed together. One bug fix in payment logic can accidentally break user login.
Breaking your app into small, independent pieces that each do one thing. Like building with Lego blocks instead of carving from a single rock. Modular code is fixable — when something breaks, you know exactly where to look.
Different parts of your app handle different jobs. UI code shouldn't also process payments. When tangled together, changing anything is like pulling a thread on a sweater.
A monolith handles everything in one app. Microservices split into many small apps. Most AI-built apps are monoliths — that's fine for starting out.
Red flag: Someone insists you need microservices on day one. You don't.
A self-contained, reusable building block. A login form. A nav bar. A product card. If your "Add to Cart" button exists as 15 separate pieces of code, fixing a bug means fixing it 15 times.
Any outside code or service your app relies on. Every dependency is a point of trust — if it gets hacked or changes pricing, your app is affected. AI tools love importing dependencies, sometimes unnecessarily.

Reorganizing code to make it cleaner without changing what it does. Like renovating a house — same rooms, better wiring. AI-built code almost always needs it. The AI optimizes for "does it work now?" not "will this hold up in six months?"
The accumulated cost of shortcuts. Like credit card debt — the longer you ignore it, the more interest you pay. AI tools are prolific debt generators because they optimize for speed, not sustainability.
How your app talks to other services. Every time your app sends a payment to Stripe, checks an address, or pulls shipping rates, it's using an API.
A structured way for two pieces of software to talk. Like a waiter — you tell the waiter what you want, the waiter tells the kitchen, the kitchen sends back your food.
A specific address your app sends requests to. If an API is a building, an endpoint is a specific door. Each endpoint is a potential point of failure and cost.
A unique code that identifies your app to an external service. Critical: API keys are secrets. They should never be visible in your code — especially not in browser-side code.
Two styles for how APIs communicate. REST is a fixed menu — you get what's on it. GraphQL is a buffet — you pick exactly what you want. Both work. The right choice depends on your app's specific needs, not preference.
Any external service your app connects to — Stripe, Twilio, SendGrid, Google Maps. Each adds power and risk. Every integration needs to be monitored, maintained, and budgeted for.
A maximum on requests your app accepts per time period. Without it, a single bug or bad actor can flood your app — crashing it or spiking costs. One of the most common things missing from AI-built apps.
Waits until a user stops typing before triggering an API call. Without it, typing "shipping rates" fires 13 separate API calls. This is one of the most expensive problems in AI-built apps — the AI adds the field but skips the debounce.
Storing a copy of data you've already fetched so you don't fetch it again. Reduces API costs, speeds up your app, and puts less strain on external services. AI-built apps rarely implement it proactively.
Automatically retrying a failed request after a short delay. Without it, a two-second network blip means a failed payment — money in limbo, transaction lost. With it, your app handles hiccups gracefully.
The engine room of your app. Users never see this — but it's where data gets stored, logic gets processed, and things either work reliably or fail silently.
Small pieces of code that run on servers close to your users. In Supabase (which Lovable uses), your backend logic likely runs as edge functions. They're billed per run — missing debounce turns pennies-per-month into dollars-per-day at scale.
You write code, upload it, and the cloud provider runs it — automatically scaling up and down. Great for getting started. But "serverless" doesn't mean "costless." You pay per execution, and inefficient code runs up the bill fast.
Configuration values stored outside your code. Also where sensitive info like API keys and passwords should live — not hardcoded. If secrets are in the code, anyone with code access has access to everything.
Keeping sensitive credentials secure and controlled. If someone gets your database password, they have your users' data. AI tools frequently put secrets in places they don't belong.
A relational database (like PostgreSQL) organizes data into structured tables — like a spreadsheet. NoSQL (like MongoDB) is more flexible. The choice matters less than whether the data is organized thoughtfully, with proper indexes and clear relationships.
Versioned scripts that change your database structure safely and reversibly. Without them, database changes are manual and risky. If something goes wrong, there's no undo. Migrations give you a full history and rollback capability.
A tool that lets your code talk to the database using plain language instead of raw SQL queries. Makes database interaction easier and protects against some attacks. But ORMs can hide performance problems — generating slow queries you never see.
Security isn't a feature you add later — it's a property of how the whole system is built. And it's one of the areas where AI-generated code is weakest.
Authentication is proving who you are (logging in). Authorization is proving what you're allowed to do (can this user access this page?).
"Who are you?" — Verifying identity at login
"What can you do?" — Controlling access to actions and data
Scrambles data so only authorized parties can read it. In transit: protects data moving between app and server. At rest: protects data stored in your database. Without HTTPS, passwords travel in plain text.
The database itself enforces which rows a user can see — not just your app code. In Supabase, RLS is available but often not enabled by the AI. Without it, any authenticated user can query any row in any table.
Checking that user-submitted data is what you expect before processing it. Every piece of data entering your app from outside should be treated as untrusted. Bad data can corrupt your database or open security holes.
Controls which websites can make requests to your server. AI tools often set CORS to "allow everything" to make things work quickly — removing an important security layer in the process.
Someone enters malicious database commands into a form field and your app accidentally executes them. A login form without protection could let an attacker dump your entire database with a single input.
Prevention: use an ORM or parameterized queries. Never build database queries by directly inserting user input.
An attacker injects malicious code into your website that runs in other users' browsers. If your app displays user-generated content without sanitizing it, that code can steal other users' session data — no password needed.
It's easy to build something that works for ten users. The question is whether it works for ten thousand.
Distributing traffic across multiple servers so no single one gets overwhelmed. Like opening more checkout lanes when the store gets busy. Without it, all traffic hits one server — when you exceed its limit, your app crashes.
The time between a user action and the app's response. High latency makes your app feel broken even when it's working. Common causes: too many API calls, missing caching, slow database queries, or servers far from your users.
A global network of servers storing copies of your static files close to users. A user in Tokyo gets your files from Japan, not Virginia. Most modern hosting platforms include a CDN — but confirm your assets are actually being served through one.
Like an index at the back of a book — instead of scanning every page, you go straight to the right one. AI tools rarely add indexes because the app works fine during development with small data. At scale, unindexed queries can go from 10ms to 10 seconds.

Vertical means making your server bigger. Horizontal means adding more servers. One horse stronger vs. adding more horses to the team.
Vertical scaling has a ceiling. Horizontal scaling is theoretically unlimited — but your app architecture needs to support running across multiple servers.
The delay when a serverless function hasn't been used recently and needs to "wake up." Like starting a car that's been sitting in the cold. Common with Supabase edge functions — users during off-peak hours get a noticeably worse experience.
Can you see what your app is doing? If something breaks at 2 AM, how do you find out — from a dashboard, or from an angry customer?
Your app's diary. Every request, every error, every important event. Without logs, debugging is guesswork. AI-built apps often have minimal logging — the AI doesn't add it unless you ask.
Tools like Sentry automatically capture and organize errors in production. Users don't report most errors — they just leave. Error tracking catches problems your users won't tell you about.
Regularly checks whether your app is online. If it goes down, you get an alert immediately — not three hours later when a customer emails you. Simple monitors are free and take minutes to set up.
Automated notifications when something crosses a threshold. Monitoring without alerting is like a security camera nobody watches. The data is there, but nobody sees the problem until the damage is done.
A view showing exactly what your infrastructure costs, broken down by service. Without it, you're flying blind. A spike in users could mean a spike in costs you only discover at month-end.
Charges you incur every time a serverless function runs — billed per execution, sometimes per millisecond. Redundant API calls (like calling an API on every keystroke) multiply across hundreds of users into thousands of unnecessary executions per day.
Monitoring tells you when something is wrong. Observability tells you why.
Monitoring is like a dashboard light saying "engine problem." Observability is having diagnostic data to pinpoint the exact issue without guessing.
As your app grows, "something is broken" isn't enough. You need to trace a request from the user's click, through your API, to the database, and back.
How software gets built, tested, and shipped. Even if AI writes the code, you still need a process to keep things safe and organized.
Each layer catches what the one before it missed. Without all four, you're deploying with no safety net — relying on users to find your bugs.
Tracks every change ever made to your code. An unlimited "undo" button for your entire project. Without it, there's no going back. If your AI tool isn't connected to a Git repo, you're working without a safety net.
Production is your live app. Staging is a copy for testing. You try changes in staging first. Deploying untested changes directly to production means your users are your test subjects.
Reverting to a previous version when something goes wrong. Your emergency brake. Without it, fixing a bad deployment means debugging under pressure while the app is broken for every user.
A switch to turn a feature on or off without deploying new code. Release to 10% of users first. If something goes wrong, flip the switch — no rollback needed. Decouples deploying code from releasing features.
At some point, you'll work with a human engineer — for an audit, a retainer, or a full build-out. Here's how to make that relationship productive.
Retainers are great for ongoing support — code reviews, architecture guidance, firefighting. Project engagements are better for defined work with a clear deliverable. Knowing which you need prevents overpaying for the wrong arrangement.
Engineers do their best work in uninterrupted blocks. Default to async — written updates, screen recordings, documented decisions. Reserve sync for complex discussions. Too many "quick calls" fragment their time and slow everything down.
Three parts: expected behavior (what should happen), actual behavior (what did happen), steps to reproduce (exactly how). "The app is broken" wastes everyone's time. A precise report gets a faster fix.
Scope creep kills timelines — each addition seems small but they compound. WIP limits cap how many tasks are in progress at once. Multitasking is the enemy of shipping. Focus on finishing, not starting.
You don't need to understand the code to get answers — just ask your developer, your AI tool, or the engineer you bring in for an audit.
If yes, you likely have god files that need to be broken up.
Tools like Sentry or LogRocket — not just "I'll check the logs sometimes."
If not, you're flying blind on spending.
Without it, a bot can flood your app and crash it.
Search your codebase for hardcoded keys. If you find them, move them immediately.
If every change goes straight to production, you're gambling with your users' experience.
Especially critical on Supabase. Without RLS, any authenticated user may access any data.
If a deployment goes wrong, you need an emergency brake — not a three-hour debugging session.
If it fires on every keystroke, you're burning money and invocations.
Not edited it. Reviewed the structure, security, and architecture. If the answer is no, this is your most important next step.
You just need to know to ask. That's the whole point. The AI won't flag what it doesn't know to flag. That part's on you.
This pocket book gives you the vocabulary to have real conversations, catch real problems, and protect what you've built.
The Tech Pocket Book for Non-Tech Founders