Chrome Extension or Web App First? Founder Decision Tree

The decision tree

Answer three questions in order.

Question 1: Does the value happen on a page the user already has open?

Start here. Your answer tells you if an extension is even on the table.

• No. Users come to your product to do the job: a dashboard, a marketplace, a booking tool, an AI workspace. Build a web app. You don't need an extension.
• Yes. The product changes, reads or adds to another site. It highlights, fills in, enriches, summarises or blocks. Go to question 2.

Question 2: Does it need accounts, saved data across devices, a paid plan or secret API keys?

This tells you if the extension can live on its own.

• No. Everything can live in the browser: settings, a few saved items, page changes. Build a local extension. It's the smallest build of the three.
• Yes. Go to question 3.

Question 3: Can users get value without the extension open?

This tells you which part to build first.

• Yes. They review history, manage a team, see reports or set alerts. Build the web app first, then the extension as a thin layer that sends data to it.
• No. The product only makes sense inside the other site. Build a connected extension with a minimal web app behind it, just for sign up, billing and data. Keep the dashboard tiny.

The three outcomes, by type of idea

Find your type of idea below. Each line gives an example, what to start with and why.

• Changes a page, no account. Example: tab organiser, page highlighter, focus blocker. Start with: local extension. Why: no server, no login, nothing to sync.
• Adds data or AI to another site. Example: LinkedIn profile enricher, Gmail reply assistant. Start with: connected extension plus small web app. Why: value is on the page, but keys, users and billing need a backend.
• Standalone tool with a browser shortcut. Example: price tracker with alerts, research clipper with a library. Start with: web app first, extension second. Why: users spend most of their time on your dashboard.
• Workflow product. Example: CRM, booking system, client portal, SaaS dashboard. Start with: web app only. Why: an extension adds nothing the core product needs.

Criteria that should decide it

The tree covers most ideas. If you're still stuck, compare the two options on these points.

Where the user is when they need you

An extension removes a step. The user doesn't switch tabs, copy text or log in somewhere else. If your whole pitch is "without leaving Gmail", you need an extension. If users plan to sit down and work in your product, a web app is the better home.

Mobile

Chrome extensions are built for desktop Chrome. Google's own help page says that when you find an extension on your phone, you tap "Add to Desktop" and it installs in Chrome on your computer. If your users work on their phones, an extension won't reach them there. A responsive web app works on any device, and it can become a mobile app later.

How fast you need to change things

Under Manifest V3, an extension can't load code from your server. Every change to the extension's code means a new store submission. A web app updates the moment you deploy. In the first weeks, while you're still learning what users want, that speed matters. If you do go with an extension, put the logic that changes often, like prompts, rules and data processing, on your backend. You can then update it without resubmitting.

Who controls your product

A content script depends on the structure of the website it runs on. When LinkedIn or Amazon changes its layout, your feature can break without warning. A web app depends only on your own code. If your idea needs a third party site to stay the same, weigh that risk before you build around it.

How you'll charge

If you sell a subscription, you need a web checkout and a backend that checks each user's plan. A paid extension already includes a small web app.

What you need to show investors

A web app with sign up, a dashboard and real data is easy to demo on any laptop. An extension demo needs Chrome, the extension installed and the right website open. Both can work. Just know which demo you'll give before you pick the build. Halfway through and your idea fits two branches? That's normal. Book a call and we'll look at your idea and tell you which build to start with.

Three examples, decided

Here is how the tree plays out on three real types of idea.

• A focus tool that hides social feeds. It changes pages the user visits and needs no account. Local extension. If it becomes a paid team product, add a web app then.
• An AI assistant that drafts replies in Gmail. The value is inside Gmail, so it needs an extension. But the AI key must never sit in the extension, and users pay monthly. That means a connected extension with a small web app for sign up, billing and the API that calls the model.
• A price tracker that alerts you when a product drops. The user clicks once on the product page, then gets emails for weeks. Most of the value happens off the page. Web app first, with alerts, a watchlist and accounts. Add a "track this" extension button once people use it.

The pattern that works for most startups

When an idea needs a backend, the safest order is usually the one below. The extension then works as a shortcut to your product, not the whole product. If a website changes or a store submission takes time, your business keeps running.

• 1. Web app with auth, database, billing and the core feature.
• 2. Thin extension that signs in with the same account and sends data to the web app.
• 3. More browsers like Edge or Firefox, only once users ask.

How we build it

We build the web app first, at a fixed price from $3,460, with two weeks of fixes and full code ownership. To see how features like payments or auth change the scope, browse our feature cost guides. If you already have a prototype built with an AI tool, read our guides on taking an AI prototype to production.

Mistakes to avoid

These are the traps that make a first build cost more than it should. For more on picking a team for this kind of build, see our guides to hiring an MVP agency.

• Building an extension because it feels smaller. A connected extension is an extension plus a web app. It's rarely the smaller option.
• Putting secret API keys in the extension. Anyone can read its code. Keys belong on your server.
• Storing "paid" status only in the browser. Users can edit local storage. Your backend should decide who has paid.
• Supporting ten websites at launch. Each one is code you'll need to fix when that site changes. Start with one or two.
• Letting someone else own the accounts. Your GitHub repository and your Chrome Web Store developer account should be in your name from day one.

Your next step

You don't need to pick the right stack. You need to know where your users get value. Bring your idea and your launch date. We'll look at your idea and tell you which build to start with. Book a call.

Should my MVP be a Chrome extension or a web app?

Pick an extension if the value happens on a website the user already has open. Pick a web app if users come to your product to do the job, or if most of the value happens outside the browser tab.

Can I start with a web app and add a Chrome extension later?

Yes, and for products with accounts and payments it's usually the safer order. The extension signs in with the same account and talks to the same backend, so you don't build twice.

Does a Chrome extension work on mobile?

Not on a phone. Google's help page shows that from a phone, you can only add an extension to Chrome on your computer. If your users work on their phones, a responsive web app or a mobile app will reach them. An extension won't.

Does a Chrome extension need a backend?

Only if it has user accounts, synced data or paid plans, or if it calls APIs with secret keys. A tool that works fully in the browser can run without one.

Can I update a Chrome extension without going through the store?

Not its code. Manifest V3 blocks remotely hosted code, so each code change is a new submission. Logic that runs on your backend can change any time. That's why it pays to keep the extension thin.