Design and diagrams decision

Paper Sizer

A single competent developer can recreate a useful paper-sizes API and UI in about a week; the site's production polish, scale, and curated content are the main reasons to keep paying.

Visit website
You pay

Not priced

No pricing page we fetched carried a figure, so there is nothing to compare against. The build side is still real.

You’d pay instead

$50one-off24 h to build

$10/mo3 h/mo upkeep

No published price to break even against.

No open-source build does this yet

Nothing published replaces this one, so a replacement starts from an empty file. Here is what it would have to cover.

What a replacement has to do

  • Serve a small JSON dataset of paper sizes + unit conversions via a REST API; a minimal web UI to lookup and convert sizes; single-file data store and search; CI deployment and hosting; tests and basic docs.

What it still won’t have

  • Polish, UX and accessibility modes present on the live site (e.g. Epilepsy Safe Mode, Visually Impaired Mode, Cognitive Disability Mode)
  • A curated, extensive series and article pages
  • A production-grade, traffic-scaled API and SLA
  • Brand trust, analytics, and long-term content maintenance

What remains hard

  • Product polish and ongoing maintenance
Read the build prompt

First-year cost

No published price

Paper Sizer does not publish a price we could read, so there is nothing to compare against. What building costs is below.

Money you would actually spend

Keep paying
—

Subscription price × seats × 12

Build it
—

AI build —APIs + hosting —

Time you would spend

—

—

What you would spend

What we assumed

The verdict above measures whether you could build it. This one is only about money.

Runnable build prompt

Not run yet
Build a minimal paper-sizes service in Node.js (Express) + SQLite and a small React frontend. Core features: import or author a canonical JSON dataset of paper sizes and alternate units; REST endpoints to list sizes, lookup by name/series, and convert units; static single-page UI with search, unit selector, and detail view; basic tests (unit for conversions, API smoke), CI pipeline, and Dockerfile for deployment. Out of scope: multi-tenant billing, analytics dashboard, or advanced accessibility themes beyond basic semantic HTML and keyboard support. Require error handling, input validation, and tests for conversion correctness.
How we checked1 sources · 3/3 runs agreed · evidence score 82

How the score was reached

  • Build verdict base78
  • 3/3 assessment runs agreed+4
  • Evidence score82

The base comes from the verdict. Everything under it is a check that either happened or did not, and each one is a fact frozen in this record rather than a judgement made at render time - so the same evidence always produces the same number.

How scoring works →

Cited sources · 1

Every page the run actually retrieved.

Integrity checks

What held up, and what did not.

✓ 3 independent runs, one answer✓ Citations limited to fetched pages! 1 moat recorded