Six steps end-to-end. The first two ship through git, PR, and a deploy (your normal SDLC). The next three ship through Studio's publish, same React, same CMS, no rebuild. Below: where each step lives, who owns it, and what you don't have to repeat per page.

Step	Without Studio	With Studio
Setup	App shell + Delivery SDK	App shell + Delivery SDK + Studio SDK + canvas route (a dedicated route where Studio renders the editor) + ONE catch-all template route (handles every URL)
Build components	Author + Storybook (isolated, fixtures)	Author + Storybook + register in Studio (1-liner or via CLI)
Compose multiple components	In code, per page	In Studio as sections: reusable, previewable with real data
Build a page	Hand-code layout + data-fetch + prop-mapping per page	Build a template once; drop sections; bind to fields; done
Change page layout	Code change, PR, redeploy	Author in Studio, publish
Re-map a prop to a different CMS field	Code change, PR, redeploy	Click the binding, pick a different field, publish
Preview a composed page with real data	Build + deploy + visit URL	Open the section/template canvas, pick a preview entry
Launch a new content type page	New route + new layout file + new fetcher	Create a new template for the content type, drop sections

This matters because Studio isn't trying to take over your stack:

• Your components stay in your repo: same build, same bundler, same deploy
• Your design system stays sovereign: Studio uses your components, tokens, breakpoints; not its defaults
• Contentstack stays Contentstack: entries, content types, locales, publishing, branches, webhooks all work the same way
• Storybook still does its job: isolated component preview is still its lane
• Your existing pages keep working: Studio is additive; you can adopt it section-by-section, template-by-template

Studio is for layout + composition + binding. Some things are still better done in code:

• Component implementation itself (Studio doesn't write components for you, it composes them)
• App-level concerns (auth, routing, analytics, error boundaries)
• One-off complex logic inside a component (data transforms, animations, integrations)
• Server-side data fetching strategy (Studio supports CSR + SSR but you choose the path)

The right way to think about Studio: the layer above components, the layer below the app shell. Everything above stays code; everything below stays code; the composition in between becomes data.

Depending on where you are, pick the onboarding path that matches:

• Enterprise / bringing your own components first: for teams shipping with their own design system
• Just exploring: for evaluators using Studio's defaults to see the shape

Both lead to the same destination: a Studio-powered app that composes your components against your CMS data, previewable at every step.

• Set up Studio: the install + configure walk-through
• Register your components: the first step after install