Studio 03 · Tom Huang, Open Design: "Stars are not revenue wearing a trench coat"

Studio is Okane Land’s founder interview series: builders making real things with AI, and the real numbers behind them.

When Claude Design launched on April 17, Tom Huang’s team was building something else: an instant-messaging tool for AI-native teams. They shelved it. Eleven days later, on April 28, they shipped Open Design, an open-source, local-first alternative that routes through whatever coding agent you already pay for. The first version was one person, the CEO, for two days, plus a final twenty-four hours of debugging. Roughly 18,700 lines. The bill was a coding-agent subscription, about $200.

What happened next is the part worth studying. Open Design has crossed a million installs against 77,000 GitHub stars, a ten-to-one ratio that runs the usual funnel backwards, and it did it while charging nothing for the core product. The team is small, ships at a pace that embarrasses companies fifty times its size, and has turned almost the entire daily workload of a midsize engineering team over to AI agents.

This interview is a build manual. Huang lays out the file-first method in specifics, what humans write, what agents write, what gets thrown away, and he is unusually direct about the economics: what it cost, why free was the strategy and not a phase, and where the whole thing would break if one person tried to run it. Open Design is free and Apache-2.0, so there is no MRR chart here. The receipts are build costs, contributor throughput, and an install number that reframes what a GitHub star is actually worth.

A note on independence: we reviewed Open Design before this interview existed, and that review is where the relationship started. It ran with a correction we later published against our own error. Nothing in the arrangement changed the read then, and this interview does not soften it now. The skepticism is on the work, never the people.

The eleven days

Claude Design launched April 17. Open Design went public April 28, eleven days later. Walk me through those eleven days. Who decided to build it? What did the first 48 hours look like? What was the agent doing while the human slept? For a solo builder, how much of that speed came from team size, and how much could one person with an agent reproduce today?

When Claude Design launched, we were working on a different product: an IM tool for AI-native teams.

Our thesis was that tools such as Telegram, Discord, and Slack were designed for human-to-human collaboration. In the future, however, collaboration will happen between humans and humans, humans and agents, and often directly between agents. Could an IM tool designed for human collaboration support those new relationships? We thought probably not, so we wanted to build something specifically for human-agent collaboration.

At the same time, we saw major improvements in multimodal understanding, especially images, and in models’ ability to generate HTML. We discussed the shift extensively, and our CEO decided to build a demo himself.

The first version of Open Design was built by our CEO alone. He produced the initial product in two days, spent the final 24 hours debugging it, and completed a first release of roughly 18,700 lines of code.

The first 48 hours were spent almost entirely on two things: defining contracts and laying the foundation. The human wrote down the decisions that would force a rebuild if they were wrong: the boundary between the local daemon and the file system, the data contract for agent adapters, and the decision to make the design system a file, DESIGN.md, rather than a feature. Those discussions and judgments occupied the daytime.

Implementation belonged to the agent from day one. As soon as one section of the contract was settled, the agent implemented it. While the human slept, the agent handled work that did not deserve human daytime: generating adapters against an agreed contract, laying down test scaffolding, drafting documentation, and producing localized copy. The first task every morning was to review the previous night’s output, discard what failed the bar, merge what passed, and define the next section of the contract.

That speed came from one person building directly with an AI agent, not from adding more people. A solo builder today can genuinely match the construction side of that equation, provided the contracts and validation mechanisms are written into files so the agent can check its own work. What is much harder to match comes after launch: spending the first few dozen hours responding to early users and contributors as a human, at human speed. There is no parallel substitute for that.

The recipe

Turn your actual human-agent division of labor into a recipe someone else can copy. Using features such as HyperFrames or Design System Cards as examples, what does the agent produce independently? What do humans insist on writing themselves? What gets thrown away? If a reader wants to ship at your pace, what should they hand to the agent on day one, and what should they never hand over?

The recipe fits in one sentence: humans write the contracts, agents write the implementation, and validation decides what survives.

