Resources
Every term you'll hit while building apps with AI. From context windows to deployment — explained in plain English for vibe coders.
Building software by describing what you want in plain English and letting AI write the code. You drive with intent and taste, not syntax.
Why it matters
You don't need to understand every line the AI writes. You need to understand what you're building and why. The AI handles implementation — you handle direction.
The instructions you give an AI. The clearer and more specific your prompt, the better the result.
A good prompt includes context, constraints, and examples. Think of it as a brief for your AI — garbage in, garbage out.
The amount of text an AI can 'see' at once — your prompt, the chat history, and any files it's reading.
Every model has a limit. When you hit it, the AI starts forgetting earlier parts of the conversation and responses get sloppy.
The skill of writing effective prompts to get the best possible output from AI tools.
Structure and specificity matter more than fancy wording. The best prompt engineers think like product managers — clear requirements, clear constraints.
Giving AI the right files, docs, and instructions so it has what it needs to do the job well.
The model is only as good as what you feed it. Context engineering is about curating the right input — not just writing a good prompt.
The unit AI models use to read and generate text. Roughly 4 characters or three-quarters of a word in English.
AI usage is priced per token. Bigger files and longer chats burn more tokens — which means higher costs and slower responses.
The kind of AI behind ChatGPT, Claude, and Gemini. Trained on huge amounts of text to predict the next word.
Different LLMs have different strengths. Some are better at code, some at reasoning, some at creative writing. Picking the right one matters.
When an AI confidently makes up something that isn't true — a fake function, a wrong API, a non-existent library.
This is why you always verify what AI gives you. It sounds right, it looks right, but it might be completely invented.
An AI that can take actions on your behalf — read files, run commands, edit code — not just chat back.
Agents don't wait for you to copy-paste. They operate in your environment, make decisions, and execute. Cursor and Claude Code work this way.
AI that doesn't just suggest code but takes actions autonomously — reading files, running commands, fixing errors in a loop.
The difference between a chatbot and an agent. Agentic coding tools can chain multiple steps together without you intervening at each one.
A standard that lets AI tools connect to outside services (databases, APIs, your files) in a consistent way.
Think of it as USB-C for AI tools. One protocol, many connections. Build once, plug into anything.
The hidden instructions that shape how an AI behaves before you say anything. Sets the tone and rules.
Every AI tool has one. It's why Claude sounds different from ChatGPT out of the box. You can write your own to customize behavior.
Training a model further on your own data so it specializes in a task or style.
Most vibe coders won't fine-tune models directly. But understanding it helps you pick the right tool for the job.
A technique where AI looks up real data from your files or database before answering, reducing hallucinations.
Instead of guessing from training data, the AI retrieves actual information first. Essential for apps that need accurate, up-to-date answers.
A way to turn text into numbers so computers can compare meaning and find similar things.
Used behind the scenes in search, recommendations, and RAG. You describe something in words, embeddings let the AI find related content.
Running a trained AI model to get output. Every time you prompt Claude or ChatGPT, that's inference.
Training builds the model. Inference uses it. You pay for inference every time you make an API call.
A setting that controls how creative or predictable AI output is. Low = safe and consistent. High = wild and varied.
For code generation you usually want low temperature. For brainstorming or creative writing, turn it up.
When an AI agrees with you instead of telling you the truth. It wants to please you, even when you're wrong.
A common failure mode. The AI says 'great idea!' when it should say 'that won't work.' Push back and ask it to challenge your assumptions.
The date after which a model has no training data. It doesn't know about anything that happened after that point.
This is why AI sometimes suggests outdated libraries or deprecated APIs. If it was trained before a tool existed, it literally can't know about it.
Custom instructions you give Cursor so it understands your project's patterns, stack, and preferences.
A well-written rules file is the difference between Cursor fighting you and Cursor feeling like a teammate who gets your codebase.
The smallest version of your idea that still solves the core problem. Ship it, learn, iterate.
Perfectionism kills apps. An MVP that's live and getting feedback beats a polished app still on your laptop.
To release your product to real users. Getting it out into the world.
Shipping is a muscle. The more you do it, the less scary it gets. Done is better than perfect.
To repeat a process and improve each time. Small changes, tested and refined, compound into big results.
Pushing your app from your computer to the internet so other people can use it.
With modern tools like Vercel or Netlify, deployment can be as simple as pushing code to GitHub.
The service that runs your app on the internet — like Vercel, Netlify, or Cloudflare.
Your app's address on the internet, like ninakolari.com. You buy it from a registrar.
The phonebook of the internet. Translates your domain name into the server address that actually serves your site.
A copy of your live app where you test changes safely before pushing them to real users.
Breaking things in staging is fine. Breaking things in production is not.
The live version of your app that real users interact with.
The process of bundling your code into the optimized files that get served to users.
Apple's tool for letting beta testers install your iOS app before it goes on the App Store.
Essential for iOS development. Get real people using your app and catching bugs before the public launch.
Apple's process of approving your app before it can be published. Usually takes 24-48 hours.
Your app can be rejected for guideline violations. Read the rules before you submit.
An error in your software that makes it behave in a way you didn't intend.
The detective work of finding and fixing bugs — reading errors, testing assumptions, tracing what went wrong.
AI tools are great at debugging. Paste the error, give context, and let the AI trace the problem.
Rewriting code to make it cleaner or faster without changing what it does.
The future cost of quick-and-dirty code. Useful to ship fast, painful if you never clean it up.
Every vibe coder accumulates tech debt. The trick is knowing when to pay it down and when to keep shipping.
A small urgent fix shipped straight to production to patch a live problem.
Reverting a deploy to the previous working version when something breaks in production.
Automation that tests your code and ships it every time you push a change.
Removes the manual step of deploying. Push to GitHub, tests run, and your app updates automatically.
Starter code or templates that give you a working foundation so you don't build everything from scratch.
Auto-generating the basic file structure and setup code for a new project or feature.
A tool that tracks every change to your code so you can undo, branch, and collaborate without overwriting each other.
Even solo builders need Git. It's your safety net — you can always go back to a version that worked.
The website where most people store their Git repositories. Think Google Drive for code.
A folder containing your project's code and its full history of changes.
A snapshot of your code at a point in time, with a message describing what changed.
Good commit messages are like breadcrumbs. When something breaks, they tell you exactly when and why.
A parallel version of your code where you can experiment without breaking the main one.
A proposal to merge changes from one branch into another. Where code review happens.
Combining changes from one branch into another.
When Git can't auto-combine two changes to the same line and needs you to pick which one wins.
Sounds scary, looks messy, but it's just Git asking you to make a decision. AI tools can help resolve these.
Push sends your local changes up to GitHub. Pull brings down changes others made.
Your own copy of someone else's project that you can change freely without affecting the original.
Code that anyone can read, use, and contribute to. The backbone of modern software.
Most of the tools you use for vibe coding are built on open source.
Having someone (or an AI) read your code before it merges — catching bugs and sharing context.
A tracked note in a repo describing a bug, feature request, or task to do.
The part of your app users see and click — the screens, buttons, and layout.
The part users don't see — servers, databases, business logic, and APIs that power the frontend.
Working on both frontend and backend. A full-stack builder can wire up the whole thing.
Vibe coding is making full-stack more accessible. You describe what you need on both sides and the AI builds it.
A way for two pieces of software to talk to each other. Your app uses APIs to ask other services for data or actions.
When your app checks the weather, processes a payment, or sends an email — it's calling an API.
Where your app stores information that needs to stick around — users, posts, orders.
Supabase, Firebase, and Planetscale are popular options. They handle the heavy lifting so you focus on the product.
A service that gives you a ready-made backend — database, auth, storage — so you don't build it yourself. Supabase and Firebase are examples.
The reason vibe coders can ship full apps fast. BaaS handles the infrastructure so you focus on the product.
A computer connected to the internet that runs your backend code and serves data to users.
Running backend code without managing a server. The cloud provider handles scaling and uptime for you.
You still have servers — you just don't think about them. Your code runs on demand and you pay per use.
Code that runs on servers close to your users around the world, making responses faster.
Vercel, Cloudflare, and Supabase all offer edge functions. Great for auth checks, redirects, and quick API logic.
A specific URL on an API you can call to get or send data, like /users or /orders.
The format APIs use to send data back and forth. Looks like a list of key-value pairs.
You'll see JSON everywhere — API responses, config files, data storage. It's the universal language of web data.
Proving who a user is — usually with email and password, magic link, or social login.
Deciding what a logged-in user is allowed to do. Different from authentication.
Auth = who are you. Authorization = what can you do. You need both for any app with user accounts.
A standard for letting users log in with their Google, Apple, or GitHub account instead of creating a new password.
A secret value (like an API key) stored outside your code so it doesn't leak into GitHub.
Every deployment platform has a place to store these. If you paste an API key directly in your code, it's exposed.
A password that lets your app use a third-party service. Keep it secret — never paste it in your frontend code.
A pre-built library that makes it easier to use someone else's API or platform.
A set of tools and rules for building apps faster — like React, Next.js, or SwiftUI.
A framework gives you structure. A library gives you a tool. Frameworks are opinionated — they tell you how to organize your code.
Reusable code someone else wrote that you can drop into your project to skip writing it yourself.
An external library or package your project needs to work. Listed in your package.json or similar file.
More dependencies = more things that can break when they update. Keep it lean.
A tool that installs, updates, and manages your project's dependencies. npm, yarn, and pnpm are the common ones.
A reusable piece of UI — a button, a card, a header — you build once and use everywhere.
Data your app remembers right now — what's typed in a field, which tab is open, who's logged in.
A temporary store of data so your app doesn't have to fetch the same thing twice. Faster, cheaper.
A network of servers around the world that serves your images and files from the location closest to each user.
The padlock in the browser bar. Encrypts data between your user and your site so it can't be snooped on.
An automatic message one service sends another when something happens — like Stripe pinging your app when a payment succeeds.
Capping how many requests a user or app can make in a time window. Protects your API from abuse and overload.
Code that runs between a request coming in and your app responding. Used for auth checks, logging, redirects.
Your own computer acting as a server while you develop. The app runs locally before you deploy it anywhere.
How it feels to use your product — clarity, flow, friction. The full journey, not just looks.
What the user sees and interacts with — colors, layout, buttons, typography.
A rough sketch of a screen showing layout and structure, no styling. Used to agree on the bones before designing.
A static, fully styled picture of what a screen will look like. No interactivity yet.
A clickable version of your design used to test the flow before you write real code.
A shared library of colors, fonts, spacing, and components so your product looks consistent everywhere.
The path a user takes through your app to complete a task — sign up, buy, check out.
The first experience a new user has. Where most apps lose people if they're not careful.
A confusing onboarding kills retention. Keep it short, show value fast, don't ask for too much upfront.
A design that adapts and looks good on any screen size — phone, tablet, desktop.
Designing your product so people with disabilities can use it — proper contrast, labels, keyboard navigation.
Not optional. Good accessibility makes your product better for everyone.
Showing two versions of something to different users to see which one performs better.
A short description of a feature from the user's perspective: 'As a ___, I want ___ so that ___.'
Keeps you focused on the user's problem instead of jumping to solutions. Write these before you build.
When you've built something a specific group of people genuinely want and pay for. The thing every founder is chasing.
You'll know when you have it — people complain when it's down, tell their friends, and keep coming back.
How your app makes money — subscriptions, one-time purchases, ads, affiliate, or a mix.
A pricing model where users pay on a recurring schedule — monthly or yearly — for ongoing access.
Free core version, paid upgrade for more features or higher limits. Common for indie apps.
The percentage of users who cancel each month. Low churn means people stick around.
The predictable monthly income from your subscriptions. The number SaaS founders watch most.
Your MRR multiplied by 12. The yearly view of subscription income.
How much you spend on average to get one paying customer.
Healthy when your LTV is at least 3x your CAC. If you're spending more to acquire than you earn, you have a problem.
How much revenue an average customer generates over the whole time they stay with you.
Sharing your progress, numbers, and lessons publicly while you build. Distribution and trust as a side effect.
Not about bragging. It's about showing the real process — what worked, what failed, what you learned.
Optimizing your app's title, keywords, screenshots, and description to rank higher in App Store search.
Like SEO but for the App Store. The right keywords and screenshots can make or break your organic downloads.
A strategy where the product itself drives sign-ups and growth, not a sales team.
How many months your business can keep running before it runs out of cash.
A detailed description of your perfect customer — who they are, what they need, and why they buy.
Software you pay for on a subscription instead of buying once. Think Notion, Figma, Spotify.
111 terms and counting