This is the same sequence as the Astro stack, and that is deliberate — the order of operations does not change because the framework did.

Three steps change, and they change for one reason: you are building an application, not a document. Logged-in state, data that moves, things that happen without a page reload.

Here is the run.

1. Mobbin — reference before you design

App patterns are worth more than marketing patterns, because they are harder.

Onboarding, empty states, permissions, settings pages that do not sprawl. These have all been solved. Look at how, before you spend a day on your own version.

2. ChatGPT — argue with the shape first

Before any pixels, get the structure out: what the routes are, what each screen is for, what data each one needs.

This is the cheapest possible place to find out your information architecture is wrong. A conversation costs minutes; discovering it after you have built six screens costs a week.

3. Figma — states, not screens

An app is mostly states. The happy path is the easy fifth of the work.

Design the empty state, the loading state, the error, the one-item case and the two-hundred-item case. If you only design the screenshot version, you will build the screenshot version and improvise the rest badly.

4. v0 by Vercel — generate the React, not the idea

v0 produces React components that fit the Next.js world you are going to live in, which is the reason to use it here rather than a general-purpose generator.

Give it the design you already settled. Generating from a settled design gives you scaffolding; generating from a vague prompt gives you something to argue with, and you already had that conversation in step two.

5. Next.js — when you actually need it

Next.js is the right answer when the page has to do something for a specific person:

  • Accounts, sessions and permissions
  • Dashboards and anything behind a login
  • Data that changes while the user is looking at it
  • Server-side work that has to happen per request

If none of those are true, you are paying for a framework you are not using. That is what the Astro stack is for.

6. Storyblok — content the marketing team can move

An app still has pages that are not the app: pricing, docs, changelog, the landing page that pays for all of it.

Storyblok keeps those out of your codebase and in the hands of the people who actually write them, with a visual editor that non-developers do not need training for.

7. Vercel — the deploy is the boring part

Next.js on Vercel is the path with the fewest surprises: previews on every branch, server rendering that works the way the docs say, and no infrastructure afternoon.

You can host it elsewhere. On a small team, spending the afternoon is rarely the right trade.

Astro or Next.js?

Ask one question: does the page need to know who is looking at it?

If no, Astro. If yes, Next.js.

Almost every other argument about these two is a proxy for that one.

When should I use Next.js instead of Astro?
Use Next.js when pages depend on who is viewing them — accounts, dashboards, permissions or data that changes during a session. Use Astro when the page is the same for everyone, which covers most marketing sites, blogs and documentation.
Is v0 worth it if I already use Cursor?
They do different jobs. v0 generates React components from a design or prompt, which is useful at the start of a screen. Cursor edits an existing codebase, which is where most of the work happens after that. Many teams use both.
Why a headless CMS for an app?
Because the pages that sell the app — pricing, docs, changelog — should not need a deploy to change. Keeping them in a CMS means marketing edits copy without a developer in the loop.
Do I have to deploy Next.js on Vercel?
No, it runs anywhere that supports Node or an edge runtime. Vercel is the default here because it needs the least configuration for server rendering and preview deploys.