Features such as HyperFrames and Design System Cards were produced entirely by agents. It has been a long time since anyone on the team manually wrote code. Virtually all of it, really, 100 percent of it, is written directly by agents. The human reviews the result and then provides the next instruction.

You can read this division of labor directly in the repository. The entry point for any agent, human or machine, is a file called AGENTS.md, and every major directory has its own local version. We do not onboard agents through tribal knowledge passed from person to person. We onboard them through files.

The clearest example is our agent-adapter system. An adapter in Open Design is not a class full of clever logic. It is a pure data object that declares how to communicate with a particular CLI. Detection, launch, and stream parsing are all handled by a shared engine. Humans spent real weeks debating what that contract should look like. Once the contract was settled, integrating a new CLI became a one-file change, the kind of output an agent is especially good at. Give it the CLI documentation and a recorded trace, and it can produce a first draft in an afternoon.

Agents independently produce implementation against established contracts, new runtime definitions, templates and skill variants, localization, test scaffolding, and the first draft of almost everything.

Humans personally own the contracts themselves: the nine-section DESIGN.md schema, the skills protocol, adapter type definitions, review standards, and every security boundary, what the daemon may touch, what the sandbox may render, and what data may leave the local machine.

Humans also cannot outsource their understanding of user needs or their awareness of major technical shifts. They should spend more of their time on two things: talking with users and developing a deep understanding of their needs, and following the latest technology and understanding where the technical frontier is moving. Those two inputs allow a human to form a view of both technology and user demand, and therefore make better decisions when directing an agent.

The part most people miss is validation. Our repository includes replay-based mock CLIs for more than a dozen agents, built from sanitized traces. After writing an adapter, an agent can test it against a “fake Codex” without spending tokens or waiting for a person. An agent that can validate its own work is the difference between fast and chaotic.

On day one, give your agent three things: a written contract, one complete example, and a way to validate the result. Never hand over three things: the contract itself, the security boundary, and taste. Taste is review, and review still belongs to humans.

That is the clearest explanation for our release pace. Version 0.9.0 merged 310 pull requests from 88 contributors in seven days. It was possible because every contributor’s agent read the same contract files as our own agents.

On day one, give your agent a written contract, one complete example, and a way to validate the result. Never hand over the contract itself, the security boundary, and taste.

The bill

What does it cost to build and operate Open Design? Give us a rough breakdown of model and agent subscriptions, website and cloud infrastructure, and any other expenses. If someone wanted to build something at this scale, what would the monthly bill look like, and where would costs suddenly spike?

Building Open Design itself did not cost much. The first version was completed by our CEO alone in two or three days using a coding-agent subscription that cost roughly $200. If you count only the initial build, that subscription was essentially the entire budget. Open Design began as a purely open-source project with no hosted version, so in the first month there were almost no costs beyond that subscription.

For ongoing work, every agent plan we use is on the highest tier. Every one. At our pace, the bottleneck is always judgment and review bandwidth, never model budget. Paying for the best plans has been one of the cheapest decisions we have made.

The prices are public, so readers can do the arithmetic per builder: the cost of a top-tier agent subscription multiplied by the number of builders on the project, plus a hosting bill that is small enough to round off. That is the plain answer to what the monthly bill looks like.

Our costs are concentrated in places most people do not expect. They are not in serving users, because users run their own agents. They are not in routine testing either. Our regression suite replays recorded sessions through mock CLIs across fifteen agents at zero token cost. We use real agents only when they are worth the expense.

We also attack the cost curve inside the product. Version 0.15.0 reduced design-system input tokens by one quarter and cut end-to-end generation time by one fifth. The same change lowered both the user’s bill and our own testing cost.

The real cost spikes come from evaluation. Whenever we need to align behavior across more than twenty supported CLIs, we must use real agents, because consistency is the one thing a mock cannot prove.

Ongoing operations also create labor costs: community work, publishing on X, and product planning. The size of that cost depends on how the work is organized and how much is automated. If product planning, publishing, and community operations can be automated further, the cost can continue to fall.

