By Maciej Pyrc, who maintains Hype Stack.Updated .
The framework argument is the fun one. The decisions that actually cost you later are about data, identity, and who owns the deploy.
Many guides on how to build a web app start with a framework and a hello world. Framework choice matters, but several options can support the same product. Early decisions about data, identity, and deployment often have a larger effect on later work.
This guide covers those decisions in a practical order, then discusses where a template can save time.
First, know which kind of thing you are building
A website primarily presents information. A web app usually lets people create or change data. Accounts are one useful sign that the project needs application infrastructure rather than a set of pages.
That sounds like a small distinction and it changes everything downstream. The moment you have accounts, you have sessions, password resets, permissions, and a database whose contents change while people are looking at it. If your idea works as a set of pages with a contact form, do not build an app. You will spend most of your effort on machinery your visitors may not need.
Before building an application, check whether a landing page, form, and spreadsheet could test the idea with less work.
Decisions that affect later work
Four choices deserve attention early because changing them later can touch several parts of the codebase.
One language across the whole thing
Using one language across the stack can let types cross the network boundary. When a backend field changes and the frontend stops compiling, the team can catch the contract change before deployment.
Postgres, unless you have a reason
It supports relational data, JSON, and full text search in one database. Start with a more specialised store when the product has a clear requirement for it, not because it may be useful later.
Boring tools with long track records
Mature libraries tend to have more documentation, known failure modes, and prior answers to common problems. That support can matter more than a benchmark improvement your application does not need.
Where state lives
Many difficult bugs come from two places disagreeing about state. Decide which data the server owns and what the client may cache or edit locally, then apply that model consistently.
These choices affect how the team detects mistakes, operates the system, and changes it later. Pick them from the application's requirements rather than fashion.
Systems outside the core feature
The core feature is one part of a production application. A product that accepts paying customers may also need:
Seven systems to include in the roadmap
- AccountsSignup, login, logout, password reset, email verification, and handling repeated or expired reset links.
- OrganizationsIf people work in teams, shared records need an owner and organization-scoped queries. Adding that model later can require changes across the data-access layer.
- Roles and permissionsApplications may need more than admin and user: an admin who can invite but not delete, a viewer who can comment, or a billing contact who is not an admin.
- InvitationsSending them, expiring them, and handling the person who accepts one for an email address they no longer control.
- BillingBeyond checkout, account for failed payments, mid-cycle upgrades, and webhooks that arrive twice or out of order.
- Transactional emailDeliverability, templates, and DNS configuration. Templates can live in the codebase, but sending requires an account with a provider such as Resend or Postmark, billed separately.
- An admin screenBecause a customer will email about their account and you need to look it up without opening a SQL client.
These systems may not differentiate your product, but several become necessary once people create accounts, work in teams, or pay. Estimate them separately from the core feature.
A reasonable order of work
The order is not a style preference. Each step changes the shape of the data underneath it, so doing them out of sequence means writing some of them twice.
Build the core workflow
Start with the smallest version of the feature people will use. Sample data and a rough interface are enough to test whether the idea works before you spend time on accounts and permissions.
Add accounts
Once the core workflow is useful, add sign-in and connect each user's data to their account.
Add organizations if you need them
If people will work in teams, decide which records belong to an organization and enforce that scope in every query. It is easier to do this before billing than to change ownership rules later.
Add billing
Set up billing after you know what customers pay for and whether the subscription belongs to a person or an organization.
The order matters because each step depends on decisions made in the one before it. Billing needs a clear owner, and ownership depends on how accounts and organizations work.
Set up deployment early, before the application depends on it.
An early deployment exposes missing environment variables, build assumptions, and infrastructure requirements while the project is still small. Deploying each commit also keeps that path exercised as the application changes.
Where to skip ahead
Many applications need some of the systems above, so teams often rent a platform, generate an initial implementation, or start from a template. Each option shifts the work to a different place.
How do you want to handle these systems?
Quick to start, with platform constraints.
- Auth, database, and hosting arrive configured, which may cover the full infrastructure needs of a small product
- Your app becomes a description of behaviour their runtime knows how to execute
- The provider controls pricing and the roadmap, so check that it supports the capabilities you expect to need
Quick for common flows, less predictable for precise changes.
- An AI builder can produce common account, data, and billing flows
- Precise fixes become harder in parts of the generated application the team has not reviewed
- Generated code still needs documentation, tests, and someone responsible for maintenance
More setup, with source code you maintain.
- A paid starter and billing pack provide accounts, organizations, roles, billing, and an admin app as typed source. Email still needs a separate provider account and DNS setup
- No hosted application platform on the critical path and no upstream repository to merge from
- The cost is real: you own the deploy, the backups, and the upgrade you keep putting off
These options fit different constraints. A platform can suit validation, generated code can suit a small internal tool, and a template can suit a team prepared to operate and maintain the application.
If you want the third one, this stack is one language end to end, Postgres underneath, and the accounts, organizations, roles, and billing already written and typed across the boundary. You still build the workflow specific to your product.
What this guide leaves out
This guide does not cover product design, user acquisition, or mobile clients. Each can change the scope and technical choices. A working application still needs an interface people can understand and a plan for reaching its intended users.
The order above is a useful default when the product starts with an individual workflow and later adds teams and billing. Different products may need a different sequence, but ownership should be clear before billing depends on it. Setting up deployment early reduces the number of infrastructure assumptions that accumulate.
Pick a framework your team can operate, then spend more time on the data model, ownership boundaries, and order of work. If Next.js is the default you are questioning, Next.js Alternatives lists what else there is and what a move really touches.
One example of that shortcut follows, with its screens and pack list. Compare the included systems with the requirements for your application.
The decisions this page skips have their own pages: How to Design a Web App and Web App Security Best Practices, and the question one step earlier in How Do I Make an App? Four Routes, Ranked by Cost.