Security and privacy decision

GhostSIM

A capable developer can build a single-user or small-scale replacement that provisions numbers and surfaces incoming codes, but reproducing the vendor's global number inventory, app-store apps, and refund/scale polish would be operationally heavy and costly to match.

Visit website

Built by Semih, who ships 3 products in this index

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

$100one-off42 h to build

$50/mo6 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

  • Provision a virtual phone number, receive an inbound SMS for that number, and display the verification code to the user.

What it still won’t have

  • Global number inventory at scale (100+ countries)
  • Automated refund and credit handling tuned to provider SLAs
  • App-store presence and mobile apps (App Store / Google Play)
  • Built-in referral/bonus-credit system

What remains hard

  • Product polish and ongoing maintenance
Read the build prompt

First-year cost

No published price

GhostSIM 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 GhostSIM replacement: use Node.js + Express backend, Postgres DB, and a React single-page frontend deployed in Docker with Caddy for TLS. Core features in scope: (1) admin config to add virtual-number provider credentials; (2) provision/purchase a number from the provider API and store mapping in Postgres; (3) webhook endpoint to receive inbound SMS, parse verification codes (regex), persist messages, and mark refunds if no SMS arrives in 20 minutes; (4) user UI to pick country, show active numbers and received messages, and copy codes; (5) Stripe integration for one-time credit packs and weekly/monthly subscriptions; (6) background job to reconcile provider billing and trigger refunds. Out of scope: building global number inventory negotiations, native App Store / Google Play mobile clients, and growth/referral systems beyond a simple promo-code credit. Include error handling for provider API failures, idempotent webhook processing, automated tests for webhook parsing and payments, and deployment scripts (Dockerfile + docker-compose).
How we checked1 sources · 2/3 runs agreed · evidence score 52

How the score was reached

  • Partly verdict base52
  • Evidence score52

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.

! 2 of 3 runs agreed; the verdict is the majority✓ Citations limited to fetched pages! 1 moat recorded