We later added a cloud service, but the infrastructure cost remains relatively low. The token-based service exists mainly so people without a coding agent or a BYOK setup can use the product smoothly, not so that we can profit from a model markup. We do not add a spread; the associated cost is covered by what the user pays.

So here is a budget recommendation without attaching our invoices: spend money on the best agent plans, and make validation free as early as possible with mocks, replays, and golden files. Otherwise, the meter will eat you. Before accepting inference as a cost of serving users, ask whether your architecture can turn it into the user’s asset rather than your liability. That question is worth more than any isolated budget number.

What a star is worth

Everyone can see the star count, but no one can see the funnel. What did tens of thousands of stars actually turn into: installs, weekly active users, or cloud registrations? For a builder considering open source as a distribution strategy, what can stars genuinely buy, and what do people mistakenly think they buy?

Start with one number we can disclose, because it overturns the premise of the question: 77,000 stars and more than one million installs.

Most people imagine a funnel in which stars narrow down into users. Ours runs in reverse. Installs are an order of magnitude higher than stars. Most of our users have never starred the repository; many have never visited the repository page. They arrived through package managers, word of mouth, a colleague’s recommendation, or an AI assistant naming the tool when asked for a recommendation.

We are keeping weekly-active and cloud-registration numbers private for now. They are early and fluctuate week to week. Rather than narrate every movement, we would rather disclose them formally when the time is right. What we can say is that the real drop-off happens between install and weekly use. That is where the real work is, not at the star end of the funnel.

In our experience, stars buy four things.

First, credibility, and credibility converts into other assets. Journalists answer your email. Contributors submit a first pull request. Enterprise evaluators do not immediately close the tab.

Second, contributors. This is the conversion path almost no one measures. Version 0.9.0 alone merged work from 88 contributors, and a meaningful share of them came through the repository’s star-driven visibility.

Third, search and AI visibility. A highly starred repository gets cited, linked, and named when people ask models for tool recommendations. That is distribution that compounds while you sleep.

Fourth, option value. Stars represent an audience you can reach again for free, because every release can be broadcast to them.

What people mistakenly believe stars buy is users. A star is fundamentally a socially visible bookmark. It costs one click, and its relevance may expire immediately. Statistically, many people who star a project during its breakout week never run the product.

Our numbers prove the point in reverse: the product has traveled ten times farther than its star count because installs move through channels that stars never reach. If your business model needs active users, the real work begins after the star: first-run experience, documentation, and a reason for someone to return on Tuesday.

Our advice to a builder considering open source as distribution is this: if contributors, credibility, and default-option status are assets your strategy can monetize, as with our Cloud and team plans layered on top of a permanently free local product, then do it. But do not imagine that stars are revenue wearing a trench coat. Stars are attention. The product must convert that attention, and the conversion rate is never printed on the star page.

Do not imagine stars are revenue wearing a trench coat. Stars are attention. The conversion rate is never printed on the star page.

Giving it away

You chose BYOK and local-first, allowing users to run the agent subscriptions they already pay for instead of selling them another subscription. That means giving up the easiest revenue. For a small team, when is “giving the product away” the right choice, and when is it a trap? What role does Open Design Cloud play, and what has early monetization looked like?

Start by calculating the real cost of charging a subscription. Every closed-source design tool in this category charges per seat: one Pro plan here, one Team plan there. But our target user already pays for agents. They have a Claude Code plan, a Codex plan, or a Cursor plan. Requiring another subscription before they can even evaluate Open Design is not a revenue strategy. It is putting a security guard at the front door.

BYOK removes that guard. Any of the 22 CLIs we support, or any OpenAI-compatible endpoint, can unlock Open Design. The subscription the user already owns becomes our distribution channel.

When is giving the product away the right choice? Three conditions must all be true.

First, marginal cost must be close to zero. With BYOK, inference runs on the user’s own plan, so free users do not consume our margin.

Second, the free product must create an asset that compounds. Every DESIGN.md written, every skill shared, and every plugin published makes the ecosystem more valuable. That asset belongs to the commons, not to our income statement.

