Summarize with AI
A Chrome extension landing page has to show the extension inside the tool it runs in. If your AI assistant works in Gmail, the hero should be a Gmail inbox at real size with your one button in it, and the main button should say Add to Chrome. The visitor is not asking what your product looks like. They are asking whether it will fit into the place where they already spend the day.
This matters more for an AI tool than for most software, because an extension or a Slack app has almost no screen of its own: a button, a side panel, a reply in a thread. You know exactly where it appears and what it does there. A stranger on your homepage does not, and if the page shows them a product that does not exist, they cannot picture the one that does.
The dark dashboard the extension never opens
Picture an AI email assistant built as a Chrome extension. Inside Gmail it does two things. It adds a small button labelled Draft reply next to Gmail's own Reply button. And it opens a 320 pixel side panel on the right that lists the three emails in your inbox that it thinks need an answer today.
Now picture its homepage. The headline says Your inbox, finally on autopilot. The hero image is a dark app window with a left menu reading Home, Insights, Automations and Settings, and four tiles across the top: Emails handled 1,284, Hours saved 37, Response time 2h 14m, Tone score 92. None of these screens exist. The real product has a settings page with a tone slider and nothing else. It was mocked up because a Gmail screenshot looked plain.
The main button says Get started free. It opens the Chrome Web Store listing, which has two screenshots. The first is the same dark window. The second is the settings page. The visitor who clicks through still has not seen the product in Gmail, and the install dialog is the next thing that happens.
What the visitor is checking is fit, not features
Most landing page advice says show the product. For an extension that advice is half right. Your product is a button and a panel. The rest of the screen belongs to Gmail, or Slack, or Notion, and that rest is the most persuasive part of the picture.
Someone who lives in Gmail all day knows its layout by heart: the red compose button, the grey toolbar, the row of tabs. When they see that layout on your homepage with one new element in it, they understand the whole product in a glance. It does this, here, and nothing else moves. A dark dashboard tells them to open a new tab and learn a new tool, the exact cost your extension exists to remove.
So here is the claim worth arguing with: on an extension site, the host tool should take up more of the hero than your own interface. Keep the familiar parts at their real size and colour. Mark your button with one label or a thin outline. Do not redraw the host app in your brand colours. A visitor trusts the screen they recognise.
The founder who can see the button and the visitor who cannot
The founder opens Gmail forty times a day with his own extension installed, so the Draft reply button is simply there. When he reads Your inbox, finally on autopilot, his head fills in the button, the panel and the three emails.
The signs that it is not working show up in what he does next. He records a two minute screen video for every prospect who asks how it works. He adds a line to the hero, Works with Gmail, and then a Gmail logo next to it. He changes the headline twice in a month. Each fix adds a claim, never the picture the visitor needed: their own inbox with one new button.
Add to Chrome is a bigger ask than Sign up
A sign up button asks for an email address. An install button asks for access to the visitor's browser and, often, to their inbox. The page should treat them differently.
Name the browser and the action on the button: Add to Chrome, or Add to Slack. Get started free hides the fact that the next screen is a store, and people who did not expect a store often close it. Under the button, put one short line about what the extension reads, in plain words. For the email assistant that might be: Reads the email you have open. Never sends anything without your click.
If part of your product needs a web account too, decide which comes first and make that the only main button. Our post on choosing between sign up and book a demo uses a ten minute test that works here as well. If a stranger can get one good draft in Gmail within ten minutes of installing, the install is the main action and the account can wait.
The permission dialog is part of your landing page
The visitor reads your page, clicks the button, and Chrome shows a dialog listing what the extension can do. You did not write that dialog, but it is the last thing they read before deciding. Chrome writes those warnings from the permissions your extension asks for. Asking for the tabs permission, for example, makes Chrome show Read your browsing history on install. For an email tool, that line arrives with no explanation.
Two facts from Chrome's own documentation change how the page should be built. The activeTab permission displays no warning message during installation, so an extension that only acts when clicked can often ask for less. And when an update adds a permission that triggers a warning, the extension is disabled until the user accepts it. A wide permission is a cost you pay at install and again at every update.
So the landing page should answer the dialog before it appears. Add a short section near the button that lists each permission, what it lets the extension do, and what it does not do. Write it in the visitor's words, not the manifest's.
The store listing is your second landing page
Many installs never touch your homepage. People find you in the Chrome Web Store and decide there. Chrome gives you a summary of 132 characters or less and asks for at least one and preferably five screenshots at 1280x800 or 640x400 pixels. Two screenshots of a dashboard that does not exist waste most of that space.
Use all five, and give each one a single job. The first shows Gmail with your button marked. The second shows the side panel open with three real looking emails. The third shows a finished draft in the Gmail reply box. The fourth shows the settings page. The fifth shows the permission list in plain words. Write the summary as a sentence a Gmail user would say: Drafts replies to your emails inside Gmail, one click per email.
The SATHI case study shows the same problem from the Shopify side: an affiliate platform for Shopify brands, launching into an app store holding thousands of affiliate tools that looked alike, with a team that wanted its site to stand out when someone pasted three links into Slack. When every listing looks the same, the one that shows the real product in its real place is the one people can judge.
What changes when the tool lives in Slack
A Slack app has the same problem with different details. The useful part is a message from your app in a channel, a slash command or a short form. The person reading the page is often not the only person deciding, because a workspace admin may have to approve the install for the whole team.
Slack is strict about this. Its Marketplace guidelines ask for listing images at 1600 by 1000 pixels and say to show your app in the context of Slack, not other tools you connect to. They ask for a landing page that explains how the app works in Slack, gives a clear path to installing it and links to your privacy policy. They also ask apps to request the fewest scopes they need, and broad access to message history gets a closer review.
So the hero for a Slack app should be a channel, at real size, with your app's reply in the thread. Then add a short section written for the admin: what the app can read, where data goes, and who in the workspace can remove it.
Rebuild the hero around the host app this week
None of this needs a redesign.
- Open the host app on a clean account with realistic content. Take one screenshot at the size a laptop shows it, with your button or message visible and nothing else changed.
- Put that screenshot in the hero. Mark your part with one label, such as Draft reply, added by the extension. Cut the dashboard mockup.
- Rename the main button to Add to Chrome or Add to Slack. Put one plain line under it about what the tool reads and what it never does.
- Add a permissions section near the button, one row per permission. If a permission is hard to explain, ask your engineer whether the product needs it.
- Replace every store screenshot with a view of the product in the host app. Use all five slots in Chrome and the 1600 by 1000 size in Slack.
- Ask three people who have never seen the product to look at the hero for five seconds, then ask where the tool shows up. If they cannot point to the place, change the screenshot, not the headline.
The cost of skipping this is easy to state. Every visitor was paid for with ads, content or your own time. Most product led products only activate 20 to 40 percent of the people who sign up, a figure measured on SaaS companies. An extension loses people before that count even starts, at the store page and the install dialog. A page that shows the host app moves more of the people you already paid for to the point where they can see a good draft.
Copilots and extensions share this problem, since both live inside someone else's screen, so the studios in our list of landing page design agencies for AI copilots are a fair place to start if you want help.
Studio Maydit is a web and product design studio for AI founders in the US, UK and Europe, and this kind of page is where the founder knows the product best and shows it least. You have watched your button work inside Gmail or Slack a thousand times, so the dark dashboard looks like progress to you, and to a stranger it looks like a tool they would have to learn. We work in fixed scope over three to four weeks, building in Framer, Webflow or custom code, and the job on a page like this is legibility: one real screen of the host app, a button that names the store, and a permissions section a careful buyer can read before the dialog. If your extension or Slack app is better in use than it looks on your site, book a 30 minute call.
