LoopSmiths builds software it also has to run. QuoteSmiths is not licensed out and handed to someone else's support desk. The people who write the rules engine are the people who answer for it when a plan fails to parse at an awkward hour. That fact shapes engineering decisions more than any style guide does.
Most product decisions look free at build time. Clever inference, one more service in the stack, a silent retry, a fallback that quietly guesses: none of it costs anything on the day it ships. It bills later, in hours spent working out what the system did and why. When the team that built it pays that bill itself, the appetite for cleverness drops away.
Clever behaviour is expensive to explain
There is a version of estimating software that reads a plan and produces quantities in one motion. It demos beautifully. It is hard to defend when an estimator rings to ask why the wall framing came out the way it did, because the honest answer is that a model produced a number and nobody can point at the step behind it.
QuoteSmiths splits that job in two on purpose. Vision AI reads the PDF plan and extracts what it can see: dimensions, rooms, materials. A deterministic rules engine then applies geometry-based formulas and waste factors to produce the costed bill of materials. Quantities are calculated by explicit rule, never generated by a model. When someone asks where a number came from, the answer is a rule, a set of inputs and a version. That answer survives a phone call.
A system that cannot explain itself becomes a system only its author can support.
The confirmation step exists for the operator, not the demo
Between reading and calculating, QuoteSmiths asks the operator to confirm what the plan reader found. It adds a step and it makes the flow less magical. From an operations point of view it is the most useful piece of design in the product, because it puts a human decision on the record at exactly the point where machine reading is least certain.
The effect on support is direct. A wrong number is either a confirmation problem or a rules problem, and those are different conversations with different fixes. Without that boundary, every complaint arrives as the same sentence: the software got it wrong.
Build the record before anyone asks for it
Teams that operate their own products learn that most incidents are not outages. They are questions. Why is this quote different from the one sent last month. Who changed that quantity. Which supplier price was used. Answering from memory stops working early, so the record has to be built in rather than added after the first hard question.
- Versioned bills of materials, so an earlier quote can be reproduced rather than reconstructed.
- Workspace roles and approval, so it is clear who signed off and when.
- Purchase orders grouped by supplier and delivery stage, so what was ordered traces back to what was calculated.
- Back-costing against actuals, so a rule that reads well on paper can be checked against what the job consumed.
None of that is compliance decoration. It is the difference between answering a question from the record and rebuilding the answer from memory.
Failure should be loud
The instinct to keep a product feeling smooth pushes towards silent recovery: swallow the error, fall back to a default, retry quietly, carry on. For an operator that is the worst outcome, because the system keeps producing output that looks correct. A quote that is confidently wrong travels. It goes to a client, it gets accepted, and it turns into purchase orders before anyone notices the number was never really read off the plan.
So the preference is to stop and say so. If the plan reader cannot resolve a dimension it needs, the right behaviour is to name that dimension rather than assume one. If a line has no supplier SKU attached, it should read as incomplete rather than quietly price at zero. Loud failure is cheap to fix on the day. Quiet failure is expensive later, on site.
Every dependency is a pager someone has to carry
Taking on a dependency is a promise to understand someone else's failure modes at a time that suits them. The question asked before adding one is not whether it saves a week now. It is whether a two-person team can diagnose it at 2am with the documentation that actually exists. That test rules out plenty of otherwise reasonable options.
The same shape runs through the rest of the studio's work. The Concept Realty, which is in development, applies it to property operations: AI-assisted defect detection on inspection photos with a person validating each finding, so the record shows what was flagged, what was confirmed and by whom. Machine reading proposes, a person decides, the system remembers.
What it costs and what it buys
This way of building is slower in obvious places. A confirmation step is more work than no confirmation step. Versioning is more work than overwriting. Explicit rules are more work than asking a model, and they have to be maintained as products and prices change. The trade is deliberate: less time making something impressive, more time making something supportable.
Software built by people who never operate it tends to be optimised for the moment of purchase. Software built by people who do is optimised for the long stretch of ordinary use that follows, which is the part that decides whether anyone keeps paying for it.