BuildWise

The problem

Beginners guess slicer numbers.

A slicer presents a wall of knobs — walls, infill density and pattern, layer height, temperatures, speeds, supports, chamber — and almost no guidance on which ones matter for your part on your machine. So beginners copy a number off a forum, crank infill to 100% for "strength," and wonder why the part is heavy, slow, and still snaps. The advice that exists is generic, contradictory, and rarely tied to the printer in front of you.

Experts don't think in numbers. They think in intent — strong, fast, cheap, pretty, does-it-live-in-a-hot-car — and let the tradeoffs follow from the hardware and the physics. The gap between those two worlds is exactly where parts fail.

The solution

State intent. Get defensible settings.

BuildWise moves you from guessing numbers to stating intent. You give it your printer, your filament, what you're making, and optionally an STL; it returns a settings table tuned to your exact setup, with an honest "why" on every row and explicit tradeoffs when goals conflict — strength versus speed, surface versus time.

It's built on one principle: the computer handles the facts; the model handles the judgment. Anything deterministic — printer specs, physical feasibility, part geometry, which engineering principle applies — is computed in code and handed to Claude as authoritative context. The model never guesses your hotend's max temperature or whether a material can physically print; it reasons over grounded facts and communicates them well. And it refuses common-but-wrong moves — like 100% infill for strength — rather than politely obliging them.

Embeddings run locally, so the only model in the loop is Claude — retrieval adds no second API dependency, no extra latency tax, nothing to sign up for.

Status

Live, and free to try.

The full engine is up and running: typed domain models, the STL geometry analyzer, sourced printer and material fact tables, the deterministic feasibility gate, local-embedding RAG over a curated principle corpus, and the coach with table output, verbosity, and goal tradeoffs — driven by a custom web UI on a FastAPI backend, all behind 130 passing tests, a retrieval eval, and a CI pipeline that fails the build if a test is skipped. It runs on my own server, behind a reverse proxy, rather than on a managed Space.

Upload a part and the demo gives you the whole thing — the geometry read off your mesh, the feasibility verdict, and the settings table with a reason on every row — with no account and no API key. The write-up is the only part that calls a model, so it runs against a daily ceiling I pay for; when that is spent the demo falls back to the geometry and feasibility half, which is pure code and costs nothing to serve, and says so rather than failing. Paste your own key and you skip the ceiling entirely.

That split is the product's whole argument, made literal: the deterministic engine decides what is possible, and the model only writes it up.