Getting Started with Modern Development

The first hour of a project sets the tone for everything after it. Here is a setup that stays pleasant as the codebase grows.

Make the feedback loop fast

Everything else is secondary to how quickly you find out you were wrong.

• Type checking on save. TypeScript catches a whole class of bug before the browser does.
• A dev server that reloads reliably. If you find yourself restarting it, fix that first.
• One command to run everything. npm run dev should be the whole ritual.

Structure by feature, not by type

The instinct is to group files by what they are — all components here, all hooks there. It reads well on day one and badly on day ninety, when a single change touches six folders.

src/
  billing/       # page, components, api, types for billing
  experts/
  blog/
  lib/           # genuinely shared things only

The test: to delete a feature, can you delete one folder?

Lint rules that earn their place

A linter that cries wolf gets disabled. Keep the rules that catch real bugs:

• unused variables (usually a rename you did not finish)
• missing await on a promise
• exhaustive dependency arrays

Drop the ones that are taste. Formatting is not worth a code review comment — let the formatter own it.

Write the error path first

Most bugs in young codebases are not in the happy path. Before you ship a feature, answer:

1. What does the user see when the network fails?
2. What do we see — is there a log with enough context to find the request?
3. What happens if this runs twice?

That third question catches more production incidents than the other two combined.

Code that works is table stakes. Code that tells you how it failed is what you actually want at 2am.

Commit like someone will read it

They will — probably you, six months from now, trying to work out why a line exists. A commit message that explains why is worth more than one that restates the diff.

Bad:  update user route
Good: Reject expired invites so a reused link cannot create a second account

Ship on day one

Deploy the empty app before you build anything into it. Every deploy after that is a small change rather than a big scary one, and you will have found your environment-variable problems while the stakes are zero.