Third, there must be a natural upgrade moment that does not have to be manufactured.

If any of those conditions reverses, free becomes a trap: free usage burns your own compute; you open-source your only differentiation and have nothing left to sell; or the upgrade path works only by crippling the free version.

Open Design Cloud is our answer to the third condition. It is a convenience layer, not a paywall. Some people have never configured a CLI and never want to. Cloud gives them one login, more than twenty flagship models, and usage-based token billing. No local-product feature is held hostage by it.

The next layer is more interesting. We are testing a team workspace that provides shared brand assets, project drafts, and team comments on top of the same open foundation. Individuals who bring their own key remain free forever. Teams that want a hosted shared space receive something genuinely worth paying for. The product currently generates stable positive cash flow.

The summary is that we gave up the easiest revenue in exchange for the hardest asset to earn: becoming the default option in agent-native design. A subscription model can be copied next quarter. Default status is much stickier.

Alternative, not copy

You turned Open Design into an open-source alternative to a frontier-lab product and reached a high level of completeness very quickly. Technically and ethically, where is the line between a clean-room alternative and a copy? What makes an alternative legitimate rather than derivative? How do you think about building in a category Anthropic defined just eleven days earlier?

A copy reproduces the other product exactly. The line between an alternative and a copy is not speed. It is what you took.

A category is not property. “Agents should be able to do design work” is an idea, and bringing an idea into the world is the point of launching a product. Implementations are property: code, assets, weights, and internal architecture. We took the former and never touched the latter. Claude Design is closed source; there was nothing for us to copy even if we had wanted to. We could see only what any user could see: a public product’s external behavior. Studying public behavior is called competitive analysis in every industry on earth.

The strongest technical evidence that we are an alternative rather than a copy is that we keep disagreeing with the original. A derivative cannot do that; it inherits the original’s decisions. At almost every fork, our decisions went in the opposite direction.

Claude Design runs in their cloud. Open Design runs on your machine, with a local daemon managing your files. Claude Design charges by subscription tier. We use BYOK and support 22 agent CLIs plus any OpenAI-compatible endpoint, because the agent you already pay for should be the engine.

Their design system lives inside their product. Ours is a nine-section DESIGN.md in your repository, compatible with any agent, including theirs. The entire project is licensed under Apache 2.0. Tracing someone else’s work cannot produce an architecture that points in the opposite direction.

That is the central distinction between Open Design and a copy: we do not force users into our subscription. We offer choices. Users can select different models and reuse their existing BYOK and CLI setup. We believe design capability should not be tied to one model company. It should belong to any person and any company. People should be free to create with different models and coding agents instead of being locked to one.

Ethically, we ask ourselves three questions. First, did we take an implementation we had no right to take? No, because there was no implementation available to take. Second, did we mislead anyone about the source of the category? No. The first paragraph of our launch post named Claude Design. We exist because it existed, and we acknowledged that from day one. Third, does our existence make the category better, or merely cheaper? We believe an open, local, model-agnostic implementation turns agent-native design into something the entire ecosystem can own rather than something rented from one vendor. That is a contribution, not a discount.

As for building in a category a frontier lab defined eleven days earlier: that is exactly why open source exists. Closed products prove demand; open implementations turn demand into infrastructure. Frontier labs open categories; communities make those categories permanent.

Anthropic proved that design can be agent-native. Our wager is that agent-native design should also be user-owned. Those two wagers differ enough that either side can fail independently without taking the other down. That is the real test of an alternative: it can fail in its own way.

Could one person run it?

Relative to the size of its core team, Open Design is unusually large: 77,000 stars, thousands of issues, and nearly a hundred contributors involved in each release cycle. Run a thought experiment. Could one person operate it today? What would break first, issue triage, community, or release cadence? Where do agents genuinely replace headcount, and where do they merely assist?

One person can operate Open Design, provided the work is turned into automated skills or plugins and those systems run at the right time. One person can keep Open Design building and operating, although some parts will slow down depending on how that person understands and prioritizes the work.

