What this actually costs you

Six realistic ways people actually build things, each priced with real, current API rates (Claude Sonnet 5: $2/$10 per million input/output tokens; Qwen3.7: $2.50-7.50/MTok depending on tier; Kimi-K3: $3/$15 per MTok — all current list prices as of this writing). The token counts behind every dollar figure are the same real, measured data in the receipts — nothing here is invented for effect. Where we scale a measured result up to a more realistic project size, we say so plainly. The underlying builds were measured against rebar-ui v0.1.0 (2026-08-29/30) — only the API prices above are kept current.

Everything else on this page compares token costs. This one compares the actual decision a small team faces: hire developers to build an internal app, or build it with an AI coding agent and rebar-ui. Worked example — a company timesheet tool, seven screens: Dashboard, Time Entry, Manager Approvals, Reports, Project/Client Admin, User Settings, Leave Requests. Stated assumptions throughout, so you can plug in your own numbers if ours don't match your situation:

Developer rate: $100/hr — a round figure inside the real market range for a mid-level full-stack contractor ($81-135/hr, per current rate-tracking sites), used for both sides of this comparison, including the human time an AI-assisted build still needs.

Revisions: 6 rounds of stakeholder feedback per screen before the team is happy shipping it — a deliberately ordinary number for getting a first version of an internal tool out the door, not the 13-17-round figure used elsewhere on this page for "how long until a migration pays for itself" (a different question this scenario doesn't need to answer, since a timesheet tool is exactly the kind of internal app nobody re-skins — see scenario 5).

The $1.38 API cost is the sliver at the very bottom of the right-hand bar — too thin to label. Almost the entire AI-assisted cost is human oversight time, not tokens; it's still roughly a tenth the size of the traditional bar next to it.

What this doesn't include: project management overhead, code review, and QA time are folded into the day estimates above, not added separately — a real team with more process overhead would widen this gap further, not close it. Per-screen token costs are the same real, measured Composite-tier numbers used throughout this page (see the tiers section), scaled to 7 screens × 6 rounds — a stated scaling, not a new measurement. Swap in your own day rate, revision count, or screen count; the model is simple enough to redo by hand.

The most direct comparison: build the same app with Claude, one condition hand-coded in antd, the other headless in rebar-ui and migrated to antd once revisions settle down. Real, measured token counts through each tier's actual crossover round, priced at Claude's real rates.

These are small dollar amounts because our test spec is small — the point is the percentage, which holds regardless of how big your real project is. Past the break-even round, every additional round of revisions just widens the gap.

We haven't run the full round-by-round migration experiment on Qwen or Kimi yet — only Claude, so far. What we do have is the real one-shot build cost on both, and it tells you a lot on its own:

On Claude, rebar-ui's one-shot saving is only ~3%, which is why migrating away from it takes 13+ rounds to earn back. On Qwen and Kimi, the one-shot saving alone is already bigger than Claude's entire 13-17-round gap — so if a similar per-round pattern holds on these models (not yet measured directly), migrating away from rebar-ui would likely pay for itself almost immediately, not after over a dozen rounds. That's a reasoned inference from real numbers, not a second measurement — flagged as exactly that.

Plenty of real software is never going to get a design pass — an internal ops dashboard, an admin panel, a tool three people on your team use. If you're never migrating away from rebar-ui, there's no migration bill to earn back — it's just cheaper, every single round, from day one. Modeled on our Composite-tier spec's real one-shot cost and real measured per-round revision cost, extended out (Claude pricing):

This is the strongest case for rebar-ui, and the simplest: skip the "will it earn back the migration cost" question entirely by never paying that cost. Real teams building internal tools this way, at real scale (many tools, many teams), see this saving multiply directly.

A common real job: recreate a screen from an existing enterprise platform you don't own the code for — a dense, multi-panel record page in the style of a Salesforce-class CRM — working from what's on screen, the same way our real image-to-code experiment works from a reference screenshot rather than a written spec. We haven't rebuilt an actual named product (nor would we claim to) — this scales our real, measured Complex-tier result by a stated 3x, a conservative estimate of how much denser a real enterprise record screen is than our test spec, using an unnamed frontier model priced at Claude's real rates:

The percentage doesn't change with density in this simple model — real screens won't scale perfectly linearly, but the direction (rebar-ui cheaper, reading a screenshot or reading a spec) is the same effect measured twice, not assumed once.