Plan and scope

Every project starts as a vague idea: "I want to build a recipe app," or "we need a dashboard for the team." A vague idea is not a plan. It has no edges, so it can grow forever and never ship. Scoping is the work of turning that idea into something specific enough to actually build.

Find the smallest useful version

The smallest useful version of an idea, often called the MVP (minimum viable product), is the least you could build that still delivers real value to a real person. Not the least you could build and call it done for yourself: the least that actually helps someone else. A recipe app's MVP might be a single page that shows one person's saved recipes. It is not accounts, ratings, comments, and a mobile app on day one.

Write a definition of done

"Good enough" is not a finish line, it is a feeling that never quite arrives. A definition of done is a short, specific, checkable list: the exact conditions that mean this version is finished. If you cannot check each item off with a plain yes or no, it is not specific enough yet.

• Vague: "The app should feel fast." Specific: "The main page loads in under two seconds on a normal connection."
• Vague: "Users can manage recipes." Specific: "A user can add, edit, and delete a recipe, and see the list update immediately."
• Vague: "It should work well on mobile." Specific: "Every page is usable on a 375px-wide screen with no horizontal scrolling."

Cut scope on purpose

Once you have a definition of done, everything not on that list is a candidate to cut, at least for version one. Cutting scope is not giving up on the idea. It is protecting your ability to actually finish it.

• Write down every feature you are imagining, then cross out anything not required by your definition of done.
• If a feature description contains the word "and," it is probably two features. Split it, then cut one.
• Ask, for each remaining item: could I ship without this and still deliver the core value? If yes, it goes on the v2 list, not v1.
• Set a real deadline, even a rough one. An open-ended timeline lets scope grow forever; a date forces the cutting decisions you have been avoiding.

A stack is the set of tools and technologies a project is built on: the framework, the database, the hosting, the pieces that fit together to make the thing run. Picking one is less about finding the "best" stack and more about matching tools to what this specific project needs.

The first fork: static site or app?

The single biggest decision is whether the project needs a backend and a database at all. A site that just displays content, a portfolio, a marketing page, most blogs, can be a static site: files that get served as-is, with no server-side logic running per request. A web app that stores per-user data, handles logins, or reacts to input in real time needs a real backend behind it.

Get this fork right and half of your later decisions make themselves. A brochure site with no backend has nothing to secure, nothing to back up, and nothing to patch. Building one like it is a full app, with a framework, a database, and user accounts it will never use, adds real cost for no benefit.

Pick tools for the job, not by habit

Once you know which side of that fork you are on, resist reaching for the framework you already know out of habit, or the one that is trending this month, without asking whether it fits. A short list of real questions gets you further than either instinct.

• What does the project actually need this month, not in a hypothetical year two?
• Can you and whoever else works on this actually maintain the choice, or does it require expertise nobody on the team has?
• Is there real documentation and community support, so getting stuck does not mean being stuck alone?
• What does it cost at the scale you expect now, not at the enterprise scale a sales page is trying to sell you?

For the mechanics of this decision in more depth, the specific free tools people actually use at each step and how to set them up, see How to start building a website.

Almost every web app, no matter the framework, breaks down into the same handful of parts. Learning what each one is responsible for makes it much easier to reason about where a bug lives or where a new feature belongs.

Following one click through the system

Take something ordinary: a user clicks "Save" on a form. That single click passes through several parts before anything actually happens, and each part hands off to the next.

The reply travels back the same way it came: the database returns the result to the backend, the backend formats a response, and the frontend updates what the user sees, usually within a fraction of a second.

What each part is actually responsible for

A few habits worth building now

• The backend should never trust data from the frontend without checking it again. Anyone can send a request that did not come from your UI.
• The database is the one part that must not lose data if a server restarts. Frontend and backend code can be redeployed from scratch; user data usually cannot be recreated.
• "Hosting" is not one thing. Frontend, backend, and database are frequently hosted in different places, even for a small app.

Before you build a single feature, a small amount of setup pays for itself many times over: a repository under version control, a real separation between the environment you build in and the one real users touch, and a place for secrets that is not the code itself.

Repository and version control

Version control, almost always Git, tracks every change to your code as a saved snapshot. Without it, "undo" only goes back as far as your editor's memory, and there is no record of what changed, when, or why. Set this up before writing feature code, not after something has already gone wrong.

1. 1Create a repository, on GitHub, GitLab, or similar, before writing a line of feature code.
2. 2Commit early and often, in small chunks that each describe one change, not one giant commit at the end of the week.
3. 3Push to a remote regularly, so your code exists somewhere besides one laptop.
4. 4Protect the main branch, so changes go through a pull request and a review step, even on a project where you are the only person working.

Separate dev and production

Development is where you build and break things on purpose. Production is what real users see. Keeping them separate means a mistake you make while experimenting stays contained, instead of landing in front of someone relying on the app to work.

Secrets go in environment config, never in the repo

A database password, an API key, or any credential is a secret. Secrets belong in environment variables, values set outside your code and read by it at run time, never typed directly into a file that gets committed. A file listed in .gitignore keeps local secrets out of version control; most hosts also let you set environment variables per environment in their dashboard.

# .env (local only, never committed)
DATABASE_URL=postgres://user:pass@host/db
API_KEY=sk_live_xxxxxxxx

# .gitignore
.env

• A secret committed to a repository is compromised the moment it is pushed, even to a private one; deleting the file afterward does not remove it from the repository's history.
• Development and production almost always need different secret values, for example a test database versus the real one, never the same credential reused across both.
• Most hosts (Vercel, Netlify, Railway, and similar) let you set environment variables per environment directly in their dashboard, which is where production secrets belong.