Let us actually run the experiment. On day one, the solo operator takes over the repository. More survives than most people expect because the project’s operational knowledge lives in files rather than in people’s heads. Every directory has its own AGENTS.md, so any agent, including a contributor’s agent, can onboard itself.

The mock-CLI test system can replay recorded sessions from fifteen agents at zero token cost, so regression testing does not require a separate QA team. Adapters are single-file data objects, so a significant share of incoming pull requests can be reviewed mechanically against a contract. One person plus agents can keep the software alive: merging routine fixes, shipping releases, and updating an adapter when a CLI changes its stream format.

Our community pull-request workflow is one example. An internal automated looper evaluates whether a community PR is necessary. If it is necessary, the system moves it forward quickly toward merge. If it is unnecessary or problematic, the system opens a discussion with the author. Those steps are automated. That helps us involve nearly a hundred contributors in each release and use the community’s combined effort to build Open Design quickly. On average, we can merge a pull request in less than half a day.

Agents genuinely replace headcount in code production, localization, test scaffolding, issue triage, documentation, and regression testing, almost the entire daily workload of what used to be a midsize team. They only assist with contract design, security boundaries, community judgment, and taste. Those are exactly the four things we never hand to agents, which suggests the boundary is real rather than habitual.

The arithmetic for a solo builder is that agents allow one person to operate something that would have required an eight-to-ten-person team a few years ago, but only if the project is designed that way from day one. Contracts must live in files. Validation must be runnable by agents. The architecture must make most contributions mechanically verifiable.

That does not mean every part can maintain the same speed under one-person operation. At scale, community response and decisions that require human accountability remain bottlenecks. An agent can answer questions and perform triage, but it cannot decide whose pull request deserves attention, which direction should receive support, or accept responsibility for saying, “This release will not embarrass us.” Agents reduce the minimum human headcount, but they do not reduce it to zero.

The ByteDance lessons

Before becoming a founder, you worked on agent platforms at ByteDance, including Coze and Aily. What did building agents inside a large company teach you that solo builders most often get wrong? Conversely, what did the large-company approach itself get wrong, what did you later have to deliberately unlearn?

What large-company agent work taught me comes down to an unfashionable word: reliability.

On a platform at that scale, an agent feature cannot ship simply because the demo works. It must survive evaluation, regression testing, and replay against thousands of recorded sessions. At that scale, edge cases are not rare events. They are an ordinary Tuesday.

This is where solo builders most often go wrong. They treat validation as something to add after product-market fit, when validation is actually what makes iteration speed possible. The mock-CLI system in the Open Design repository, which replays agent sessions at zero token cost, is the most “big company” part of what we built, and I make no apology for it.

The other lesson is protocol thinking. When many teams integrate with your platform, you learn quickly that the interface itself is the product. A sloppy contract creates a debt that costs a hundred times more later. That is why our agent adapters are data rather than code, and why humans on the team spend their time debating contracts while agents write the implementation.

What I had to unlearn is harder to admit. A large platform is a gravity well. Its instinct is to own everything: the model, the runtime, the data, and the user’s entire workflow. Ownership is how platforms measure themselves.

It took me time to see that what feels like ambition from the inside looks like a cage from the outside. Open Design is largely a list of things we decided not to own: not the model (BYOK), not the runtime (your machine), not the files (your repository), and not even the agent (bring whichever one you already pay for).

The second thing I had to unlearn was our relationship with time. In a large company, a quarter is the smallest unit of ambition, and consensus is a tax on every decision. The eleven-day sprint felt almost like an exorcism. Once agents took over production, many of the old reasons why work “had to be slow” quietly expired. The remaining bottleneck was how quickly a small group of people could persuade one another. When the group is small enough, that can happen very quickly.

A large platform is a gravity well. What feels like ambition from the inside looks like a cage from the outside. Open Design is largely a list of things we decided not to own.

Vibe coding vs vibe design

