Summarize with AI
An open source startup website has to do one thing most open source homepages skip: tell the developer who will self-host apart from the team that will pay, and send each one to a different door. The paid path, usually your Cloud product, should be the main button in the hero, and GitHub stars should sit nearby as proof rather than as the goal.
This matters more for an AI startup than for most. Your repo is the reason strangers trust you, but it is also the reason your homepage is full of people who will never pay, and right now the page cannot tell them apart. If you cannot say which visitors were meant to buy, you cannot say whether the site works.
Star on GitHub, Read the docs, Try Cloud: three buttons, no path
Picture an open source agent framework, used here as an example. The repo has 18,000 stars. The homepage headline reads The open source framework for production agents. Under it sit three buttons of the same size and the same weight: Star on GitHub, with a live count of 18.2k, then Read the docs, then Try Cloud.
Below the buttons is a code block with a copy icon: pip install, then the package name. Scroll down and you get a grid of integrations, a contributor wall of 240 avatars, a Discord badge showing members online, and a quote from a well known engineer about the API design. The word pricing appears once, in the footer. The word team does not appear at all.
Cloud signups run at about 40 a week. The founder can see the number in the admin panel. He cannot tell you how many of those 40 came from someone who was ever going to pay, or how many paying teams looked at the hero, read Star on GitHub as the main action, and left to clone the repo instead.
Two visitors arrive, and only one of them has a budget
The first visitor is a builder. She found the repo on Hacker News or in a thread, she wants to read the source, and she will run it on her own laptop tonight. She is the reason the project exists and she will never pay you. That is fine. Her star and her pull request are worth a lot, just not in revenue.
The second visitor is a team lead at a company with forty engineers. He was sent the link by one of them. He does not want to run anything. He wants to know who handles upgrades, whether there is single sign on, where the data lives, and who picks up the phone when the agents stop running at two in the morning. He is the only one of the two who can sign a contract.
The three equal buttons treat these people as one person. The builder is served well, because every button is a builder button. The team lead has to work out on his own that Try Cloud is the thing meant for him, and nothing on the page tells him what Cloud adds beyond the free version. This is the same gap Dualite had with two kinds of visitor. On the Dualite case study, its CTO says first-time visitors from the non-technical crowd were not grasping who Dualite was fast enough, so the site had to do that work before anyone opened the product. Dualite reached 100,000+ users in seven months after that work.
What the founder does with a star count
He checks the star history graph before he checks his email. When the repo crossed 10,000 he posted a screenshot. The monthly investor update opens with stars, then Discord members, then downloads, and Cloud revenue sits in the fourth paragraph.
In a second meeting, an investor asks the kind of question that comes up in this situation: how many of these stars work at a company that could pay you? He answers with the contributor count, which is a different number. Later he asks his cofounder to add a Talk to us link to the footer. Two weeks after that he asks for a fourth hero button, Book a demo. The page gets busier and the 40 a week does not move.
None of this is careless. Stars are the one number that goes up every day without him doing anything, so it is the number he reports. The trouble is that he knows which of his visitors are buyers, because he has met them on calls. The homepage has not.
What 18,000 stars are worth when you raise
Stars do not show up in revenue, and revenue is what the next round is priced on. Carta's Q1 2026 data puts the Series A bar for AI startups at around 3.5 million in ARR, up from roughly one million three years earlier. A repo with a large following and a thin Cloud business has to cross that bar with the Cloud business alone.
The free version makes the gap wider, not smaller. Measured on SaaS and product-led companies, freemium products convert free users to paid at a median of 2 to 5 percent. An open source project is a freemium product where the free tier is the whole product, runs on the user's own servers and never sends you a signal. Every builder who self-hosts is, by design, one more user you will not convert. If the homepage pushes paying teams down the same path, you are adding buyers to the pile that was never going to pay.
There is a cost on the Cloud side too. If your Cloud product runs agents for customers, you pay for inference on every run, and AI product builders average around 52 percent gross margin against 70 to 80 percent for traditional software. Free Cloud users who were really builders testing the hosted version are the most expensive visitors you have.
Why Try Cloud should be the main button, even if stars drop
The usual advice for open source sites is to lead with the community. Put the star count in the hero, make the GitHub button big, show the contributor wall early, and let the paid product follow later. That advice is right for a project. It is wrong for a company that needs a Cloud business to raise.
Here is the trade, said plainly. If Try Cloud becomes the one filled button and Star on GitHub becomes a small badge in the nav, some builders will not star the repo who would have. Your star graph will grow a bit slower. Accept that. Builders find the repo through the repo, through a link in a thread or a package registry. Paying teams find you through the homepage. The hero is the one place the second group looks, so it should be built for them.
Supabase is a good example of the pattern. On its homepage the star count sits as a small number in the top nav. The hero has one filled button, Start your project, which opens the hosted product, and a quieter Request a demo next to it. Self-hosting is covered in the docs, which explain that it suits people who need full control of their data or have compliance rules. Nobody who wants to self-host has trouble finding it.
The self-host or Cloud block that sorts people for you
The single most useful section on an open core homepage is a plain comparison of the two ways to run the product. It lets each visitor pick their door without a call, and it tells the team lead in one glance what he is paying for.
For the agent framework, it would be a table with two columns, Self-host and Cloud, and rows that answer the team lead's questions. Who runs it: you, or us. Upgrades: you pull new releases, or they ship to you. Single sign on and audit logs: not included, or included. Run history: whatever your own disk holds, or kept and searchable for you. Support: GitHub issues, or a named channel with a response time. Price: free, or the plan names with a link to pricing. The last row matters. A comparison that hides the price reads as a sales trap.
Be honest in the Self-host column. PostHog's self-host page opens with the question should I use self-hosted PostHog or PostHog Cloud, and says plainly that self-hosted deployments are officially unsupported. That candour sells Cloud better than any feature list, because the team lead now knows exactly what he would be taking on.
Five changes you can make this week
- Name the noun in the first sentence of the hero. Not a framework for the future of agents, but an open source framework for running agents in production, with a hosted Cloud for teams.
- Make one button filled. Try Cloud, or better, a label that says what happens next, like Start a Cloud project. Move Star on GitHub to a small badge in the top nav with the count beside it. Put Read the docs in the nav too.
- Add the self-host or Cloud comparison block directly below the hero, with six rows the team lead cares about and a price row.
- Move the contributor wall, the Discord badge and the integrations grid lower, under a heading like Built in the open. They are proof for both visitors, not a call to action.
- Count the two visitors separately. Track clicks on the GitHub badge, the docs link and the Cloud button as three events, and tag every Cloud signup with whether it came from a company email domain. In a month you will know which of your 40 a week were the team lead.
If your docs live on the same site as your marketing pages, check that the docs nav does not take over the homepage nav. Docs often belong on their own subdomain or framework, which is part of the choice covered in Webflow vs Next.js for tech companies. And if your Cloud product runs agents, the hero should show one run with its steps, the way agentic AI landing pages do, rather than a code block alone.
How Studio Maydit approaches it
Your repo explains the project to people who already read source code. Your homepage has to explain the company to the team lead who does not, and you are the one person who cannot read it the way they do, because you know exactly what Cloud adds. Studio Maydit designs websites for AI founders in Framer, Webflow and custom code, and on Dualite we built the site so a first-time visitor understood the company before opening the product, then stayed on for the product itself. If you want to compare studios that work on developer tools first, our ranking of landing page agencies for AI devtools is a fair start. If you would rather talk through your own hero and who it is really for, book a 30 minute call.
