Practical platform decision guide
Webflow, Astro, Framer or Expo: which should you use?
Choose a platform based on what you are building, who needs to manage it and what the team must be able to change after launch.
Webflow, Astro, Framer and Expo are often grouped together because they can all help something reach a screen. They are not four versions of the same tool. Three can play a role in a website. Expo is primarily for building applications that run across native devices and the web.
I use this decision less as a technology contest and more as an ownership question. The right platform is the one your team can operate, extend and measure without fighting the way it was built.
Start with the team, not the tool
Choose the closest answer. This narrows the conversation, but the content model, integrations and long-term owner still matter.
Likely starting point
Webflow
A marketing team needs visual control, a capable CMS and a fast route from design to launch.
Check before committing
It becomes less comfortable when the product needs deep application state or native mobile behaviour.
The next option from these answers is Framer. A hybrid can be sensible when the marketing site and product have different owners.
The quick comparison
| Platform | Choose it when | Be cautious when | Natural owner |
|---|---|---|---|
| Webflow | A marketing team needs visual control, structured content and fast page iteration. | The project depends on deep application state or complex product logic. | Marketing, design or website team |
| Astro | The site is content-led, performance matters and the team wants control of a codebase. | Nontechnical editors need to reshape page layouts visually every day. | Developer with content or marketing input |
| Framer | A design-led marketing site needs to launch quickly with expressive layout and motion. | Content operations, integrations or application logic are likely to become complex. | Designer or small marketing team |
| Expo | The core experience belongs on iOS and Android and benefits from shared product code. | You only need a conventional marketing website or content publication. | Product and engineering team |
Start with the thing you are building
A marketing website needs publishing, campaigns, content and conversion journeys. A product needs state, accounts, permissions and behaviour. A mobile app may need notifications, device APIs and store releases. Choosing the platform becomes easier once the primary job is clear.
A portal can still have a Webflow marketing site. An Astro publication can link into an Expo product. The public website and the product do not have to share a platform when they have different users and owners.
Choose Webflow for visual marketing ownership
Webflow is useful when marketers and designers need to create pages, work with structured CMS content and see changes in context. It is particularly strong when the website itself is the main operational surface and regular iteration matters more than owning every line of the rendering stack.
I still use Webflow for appropriate website work. I would not force it to behave like a complex application simply because the first few screens can be built there. Once user state, permissions and business logic become central, a separate product stack is usually clearer.
Choose Astro for a content-led codebase
Astro is designed around content-driven websites and sends very little client-side JavaScript by default. It suits publications, marketing sites and large content libraries where performance, component control and a maintainable codebase matter.
This website is built with Astro. That gives me direct control over routes, structured data, content components and interactive islands such as the planner on this page. The trade-off is that page structure is primarily managed in code, even if the content itself comes from a CMS.
Choose Framer for fast, design-led launches
Framer is a strong fit for a focused marketing site where visual iteration, responsive layouts and motion are central. Its current editing tools also let permitted collaborators update visible content and CMS pages from the published site.
I become more cautious when a project expects a large structured content operation, many connected systems or product-like logic. A fast launch is useful only if the platform still fits the work six months later.
Choose Expo when the product is an app
Expo provides a React Native route to applications that run on iOS, Android and the web. It becomes relevant when the mobile experience is the product, not simply another way to read a website.
I use Expo for app work because a shared TypeScript and React foundation can support a coherent product across devices while still allowing platform-specific behaviour. Store distribution, device testing and mobile release operations remain real parts of the job.
Five questions that decide more than a feature list
- Who owns the platform after launch? A designer, marketer, developer or product team will each tolerate different workflows.
- What changes every week? Campaign pages, structured articles, application logic and native releases need different operating models.
- Where does the source of truth live? Decide whether content, customer data and product state belong in the platform or in connected systems.
- What is likely to become complex? Content volume, roles, localisation, integrations and approval can reveal the future constraint.
- What would make leaving expensive? Understand which designs, data and components can be reused if the business outgrows the platform.
A hybrid can be the simpler architecture
Teams sometimes avoid a second platform because one system sounds simpler. In practice, a marketing site and a customer product can have different release rhythms, permissions and technical needs. Keeping those boundaries clear can reduce compromises on both sides.
Do not build a hybrid by default. Use it when there is a real ownership or product boundary, then make navigation, analytics, identity and brand feel coherent across the experience.
.jpg)
