2dto3D

You give it a photo. It gives you back a 3D model you can look at, download, and use.

The demo version of that is a single API call to a generation provider. The product version is everything around the API call, which is where all the work actually is.

The pipeline

A generation runs as ten stages on a queue, not one request: identify the subject, generate multiple views, generate the 3D geometry, generate the texture, render a preview, poll for status, optimize the mesh, export, and confirm the export. Stages retry independently, and anything that exhausts its retries lands in a dead-letter queue rather than vanishing.

Mesh optimization runs in a Cloudflare Container, because it is a real binary pipeline that does not fit in a Worker. Everything else is Workers, D1, and R2.

Generation itself is provider-agnostic behind a factory: Tripo3D and fal.ai’s SAM-3D for geometry, a separate model for multiview, GPT-4o for identifying what the subject even is. Providers change often in this space, so none of them are load-bearing.

The unglamorous half

Google OAuth and email magic links. Sessions cached in KV. Credit billing through Polar with a transaction ledger, volume bonuses, and redemption codes. Organizations with shared credit pools. Nineteen database tables. A monthly cron that resets the free tier and a daily one that sends lifecycle email.

That half is why it is a product rather than a demo, and it is roughly 80% of the code.

Built solo. About 33,000 lines across four Workers, 166 commits.