Your first dev meeting is a wall of acronyms: PRD, POC, MVP, and whatever an RFP is. The vocabulary is smaller than it sounds, though, and pairing up the words that always travel together gets you down to about fifteen. “When does the PRD land?” “Let’s do a POC first.” “Is that in the MVP?” It is the same handful of words on a loop, and the ones that cause damage are the pairs that sound alike.
Here is the part beginners get wrong. They assume the point of learning these words is to nod along in the room. The real payoff is somewhere else. If you build things by telling an AI what you want, these words are the units of work you hand it.
“Build me something like this” and “write the PRD for this feature” are not the same request. The second one tells the AI what shape the answer should take and which boxes to fill. You get a different artifact back.
Why bother learning the words?
Because missing a word in a meeting costs you an hour, while missing the name for the thing you want costs you the build. The random-post wheel in this site’s sidebar started that way. My first ask was “something that picks a random post,” and what came back was exactly that vague. It got usable only after I wrote down the size, the colors, how long it spins, and what shows after it stops. That written-down thing was a small PRD, I just did not know the word yet.
The step-by-step version of that build lives in its own post. Build a web game with AI walks the seven stages from idea to deploy, so go there if you want the order of operations. This post is about the words instead, and mostly about the pairs that sound alike and get swapped.
What is the difference between a POC, a prototype, and an MVP?
Each one tests a different question: a POC tests whether the tech works, a prototype tests whether people understand it, an MVP tests whether anyone uses it. These three get mixed up more than any other trio in the room.
A POC (proof of concept) exists to answer “is this technically possible?” It can be ugly. It can run on ten rows of fake data. Once you know the answer, the POC has done its job, and most of them get thrown away.
A prototype is a convincing fake. Buttons move you to the next screen, but nothing real happens behind them. You build one to ask “is this flow right?” before paying to fill it in.
An MVP (minimum viable product) is a different animal from the other two. It ships to real users. It is a real product with the smallest set of features that still works. The Lean Startup, the book that put the term in everyone’s mouth, describes the MVP as the version you build “to begin the process of learning as quickly as possible.” Small is not the point. Learning from real people is the point.
One more thing worth knowing before you use the word in a meeting. The boundaries move from company to company. Some teams call a clickable mockup an MVP; others will not say MVP until payments work. When it comes up, ask instead of guessing. Where does MVP end for us this time?
Split the same way when you hand work to an AI and you get different output:
POC ask: “Write the smallest code that proves this is technically possible. Skip the styling, use fake data.”
MVP ask: “Cut this down to an MVP scope. List what you removed and one line on why each one can wait.”
Why do a PRD and a spec both exist?
A PRD says what you are building and why; a spec says exactly how each button behaves. Without the first you drift, and without the second you answer the same question ten times.
You can see the definition of a PRD (product requirements document) in the templates the tool vendors publish. Atlassian’s PRD template calls it “a guide that defines the requirements of a particular product or feature, including its purpose, features, and functionality,” and gives you five things to fill in: basics and team roles, objectives and success metrics, assumptions and options, supporting documentation, and open questions plus scope creep.
That last box tells you something. Scope creep, the slow drift of requests past the line you agreed on, is not meeting slang. It has a field in the requirements template. That is how often it happens.
The spec comes next. If the PRD says “the user taps Log in,” the spec says what appears when the email field is empty and what happens on the fifth wrong password. Some teams call it a functional spec, some just call it the spec, and in agile shops it often lives as a pile of tickets instead of one document.
PRD ask: “Write a PRD for this feature: purpose, who uses it, screen-by-screen behavior, and how we know it’s done.”
Spec ask: “Turn that PRD into a spec. For every button, what happens on tap, and what the screen says when the input is empty or wrong.”
Tools will draft both for you now. I looked at one in the Manyfast write-up: you talk to it, and it produces a PRD, a spec, user flows, and wireframes. A wireframe is the screen with the color and art stripped out, layout only. A user flow is the order of screens someone walks through. Both are words people say while sketching on a napkin, so knowing the name is enough.
Will you ever hear RFP?
Only if money and a contract are involved. An RFP (request for proposal) is what a company sends out when it wants an outside team to build something: the requirements, the constraints, the timeline, the budget range, and how bids get judged. Agencies answer with a proposal and a quote.
If you are building your own thing, the word will never come up. It is still worth two minutes of your attention, because writing an RFP is the same exercise as writing requirements. Anything clear enough to hand a stranger for money is clear enough to hand an AI. Same skeleton: what, why, how far, by when, and what counts as done.
How far apart are an API and an SDK?
An API is the counter you talk to; an SDK is a kit that makes talking to that counter easy. They point at the same service often enough that the words blur.
The MDN glossary defines an API by contrast with the screen you use: it is the set of features and rules inside a program that lets other software interact with it, “as opposed to a human user interface.” MDN also suggests reading an API as “a simple contract” between the side offering it and the side using it. That framing is the useful one in a meeting. A contract means your request has to arrive in an agreed shape, and the answer comes back in one too.
WordPress ships one. The REST API handbook lists the addresses and formats, and one of them hands out a list of posts. The sidebar wheel fills its slots with the eight most recent posts that way. Nobody reads titles off a screen and retypes them; a program asks for the list and gets it.
An SDK (software development kit) sits on top of that. Calling a payment company’s API directly means knowing every address and field; install their SDK and one function call covers it. Underneath, the SDK is still calling the API. So when someone says “we’ll just drop in the SDK,” they mean take the shortcut somebody else built. “We’ll hit the API directly” means no shortcut, do it to spec.
Front end and back end fall out of the same picture. The screens people see are the front end, the part that prepares and hands over data is the back end, and the API is where those two talk.
Why does “it worked on my machine” break in production?
Because your laptop and the real server are not the same environment. That gap is why staging and production are separate words.
Production is where the customers are. Staging is the rehearsal copy, set up to match production as closely as you can manage, so you can ship there first. Deploying is the act of putting your build on one of them, and rolling back is putting the previous version back when the new one misbehaves.
This site gave me a clean example. I switched the post URLs to a prettier format and every post started returning 404. The common cause is a rewrite rule that has not been refreshed, and revisiting the settings screen fixes it. That was not my problem. Apache had been configured to ignore the site’s own config file, so nothing I clicked inside WordPress could have worked. The fix was a server change. Both causes are written up in the post on permalinks.
The lesson generalizes. Identical symptoms, different causes, different fixes. Which is why throwing the symptom alone at an AI wastes a round trip.
Deploy ask: “It works locally but not on the live URL. List the environment differences that could cause this, in the order I should check them.”
How do you report a bug so it gets fixed fast?
Write what you did, what happened, and where, in that order. Those three lines are the repro steps, and they are the first thing anyone reads in a bug report.
“It’s broken” carries no information. “If I tap the button twice quickly, the wheel never stops” does. The first one gets you a question back; the second one gets reproduced on the spot. QA is the stage where someone hunts for these on purpose, so “has this been through QA?” means “did a human actually click it in more than one situation?”
The dice game caught me with exactly this. The game goes into a post as one short line of code. To show readers that line, I put the same line inside a code block, and the copy inside the block ran too, so the game rendered twice on the page. I fixed it by writing the example with character entities so it stays text. The sentence describing the widget had quietly built a second widget. You do not find that by reading; you find it by loading the page. It is the game in the dice game post.
Bug ask: “Tapping the button twice fast leaves the wheel spinning. Latest Chrome, same on mobile. Give me three likely causes and the order to check them.”
Do sprints matter if you work alone?
The ceremonies do not, the habit of cutting work into fixed chunks does. That is true of most agile vocabulary. The format belongs to teams; the bones travel.
The definitions are short in the Scrum Guide, which gets revised, so these are the lines standing there in July 2026. Sprints are “fixed length events of one month or less to create consistency.” The Daily Scrum is “a 15-minute event for the Developers,” meant to check progress toward the goal and adjust the day’s plan. The Product Backlog is “an emergent, ordered list of what is needed to improve the product.” Ordered is the operative word there. Not a pile, a queue you pull from the top of.
Working solo, what survives is this: keep one ordered list (backlog), decide this week ends here (sprint), and look at where you left off before you start (standup, minus the standing). The names sound grander than the practice.
Tech debt belongs in this section too. It is the cleanup you skipped because you were in a hurry. This site carries some. A script converts uploaded images to a lighter format on the server, and it only matches png and jpg files. GIFs slip straight through the net. Nothing is broken today, but the day I upload a pile of GIFs, the bill arrives.
15 terms you will actually hear
Words that travel in pairs share a row.
| Term | Short for | What it means in the room |
|---|---|---|
| RFP | Request for proposal | “Build this for us” doc. Answered with a proposal and quote |
| PRD | Product requirements doc | What you’re building and why |
| Spec | Functional spec | How each button behaves |
| Wireframe | – | Layout only, no art. Screen order is the user flow |
| POC | Proof of concept | A test of whether the tech works at all |
| Prototype | – | A convincing fake, nothing real behind it |
| MVP | Minimum viable product | Smallest version you actually ship |
| Scope creep | – | Requests drifting past the agreed line |
| API | – | The counter software talks to software through |
| SDK | Software development kit | A kit that makes using an API easy |
| Back end | – | Prepares the data. Screens are the front end |
| Staging | – | Rehearsal copy. The live one is production |
| QA | Quality assurance | Somebody clicking it in every situation. Bug reports start with repro steps |
| Sprint | – | A chunk of a month or less. The queue is the backlog |
| Tech debt | – | Cleanup you skipped to go faster |
Which five I would learn first
Try to memorize fifteen and you keep none. If you build with an AI, five of them earn their keep.
PRD, spec, POC, MVP, repro steps. The reason is simple: those five are things you can literally ask for. The other ten only need to be recognizable when someone says them, and recognizing takes one read of a post like this. Asking is the part you do every day.
One last thing. The expensive habit is guessing at a word and moving on. When two people leave a meeting holding different definitions, the difference shows up in the build. If you agreed to ship an MVP and one of you pictured a clickable mockup while the other pictured working payments, that meeting decided nothing. Ask when a word goes past you. Not because you are new, but because asking is how you check.