How verdicts get stamped

Two different questions

Most arguments about rebuilding software collapse two separate questions into one. Can a competent developer working with AI coding tools produce a working version of this? And would doing so be a reasonable decision? Those come apart constantly, which is why this site answers them separately.

• Vibe Score — how hard the software is to build, 0–100, higher means easier. Purely technical. It deliberately ignores whether building it is a good idea.
• Verdict — whether we think you should. One of BUILD IT, BORDERLINE, or JUST PAY. This takes the score and applies everything the score leaves out on purpose: network effects, licensed data, regulatory exposure, an integration ecosystem, what your time is worth.

A product can score 99 and still get JUST PAY. That isn't an inconsistency in the data — it's the entire point of keeping the two numbers apart. Vercel scores 99and is still JUST PAY: it's not hard to approximate, it's a bad thing to try to replace.

How a Vibe Score is produced

1. We break the product into the components its rebuild would actually need — authentication, data storage, integrations, rendering, and so on — from a fixed, shared taxonomy, not invented fresh per app.
2. Each component carries a difficulty rating from that taxonomy. The full list, with every current rating, is on the Vibe Codeability Database rather than repeated here, so there's exactly one place it can go stale.
3. The score is the plain average of those ratings, rounded to the nearest whole number — not weighted toward the harder parts, and nothing adjusted by hand afterward. The number you see is exactly what the components produce.
4. The result is recorded with the date it was checked, so a score can be compared against its own history rather than silently overwritten — see Revisions below.

On who scores: every app and idea on this register has been reasoned through by Dan working with Claude — real research into what the product actually does and what it costs, then a considered judgment call on components and verdict, not a fixed prompt run once and left alone. The score itself is computed from the component list alone; price is never an input to it, so a product's cost can't quietly pull its Vibe Score up or down.

How the verdict follows

Score and price together tell you most of what you need. Neither alone tells you much. A high score with a low price is the easy BUILD IT case. A low score is usually JUST PAY regardless of price — something that's genuinely hard to build stays hard whether the subscription costs $5 or $50. The interesting cases sit in between, and the real threshold isn't numeric.

Checked against the current register: BUILD IT apps average a 95.2 Vibe Score and range from 86 to 99. JUST PAY apps average 78.6 — but range all the way from 49 up to 99. Those ranges overlap substantially. There's no score you can point to and say "below this, it's JUST PAY" — the verdict is a judgment applied on top of the score, not a formula derived from it, and Vercel sitting at a perfect 99 and still landing on JUST PAY is the clearest single example of why.

How the cost-to-build numbers work

Every app page also carries an estimated build cost — AI agent usage plus ongoing hosting. Both are calculated from data already on that page (its component list and effort rating), not hand-entered per app, so they're consistent and they never go stale relative to the verdict above them.

• AI agent cost is estimated from Claude Sonnet 5's published API pricing (as of August 2026) applied to a rough, published range of cumulative tokens for one agentic coding task, scaled by that app's effort rating. If you already pay for an agent subscription — Claude Pro, Claude Max, Cursor, or similar — this cost is already covered; the marginal cost of one more build is $0.
• Hosting cost is a small dollar figure assigned to each component in the Vibe Codeability Database, assuming free-tier hobby-scale usage of ordinary providers. Most BUILD IT apps land at genuinely $0/mo; the number only climbs for components — realtime sync, bank-account aggregation, video infrastructure — where a workable free tier rarely exists.
• These are ballpark ranges for planning, not a bill forecast. Actual cost depends on your agent, your iteration count, and which model you use.

Limitations

These apply to every figure on this site, including any statistic quoted from it elsewhere.

• Scores are judgments, not measurements. No product on this register has actually been rebuilt as a test. A Vibe Score is an informed estimate of difficulty, and estimates of software difficulty are famously optimistic.
• Every score is single-rater. One person and one AI assistant reasoning it through, not independently cross-checked by a second, separate scorer. There's no inter-rater agreement figure to publish — if that changes, this section will say so.
• Category comparisons rest on small samples. Most categories hold a few dozen products each. Differences between categories at that size are easily produced by which products happened to be included, and shouldn't be read as measurements of an industry.
• Prices are list prices. The advertised monthly cost of a typical paid tier, ignoring annual discounts, seat minimums, and negotiated rates. Real spend differs.
• Aggregate cost figures are arithmetic, not a budget. Adding up subscription prices across the register produces a large number, but nobody subscribes to everything. Treat any total as the size of the register, not the size of anyone's bill.
• Coverage is not a sample. Products were chosen because they're recognisable and because the build-versus-buy question is interesting for them. That's a deliberate bias — the register's proportions describe this list, not the SaaS market.
• Scores drift. What's feasible has changed materially over the past two years and will keep changing. Every score carries the date it was checked, and old scores are kept rather than silently replaced.

Revisions

Scores change as the taxonomy improves or a gap gets found. The history is kept so you can see what moved and when, rather than a number changing with no trace of what it used to be.

• 2026-08-14 — HubSpot. Score 95→79 — added a missing integration-ecosystem component; years of third-party partnerships weren't previously measured.
• 2026-08-14 — Webflow. Score 97→71 — added a missing no-code-editor component; its real barrier is the visual-to-code editor, not raw feature count.
• 2026-08-14 — DocuSign. Score 93→75 — a tagging gap, not a new finding: it predated the regulatory-compliance component and was never retroactively tagged like other compliance-heavy apps.

Three shown here as the clearest, most specific examples. The full change history for every app and idea is in the changelog.

Tell us a score is wrong

Disagreement is useful, particularly from people who've actually built the thing in question. If a score or verdict looks off, tell us which product, which direction, and what we've underweighted — a component we missed is the most useful correction there is.

support@canicodethis.com

Reviewed personally, the same as everything else that comes through that address — no formal SLA, but a real component gap is exactly the kind of correction that gets acted on.