Open Design argues that the important distinction between vibe coding and vibe design is not simply whether a chat window can generate a mockup, but what you actually own after the demo ends. Why is generating a design image not enough? By month six of a real project, what has “owning the files” changed? How should someone currently satisfied with chat-generated mockups change their workflow this week?

There is a simple test: close the chat tab and try to use what you just made.

A mockup inside a chat window is essentially a screenshot of a decision. It looks like progress, but you cannot diff it, version it, or hand it to a teammate. Next week, you must prompt from scratch just to return to the point you already reached today. The demo was the entire output, and the demo is over.

Owning files reverses that situation. Everything Open Design produces is real CSS, real fonts, and real components stored in your own file system.

The design system is itself a file: a DESIGN.md with nine sections that encode color, typography, spacing, components, and even anti-patterns into a brand contract any coding agent can understand, the same file-as-contract idea that runs through the vibe coding stack. That file is the difference between “generate something attractive” and “generate the next thing that belongs to this brand.”

By month six, the compounding effect becomes overwhelming. Your Git history is your design history. When the brand evolves, you update one contract file and regenerate instead of explaining the brand to a chatbot for the hundredth time.

When something is wrong, you can click the element and make a surgical edit rather than watching a full regeneration destroy the 90 percent that was already correct. Because files are the shared substrate, collaboration happens naturally. Team members can share the same DESIGN.md through Git while each uses a different agent, whether Codex or Claude Code, to drive it.

We are now testing a team workspace that extends this foundation by allowing brand assets, project drafts, and team comments to be shared directly inside Open Design.

The change you can make this week is simple: stop treating the chat window as your workspace. Create a repository, put a DESIGN.md inside it, and have the agent write files there.

Vibe coding optimizes for the instant when a demo impresses someone. Vibe design optimizes for the following morning, when the project becomes real and you must live with what you own. Whether the method itself pays, beyond the demo, is its own question with its own receipts.

The weekend build

A reader finishes this interview tomorrow morning with a Claude Code subscription, a free weekend, and an urge to build “something people will star.” From a team that ships at your pace, what should they copy from your way of working? What should they absolutely not copy? If you were starting from zero today, alone, what would you do first?

Start with one essential principle: once you have an idea, use an agent to build the smallest viable MVP and put it in the market for validation instead of leaving it as a thought experiment.

More specifically, copy three things. All three fit inside one weekend.

First, write the contract before the code. Put an AGENTS.md at the root of the empty repository. Explain what the project is, where the boundaries are, and how a change is validated. It takes thirty minutes, but every hour the agent works after that compounds instead of wandering.

Second, before assigning work, give the agent a way to check itself: one test command, one replayable example, and one golden file. The biggest dividing line between teams that ship with agents and teams that are dragged down by them is whether validation is the agent’s responsibility or the human bottleneck.

Third, copy our division of labor: humans own the contracts, boundaries, and taste; agents own implementation and first drafts. For a weekend project, that means spending Saturday morning thinking and writing natural language rather than TypeScript. It feels wrong, and it is right.

Do not copy our pace. The eleven-day sprint worked because a category had just been proven and the window was open. That is a story about timing, not a work ethic worth imitating. Sprinting that way without the same reason is the standard way a weekend project dies on Monday.

Do not copy our scope either. Our starting point sat at the intersection of things we had worked on for years. Your intersection will be different. Copying our product instead of our method would turn you into the kind of derivative we refused to become.

If we were starting alone today, we would look for the gap discussed throughout this interview: a closed product that has just proven demand but does not let users own what it gives them. Pick one, and pick a small one. Do not build another design tool; that position is occupied, and it is occupied by us.

The transferable recipe is this: find a demo everyone loves but cannot keep, and build a version the user can truly own. Then do the unglamorous work. The stars everyone sees were not earned during the weekend of construction. They were earned in the months afterward by responding to issues quickly, publicly, and like a human. An agent cannot fully substitute for that part, and that part is the moat.

Find a demo everyone loves but cannot keep, and build a version the user can truly own. Then do the unglamorous work.

Tom Huang is @tuturetom on X, and this interview was coordinated with Koki.