Written by someone who has spent an embarrassing number of hours doing exactly that.
I build stuff with these tools constantly. Lovable, Claude Code, Cursor. I’ve used them for early feature prototypes at HeadQ, Outside of HeadQ I use them to build actual software from scratch. Not prototypes sitting in a private repo. Things people use and I genuinely think they’re one of the most interesting shifts in how software gets made. I’m not writing this to talk you out of using them.
I’m writing this because I’ve also seen what happens when a manufacturing company ships a vibe-coded configurator into a real sales process. And it’s not pretty.
Let’s start where the argument usually starts.
You spend a week building a configurator for your forklift lineup. Not a weekend hack, a real build. It handles three models, two mast heights, four attachment options. Clean enough. Your sales director is impressed.
Then the requirements arrive.
“What happens when a customer selects the 6-meter mast but we only stock that in the diesel version?”
You add a constraint. Fine.
“And what if they’re in Norway? Different pricing.”
You add that.
“We also need to block the electric model in markets where we don’t have service coverage.”
Still manageable.
“Dealers get 22% margin, but it varies by product category and we have three distributor tiers.”
Here’s where it gets hard to explain even in a meeting room, let alone in code.
You’re no longer writing rules. You’re writing rules about rules. And what that actually looks like starts something like this:
if (market === “NO” && dealerTier === “gold”) {
if (productCategory === “heavy” && mastHeight >= 6) {
price = basePrice * 0.78 // 22% margin
} else if (productCategory === “heavy” && mastHeight < 6) {
price = basePrice * 0.81 // 19% margin — Nordic exception
}
} else if (market === “NO” && dealerTier === “silver”) {
}
Now multiply that across three markets, four product categories, two dealer tiers and a handful of regional availability rules that don’t map cleanly onto any of the others. The people who understand this logic are your sales engineers and product managers. Getting it out of their heads and into code, without losing anything in translation, without introducing a bug in the cases nobody thought to test, is a real project.
A good developer can build this. That’s not the question. The question is what you own when you’re done.
You have a system that works most of the time, that nobody can fully explain end to end and that you are now responsible for maintaining alongside everything else on your roadmap. Forever.
And that’s still just the configuration layer. Everything that happens after “Get Quote” — CRM routing, approval flows, stock checks, regional sales assignments — none of that came from the prompt either.
A broken checkout on a consumer site loses a €30 sale. A broken configurator in a B2B sales process loses a €300,000 deal, the relationship and every opportunity that came after it.
Your prospect configured something. Maybe shared it internally. Maybe built a business case around it. Then it shows them the wrong price, blocks a valid selection or just behaves in a way that doesn’t track.
They don’t file a bug report. They lose confidence. In B2B sales, that’s usually the end of it.
There’s no analytics event that captures “person closed the tab and called your competitor.”
Yes, SaaS vendors can raise prices, get acquired, or sunset features. Anyone pretending otherwise is selling something. But there’s a real difference between a vendor dependency you can evaluate, negotiate and exit on your timeline, and a custom system that breaks in production during a live sales conversation with no documentation and no clear owner. One is a business risk you manage. The other is an emergency that finds you.
Now the math.
The initial build felt cheap. And building with AI tools makes it look even cheaper. No agency fees, no long dev cycles, just you and a prompt.
But then the real world starts knocking.
A new distributor joins in Q3. Someone needs to get back in the code. A competitor drops prices in your German market and you need to respond this week, not after the next sprint. A product line gets retired but customers still need accessories for the old models, and now you have to build logic that surfaces compatible parts for hardware you no longer sell. Your sales rep in Sweden needs a different margin structure than the one you launched with.
None of this is exceptional. This is just a normal year in manufacturing.
And here’s what one manufacturer who built their own solution told us recently: the moment you go beyond the basics, the AI tooling costs start climbing fast too. Cursor, Copilot, API tokens, compute, licenses — small individually, all running continuously. By the time you’re maintaining real logic across real markets, you’ve quietly signed up for a stack of recurring costs that weren’t in the original calculation. And unlike a SaaS subscription, nobody sent you a proposal for them first.
Every single one of these moments — the distributor, the competitor move, the sunset product, the AI bill — costs you developer time, delays, and the quiet erosion of trust from a sales team that’s tired of waiting for software to catch up with the business.
Then there are the costs that don’t show up on a board. The deal that went cold because the configurator showed incorrect pricing. The sales rep who stopped using it and went back to spreadsheets because it was too unreliable. The enterprise prospect who asked about multi-currency support and got “we’re working on it.”
TCO never appears in the original build vs buy decision. It shows up later, one incident at a time.
Then someone leaves. The developer who built the whole thing is gone. The new hire inherits a codebase with no documentation, held together by logic that made sense nine months ago. They don’t rewrite it. They work around it. Now your pricing rules are a layer of workarounds on top of constraints on top of assumptions nobody remembers making.
You didn’t build a tool. You built a liability.
If you’re selling one product in one market with simple pricing, paid subcscription of HeadQ is probably more than you need. We have a free plan for that.
But most manufacturers aren’t there. They have product families. Regional pricing. Dealer tiers. Customers configuring in Swedish and quoting in euros while distributors in Norway need the same product in NOK with different margin logic applied automatically.
This is where custom-built breaks. Not dramatically. Slowly. One workaround at a time, until the cost of maintaining the system exceeds what the right tool would have cost from the start.
The real comparison was never HeadQ vs a configurator. It’s HeadQ vs a configurator plus everything else you still have to build: product discovery, real-time pricing, CRM integration, sales rep enablement, distributor portals. The full sales motion, not just the piece that looks good in a screenshot.
You’re not paying for a feature. You’re paying to not build, maintain, debug, and re-explain a system every time your business changes.
Here’s the challenge I’d put to anyone still skeptical.
Next time your pricing changes or you add a product to a new market, track it. Time from business decision to live in production. Count the meetings, the back-and-forth, the deployment. Then come see what that looks like on our end.
That’s not a pitch. That’s a dare.
Best regards,
Mikko / HeadQ
CEO, Co-Founder