Compare · build vs buy
You could build this. Here is what you would be taking on.
If you have a developer and a clear idea of your own pricing, version one is genuinely a fortnight’s work: an upload form, a mesh library for volume, a formula, an e-mail. It will work, and for some shops that is the end of the story. This page is about the part after that.
When building it yourself is the right answer
- You run one process on one machine class with one material, and your pricing genuinely is volume times a number.
- You have in-house developers with spare capacity and an interest in keeping it.
- Your pricing logic is a trade secret specific enough that you would not want it in anyone else’s product.
- You quote a handful of parts a week, and the manual process is not actually costing you anything.
In those cases, build it. We would rather you did than pay us for something you do not need.
What version five looks like
| What comes up | Why it is not a weekend |
|---|---|
| Meshes that are not watertight | Most uploaded files are broken in some way. Volume from a non-manifold mesh is a plausible-looking wrong number, and plausible-looking wrong numbers are the expensive kind. |
| Units | STL does not record them. A part arriving 25.4× wrong quotes at 16 000× the material. You will find this out from a customer. |
| Wall thickness | “Is anything thinner than 0.8 mm?” is a real computational geometry problem, not a bounding-box check. |
| Support estimation | Requires overhang area by angle in a chosen orientation, and the orientation choice changes the answer. |
| Powder build share | The arithmetic that makes SLS and MJF quoting correct, and the single thing home-made calculators get most wrong. |
| Money | Floats in prices produce rounding disputes. Integer minor units, one rounding point per line, and tax rules by country - including reverse charge - are a project on their own. |
| Versioning | A quote sent in March must still explain itself in November after you have changed your rates twice. That means configurations are versioned documents and quotes reference versions. |
| Multi-tenancy, if you have sites | Or just: the widget has to work on your page without your CSS breaking it, and it must never throw into your site. |
| Upload at real sizes | A 200 MB assembly over a phone connection needs resumable multipart upload, or your buyer gives up. |
| Maintenance | It is now a system your shop depends on, maintained by whoever wrote it, for as long as they work there. |
Build the front end, buy the engine
This is genuinely common and we support it deliberately. Everything the widget does is a documented REST API with an OpenAPI document: upload, analyse, price, quote, order, webhooks, customer tokens. Build exactly the buyer experience you want, and let the geometry and the pricing be someone else’s maintenance burden.
A shop can start here and adopt the widget later, once keeping its own front end stops being interesting, or go the other way. Both are fine.
Take the checklist with you
If you do build it, the evaluation questions are still the right list - they are what a good quoting system has to get right, whoever writes it. The build-share question and the “does an old quote still explain itself” question are the two that come back to bite.
Or spend twenty minutes finding out
Bring a part you have quoted by hand. If your own spreadsheet is better, that is a useful thing to learn in twenty minutes.