Product Design · Systems Design · Applied AI
Workshop Quoting System
A production-ready quoting system that transforms tacit workshop pricing knowledge into an explicit, reusable decision framework — supporting faster initial estimates while preserving expert judgment for complex work.
A quote that depended on one person’s head, turned into criteria that can be written down, questioned, and improved.
Presupuestador is a production-ready decision-support and quoting system built for Guzmán Villalba, a custom metal-fabrication workshop in Montevideo. What began as one estimator’s undocumented pricing judgment is now a structured decision framework — one that traveled from a Google Sheets model to a responsive V1 product, deployed and in real use, while a possible V2 for larger, project-based quotations stays a documented direction, not a built feature.
- Operational diagnosis
- Documented criteria
- Google Sheets MVP
- Responsive V1 (deployed on Vercel)
- Calibration & documentation
- V2 — project-based estimation
Where the project actually stands: a working V1 is live and answering real quotes today. Calibrating its pricing criteria with the workshop’s estimator, and documenting the rules behind it, is ongoing work — not a finished, closed step. A V2 for larger, more complex project-based quotes is an active area of investigation, not something built yet.
A workshop that quotes well — just slowly, and from one person’s head.
Guzmán Villalba is a custom metal-fabrication workshop in Montevideo (internally, the project described here is called Presupuestador). Every job — from a one-off staircase railing to a small production run of parts — starts with a quote. For years, that quote came from one estimator’s judgment: material, labor, machine time, and margin, priced from memory and experience, not from a written system.
That worked while volume stayed manageable. Then jobs started queuing up behind one person. Someone new on the team couldn’t estimate without shadowing that process for months. And because the judgment lived only in his head, it couldn’t be questioned, versioned, or improved — only repeated.
A generic, off-the-shelf pricing calculator was never going to solve this. The workshop’s jobs are custom by nature — no two railings, staircases, or production runs share the same combination of material, cut complexity, finishing, and logistics. A tool that assumed standard products, standard quantities, or a fixed catalog would have ignored the exact judgment the workshop actually depends on.
A slow quote can lose the job before any metal gets cut.
A client calling for a rough number needs a fast, defensible answer. If the only path is a complete formal quote — and that quote depends on one specific person having time that week — the answer arrives late, or doesn’t arrive at all.
- Pricing judgment wasn’t written down anywhere — it lived entirely in one person’s experience.
- There was no fast way to give an orientative range without building the full quote first.
- Adding people to the estimating side of the business meant, in practice, that one person had to walk each of them through every case individually.
- An unanswered or delayed quote can’t convert into a job — the backlog isn’t just an inconvenience, it’s lost work.
At times, more than ten quotations could sit pending or unsent at once — an observed range from the workshop’s day-to-day operation, not a formally tracked metric. Some share of those never needed a full formal quote in the first place: a fast, orientative range, given up front, can already show a client that a job sits outside their expected budget — without spending the time to build a detailed quote that was never going to be accepted.
[Internal working estimate, not yet measured — confirm before publishing: the team’s informal sense is that something in the order of 70% of quotes that go unanswered fall into this category — work that an early range would have filtered out before a full quote was ever built. This is a working estimate used to motivate the project, not a validated business metric, and it should either be measured properly or removed before this case goes live.]
Watching quotes get built, not just asking how they get built.
Interviews alone undersold how much judgment was involved — the estimator himself struggled to put his own rules into words. Shadowing several real quotes end to end surfaced the actual variables in play, and the real work of this project turned out to be documenting materials, labor units, margins, cut and fabrication complexity, finishing steps, placement/installation, and external or outsourced supplies — not designing screens. The interface came later, and was the easier part once that documentation existed.
The clearest finding: the judgment wasn’t arbitrary, it was consistent but undocumented — which meant it could be captured as an explicit model, rather than replaced by a generic pricing formula that would have ignored the workshop’s real constraints.
The variables the pricing model reads.
The same pricing logic has been read by more than one surface over time — first the Google Sheets model, now the responsive V1 product — without the underlying criteria needing to be rebuilt each time. The variables below are the ones documented so far:
by…
This represents the variables identified and documented so far — it is not a claim that the model automatically covers every kind of job the workshop takes on. Atypical or highly custom work still routes through the estimator’s direct judgment (more in AI & Judgment and Limitations below).
Ship the logic before the interface.
The first version of the pricing model lived entirely in Google Sheets with Apps Script — deliberately, so the estimator could correct and extend the logic himself without waiting on a development cycle, and so the criteria could be validated against real quotes before any dedicated interface was built.
Every quote that ran through the sheet was logged. That growing base of quotes — not a business number, but the system’s own working material — made it possible to compare the model’s proposed number against the estimator’s own judgment, case by case, and adjust the model’s weighting before moving to a dedicated interface.
-
Run a real quote through the modelSame case, two judgments side by side: the model’s and the estimator’s.
-
Flag matches and gapsGaps weren’t averaged away or ignored — each one was reviewed to find the missing or mis-weighted variable.
-
Adjust the model, not the judgmentThe goal was for the model to learn to explain the estimator’s judgment — not the other way around.
This comparison loop wasn’t a round of usability testing with outside users — it was, and still is, the estimator reviewing the model’s output against his own. That loop didn’t stop once the Sheets model gave way to the V1 product below; it’s part of how the system continues to be calibrated today (more in Current Status).
From a spreadsheet only one person could drive to a responsive product the team can open from a phone, tablet, or desktop.
The V1 is a responsive web product, deployed on Vercel, that reads the same pricing logic validated in the Sheets MVP — the criteria weren’t rewritten, only re-surfaced behind a real interface. It has been tested and confirmed working on desktop, tablet, and mobile, and the primary quoting flow — from structured input to an orientative range, through to a full quote — is implemented and functional today.
-
Same model, new front doorThe V1 reads the same pricing model validated in Sheets — no criteria were rewritten, only re-surfaced behind a real interface.
-
Guided input instead of a blank spreadsheetA short structured form replaces free-form cells, so anyone on the team — not just the original estimator — can produce a consistently structured quote.
-
Fast range first, detailed quote secondThe product answers a client-facing “roughly how much” quickly, then supports building the fuller, itemized quote afterward.
This is presented as a working V1, not a finished, final commercial product. Minor fixes and calibration are still in progress — see Current Status below for exactly what that means today.
AI as a production and reasoning partner — not as the one setting the price.
AI tools (Claude and ChatGPT, specifically) were used in a few concrete, reviewable parts of building this project — not as an autonomous feature inside the product itself. Everything below describes how they were actually used; nothing here is a claim about the shipped V1 making automatic decisions.
Structuring documented criteria
- Task
- Turning shadowing notes and interview material into an explicit, organized set of pricing rules and variables.
- Reviewed by
- Every rule checked and confirmed against the estimator’s own judgment before being treated as final.
Development support for the V1
- Task
- Assisting with writing and debugging the code behind the responsive V1 product.
- Reviewed by
- All logic reviewed before deployment — nothing shipped without a human review pass.
Drafting and organizing documentation
- Task
- Helping draft and structure internal documentation, and this case study itself.
- Reviewed by
- Reviewed and corrected against the real project facts before publishing.
Future exploration, not built: ideas like AI-assisted anomaly flagging on unusual quotes, or smarter suggested ranges drawn from historical data, have come up as possible directions — most likely relevant to a future V2 rather than the current V1. These are not implemented today and are noted here only as a direction under consideration, not a feature in progress.
The system doesn’t replace the workshop’s estimator — it structures his judgment and puts it into operation. Fast ranges are for answering quickly and doing an early viability check; an unusual case, with conditions the documented model doesn’t cover well yet, still needs the estimator’s judgment before a quote is confirmed.
Where the system stands today.
Presupuestador is a system in real, active use — not a finished, closed product. Here’s what can be said with confidence today, and what’s still genuinely in progress.
- A responsive V1 is deployed on Vercel and answers real quotes.
- The primary quoting flow — structured input to orientative range to full quote — is implemented and functional.
- Confirmed working on desktop, tablet, and mobile.
- Pricing judgment is written down and versioned — it no longer lives only in one person’s head.
- Every quote that runs through the system gets logged, rather than disappearing into a conversation or a scrap of paper.
- Pricing dimensions, measures, and criteria are still being calibrated directly with the workshop’s estimator.
- Documentation of workshop rules and criteria continues to evolve — it isn’t a closed reference yet.
- Minor fixes remain before the V1 is considered fully settled.
- Unusual or atypical cases still rely on the estimator’s direct judgment — there isn’t enough documented history yet to cover them with confidence.
- No validated business-impact numbers (response time, adoption, conversion) exist yet — see Limitations.
What the system doesn’t do yet.
- Complex, fully custom, or project-scale work still gets resolved primarily through the estimator’s manual judgment — the documented model covers the common pattern well, not every exceptional case.
- Calibration of the V1’s pricing criteria with the estimator is incomplete — some dimensions and measures are still being adjusted.
- Tacit workshop criteria are still being documented — not everything the estimator knows has been captured yet.
- No validated business-impact metrics exist yet — response time, adoption, or conversion improvements are not currently measured or claimed.
- The system depends on the estimator continuing to review and correct it for atypical jobs — the judgment doesn’t maintain itself.
The hard part was never the screen.
The real design work was making explicit a judgment that one person had never had to put into words — clear enough to write down, question, and correct. The interface was, by comparison, the easier step once that documentation existed.
I also learned to distrust the temptation to replace expert judgment with a tidy formula: a model that ignored the workshop’s real constraints — client relationship, urgency, what’s actually documented versus what’s still tacit — would have been simpler to build, and worse. The system had to learn from the estimator, not correct him from the outside.
Working with AI tools throughout this project reinforced the same principle from a different angle: Claude and ChatGPT were genuinely useful as a production and reasoning partner — structuring documented criteria, supporting development, helping organize documentation — but every output stayed reviewable, and nothing was presented as an autonomous decision. The interesting design problem wasn’t how to automate the estimator away; it was how to move fast without letting speed quietly erode operational reliability or the trust the system depends on.
Where this goes from here.
Finish calibrating the V1
Continue working directly with the workshop’s estimator to calibrate pricing dimensions, measures, and criteria until the V1’s output consistently matches his own judgment across the common range of jobs.
Improve documentation and measurement
Keep documenting workshop rules and tacit criteria as they surface, and put real measurement in place — starting with tracking estimated quotes against actual production outcomes — instead of relying on informal impressions.
Track estimated vs. actual results
Once enough quotes have gone through the V1, compare what was quoted against what a job actually cost and took to produce — the first real evidence base for any future claim about accuracy or business impact.
Explore a V2 for project-based, larger-complexity quotations
Investigate what a V2 would need to support larger, more complex, project-based estimation — work that doesn’t fit the current item-by-item quoting model well. This is an active area of investigation only: no V2 has been built, and it is not represented anywhere in this case as an existing feature.