Custom configuration and quoting software for machine builders, on an Open Mercato foundation
The configuration model, the rules, the pricing, the bill of materials and the 3D were written for this machine and this sales process, on the customer records, catalogue, quotes and orders Open Mercato already carries
This is custom software for configuring and quoting machines built to order, written on an Open Mercato foundation. The configuration model, the rules, the pricing and the visualisation exist for one machine and one sales process, and they sit on the customer records, catalogue, quotes and orders the platform already carries.
The sales rep configures. Rules block what cannot be built and say why. The specification, the bill of materials and the price come out of the same evaluation that drives the 3D model. The customer opens a link, sees the machine, and either accepts it or asks for a change. The accepted configuration becomes an order pointing at the same frozen snapshot.
The build is a demo. It came together over a weekend at the Open Mercato hackathon in Wrocław in September 2026, where it took first place in a ten-team Showcase track run by the platform’s own maintainers, and it has no production deployment or client outcomes behind it. We publish it as a worked example of how we build custom software on an Open Mercato foundation. It is a demonstration, and it is not a packaged product we license or host.
Manufacturers and dealers deciding where their configuration logic should live reach that decision from two directions. A packaged configurator brings a proven path, a product roadmap and a vendor behind it. Custom software on a platform foundation brings a fit to the process a company already runs and a codebase it owns. Both routes are legitimate, and this case study documents the second one.
Business challenge
Plenty of configurable machines are still quoted by hand. The rep opens an option sheet, cross-checks a price list, and calls engineering to confirm that the combination can be built at all. Every one of those steps re-reads information the business already holds, and across a sales team the time adds up long before anyone counts it.
The expensive failure sits further down the line. A configuration that passes the quote and fails in production costs rework, a delayed handover and a conversation with the customer that no discount repairs. That is the risk the quoting step is supposed to absorb, and a spreadsheet cannot absorb it.
From there the routes split. A packaged configurator product covers this ground with a path the vendor maintains, and for many manufacturers that is the right answer. Software written for your own process covers it with a fit to how you already sell, and a codebase you own. In practice the choice turns on a handful of specifics:
- →how many people open a configurator and how often, which decides what shape of licensing or hosting suits you
- →how much of your rule set, pricing and paperwork follows a standard path, and how much of it is particular to your company
- →whether visualisation is part of the job, and at what fidelity
- →where a finished configuration has to land, and how many systems sit between it and an order
- →how often the model changes, and who you want to be able to change it
Solution overview
We wrote the configuration and quoting layer directly inside Open Mercato, on the same data as customers, quotes and orders. Every part of it was written for this machine and this sales process, which is what a custom build is for.
The platform supplied authentication, multi-tenancy with per-tenant branding, the back-office structure and navigation, company and contact records, the product catalogue, sales quotes with discounts, VAT and multiple currencies, orders, and dashboard widgets. None of that had to be designed or written.
Our layer is the part that only exists for a configurable machine: the configuration model, the rules and their messages, the calculated specification, the price roll-up, the bill of materials, the 3D and 2D representation of the machine, and the handshake that puts a configuration in front of the customer and brings their answer back.
Key elements of the solution
A configuration model whose rules carry their reason
- →the demo machine has 19 options in six groups, from frame and running gear to attachment equipment, vision and safety, operator controls and finish
- →eleven rules govern them, and every rule has an identifier and a message written in plain language for the person looking at the screen
- →a rule can force a value, add a surcharge, warn the customer, or block the configuration outright
- →select hydraulic stabilisers on the standard frame and the configurator explains that the frame has no stabiliser mounts and names the frame that does, while the button that adds the machine to a quote stays disabled
- →switch on person detection and the rear camera is selected for you, with the reason shown beside it
- →behind the 19 options sit seven lookups, two formulas and 27 bill-of-materials mappings, so a change to a price or a part is a change in one place
One evaluation, so the picture, the parts and the price cannot drift apart
- →the model is published as an immutable version with a hash, and the configurator names the version it evaluated against at the bottom of the screen
- →the bill of materials grows from five lines to nine as options are chosen, each line carrying its own SKU, quantity and unit
- →the price rolls up in the open: net list, customer discount, net after discount, VAT, gross, with every surcharge pointing back at the rule that produced it
- →the calculated specification comes from the same evaluation, including engine and cab data, the attachment static moment and the load-chart utilisation
- →a read-only dependency map shows how features, lookups, rules and bill-of-materials lines reference each other, and an unresolved reference opens the validation report instead of shipping a broken model
The machine on screen, and a drawing when the drawing is the point
- →the configured machine renders live in 3D from five viewpoints, and every option that changes the machine changes the model
- →a 2D switch replaces it with a dimensioned technical view: maximum lift height, transport height, wheelbase and overall length
- →the rendering is procedural rather than imported from a CAD library, and the 2D view doubles as the fallback when hardware acceleration is unavailable
A customer who signs off without an account
- →the rep shares a link the customer can open on any device, with no account and no sign-in; the link is shown once, expires after thirty days, and sharing again replaces it
- →the customer sees the machine, the specification, the options and the price line by line, then either accepts the configuration or requests a change with a comment
- →the answer returns to the quote as a status, with the comment attached, so nobody has to reconcile an email thread against a document
- →superseded configurations stay on the quote with their timestamps, and the rep reopens any of them as a duplicate
- →the same configuration prints as a customer document with its own reference, so what was agreed survives outside the screen
Quote to order inside one system
- →an accepted configuration converts into an order that points at the same frozen snapshot
- →production would read what was sold instead of an interpretation of it, because the configuration, the bill of materials and the price came out of a single evaluation
- →quotes, orders and configuration activity all report from the same back office, including a dashboard view of open configurator sessions and finished configurations
- →quotes carry their own currency, so a machine priced in euros and a machine priced in dollars live side by side
The demo stops at a deliberate line. The customer approves a configuration and does not build one. Rules are edited in forms and in JSON, with no visual canvas. The 3D is drawn in code rather than taken from the manufacturer’s CAD. The bill of materials ends at the quote.
Operational improvements
The layer replaces a quoting loop, so the improvements are the ones that loop was costing.
What stops happening
- →the call to engineering disappears for every combination the rules already cover
- →an invalid machine cannot reach a quote, because the rule that blocks it also disables the button that adds it
- →the bill of materials, the price and the 3D come out of one evaluation, so there is nothing to reconcile between the quote and the shop floor
- →the customer answer arrives as a status on the quote, with the comment attached, rather than as an email somebody has to transcribe
- →a change request reopens the configuration it refers to, and the version it replaced stays on the quote with its timestamp
- →a new option, a new price or a new rule is one edit in the model, and every quote written afterwards records the version it was priced against
What it is worth, on stated assumptions
- →a dealer with ten reps, twenty quotes a month each, and an hour per quote today once the option sheet, the price list and the call to engineering are counted
- →that is 2,400 hours a year, or roughly 72,000 euros at a placeholder rate of 30 euros an hour of fully loaded sales time
- →the same volume at fifteen minutes a quote leaves 600 hours, or roughly 18,000 euros
- →the difference is around 54,000 euros a year in quoting time alone
- →these are assumptions rather than an audit: put in your own rep count and your own quoting time, and the shape of the answer holds
The larger number has no figure against it on purpose. The machine in this demo carries a demo list price of 117,300 euros net, which is calibrated data and not a market figure. One configuration that reaches production wrong costs rework, a delayed handover and a conversation with the customer, and any one of those can outweigh a year of saved quoting time. That line is yours to fill in, because only you know how often it happens.
Strategic impact
A configurator is the smallest part of the system it needs to run. Authentication, permissions, multi-tenancy, the back office, search, the data layer, customer records, the catalogue, quotes with discounts and tax, and orders all have to exist before the first option appears on screen. The structural gains come from the layer sitting inside all of that rather than beside it:
- →configuration, quotes and orders share one database, so a rule change or a price change reaches the quote without crossing an integration
- →the model is versioned and every quote records which version priced it, which is what makes a quote from last year defensible this year
- →around one and a half per cent of the source we run was written for this build, so the code you own stays small
- →the platform arrives as versioned packages rather than a fork, so upstream work keeps landing without a migration project
- →the same model is the starting point for whatever a given manufacturer needs next, whether that is a bill of materials that feeds the warehouse and purchasing, since the platform already carries warehouse and ordering modules, or an integration with the systems they already run
The ratio is worth stating plainly. The layer we wrote is around 30,000 lines of TypeScript against roughly two million in the twenty-eight platform packages it depends on, counted as source lines across both, and the step that turns an accepted configuration into an order is not ours at all: the layer holds sixteen API routes and not one of them creates an order, because the platform already does. A team of two put it together over one weekend, and that was possible because the platform carried everything except the configuration layer. The same ratio is what makes a custom route affordable for a company whose process sits outside a standard path.
If your machines are quoted the way the first section describes, the question worth answering is which of these pieces you already have, and which one is missing.
work.with.us;
Bring one real problem; leave with a clear answer.