AI for client acquisition — a working scheme. Especially when you hit several pain points at once

In the first part, we broke down a simple principle: AI accelerates MVP only within a fixed hypothesis and Must-have. Without scope boundaries, it just produces extra volume faster.

The continuation is about something else: client acquisition through an AI-accelerated MVP is not theory. It's a working commercial technique. And it becomes noticeably stronger when one short release addresses not one, but several customer pains at once.

Short answer: a client more often buys the next stage not because "AI is trendy," but because at the demo they saw a solution to several of their daily problems — in a single passable scenario.

---

Why "one pain — one slide" is weaker than a vertical of several pains

A B2B customer almost never has one isolated problem. Usually there's a bundle:

Pain	How it sounds at the customer	What they actually lose
Sales / approval	"It's hard for us to explain the value internally"	The deal stalls on slides and verbal promises
Operations	"We calculate in Excel, make mistakes, it's slow"	Specialists' time and defects in specifications
Knowledge	"Formulas live with one person in a file"	Risk of losing expertise and difficult onboarding
Scale	"Then also 1C / CAD / other lines"	Fear to start, because it seems "we need everything at once"

If the MVP closes only UI "for beauty," objections remain.
If the MVP shows a calculating scenario + a clear result + a path forward — several stop-factors are removed at once.

Here AI helps not "to add a neural network to the product," but to assemble such a vertical faster: parse Excel/TZ, sketch domain rules, raise a wizard, build a demo stand.

---

Case: MVP for Blum hardware selection

Let's break it down on a real engineering project.

Project essence

We needed to make a CPQ-type web tool for furniture production: selection and calculation of Blum hardware, primarily AVENTOS HF top lift systems.

Not a "picture catalog," but a working path:

1. set project and facade parameters;
2. get a calculation (load, mechanism, hinges, specification);
3. see a preview;
4. save the project and print the result;
5. if necessary, browse the nomenclature reference.

What problem the client faced

Before the digital MVP, the process looked typical for a complex subject domain:

• the key calculation lived in an Excel calculator;
• nomenclature and logic additionally relied on a PDF catalog and internal materials;
• a specialist manually transferred the result into documents;
• a full enterprise contour (all Blum lines, 1C, BAZIS, roles, audit) looked expensive and long if built "from scratch and everything at once."

That is, the pain was not only technical. It was a tangle:

Pain direction	Specifically in the Blum project
Engineering	Hard to quickly and transparently get an HF top specification
Knowledge	Rules are "locked" in Excel and heads
Commerce / internal stakeholders	Hard to show the future solution without a working demo
Development	Fear that without 1C/full catalog it's pointless to start

What hypothesis we tested with the first release

If a technologist/designer can complete the AVENTOS HF top calculation in the web in one session and get a specification without a manual Excel cycle, the customer will confirm the value of digitalization and agree to the next stage (other lines, server storage, integrations).

This is what acquisition through MVP is: not promising a platform, but showing one credible piece of value.

---

How AI helped hit several pains at once

AI was not a "feature for the user" in the first version. It accelerated the team's delivery contour on several fronts simultaneously.

Customer pain	What we did in MVP	Where AI accelerated the team
Long/fragile calculation in Excel	Web wizard HF top + domain formula module	Draft of functions, mechanism rules, types, edge cases
Opaque specification	Result screen: mechanism HF 25/28/31, hinges, positions, warnings	Result UI skeleton, specification structure, state texts
Knowledge only in a file	Rules moved into code (calculateHfTop, mechanism table)	Fast transfer of logic from description/Excel into TypeScript skeleton
Need to "touch," not listen	Demo stand (Docker / Node), project save and print	Launch wrapper, checklists, demo scenario
Fear of "needing everything at once"	Strict Not Now: other lines, 1C, auth, DB	Generation only within Must-have, without sprawl

Result for the client at the demo: they see not an abstract AI pitch, but the closing of their pains — faster calculation, clearer specification, safer start without enterprise overload.

---

What exactly we implemented

User path

1. project dashboard;
2. HF top calculation wizard: project → dimensions → material → result;
3. live facade preview at steps;
4. save project;
5. print;
6. Blum reference with search and categories (demo sample).

Technical solution

Layer	Solution in MVP	Why
UI	Next.js 14 (App Router), React 18, Tailwind	Quickly assemble a passable wizard
Domain	TypeScript module for HF top calculation	Formulas separated from screens
Data	Local reference + materials in code	No need to wait for integrations for demo
Storage	localStorage	Close the loop "calculated → saved → printed"
Ops	Docker / npm run build, basic CI	Stand is reproducible, not "only on a laptop"
Quality	Scripts for cross-check with Excel reference	Demo looks engineering-grade, discrepancies are visible

Key engineering move: domain calculation is not mixed with UI.
UI collects input, the module calculates facade weight, LF, selects mechanism, assembles specification. Later this same core can be moved to an API and connected to 1C — without rewriting the wizard from scratch.

What was deliberately not included in the first release

Deferred	Why Not Now
HK top, LEGRABOX, TANDEMBOX	First prove one scenario
Integrations with 1C and BAZIS	Not needed to validate demand for the web path
Auth, roles, audit	Enterprise horizon, not a demo hypothesis
Full PDF catalog as online base	Demo sample is enough for the scenario
Server DB	Excessive for the first experiment

This is exactly what allowed us to quickly get a commercial effect: show value early, without drowning in a "platform for years."

---

How several pains strengthen the sale of the next stage

After such an MVP, the conversation with the client changes.

Before the demo	After the demo
"We need digitalization in general"	"Here's a working HF top — let's expand"
"Without 1C it's too early to start"	"First we confirm the scenario, 1C is the next contour"
"Excel suits us"	"Web shows the specification faster and is more convenient for the team"
"Hard to estimate the scope"	There's a Must/Not Now boundary and a clear roadmap

AI accelerated the build.
But sold the next stage not AI as a brand, but the closing of several pains in one short value path.

---

Practical framework: multi-pain MVP

If you repeat the approach on other projects:

1. Build a pain map of the customer (sales, operations, knowledge, integrations, start risk).
2. Choose one core path that touches 2–3 pains at once.
3. Fix Must/Not Now before generation.
4. Use AI for reference parsing, domain, UI, stand, demo scenario.
5. Leave to humans formula acceptance, scope promises, and success criteria.
6. At the demo explicitly show which pains are already closed and which are deliberately deferred.

Good multi-pain MVP	Bad "AI MVP"
One scenario closes several pains	Many screens about no pain to the end
There's a reference and cross-check	"Looks like the truth" without verification
There's a stand via link	Only presentation and Figma
There's an honest Not Now	Promise "we'll do everything at once"

---

Summary

Using AI for client acquisition is a working thing.
But the maximum effect comes not from code generation as such, but from assembling a short MVP that simultaneously:

• accelerates approval;
• removes operational pain;
• pulls knowledge out of Excel into a managed contour;
• shows a safe path to a large scope without the need to build everything yesterday.

The Blum case illustrates this well: instead of endless discussion of a "hardware platform," the customer got a calculating web scenario for AVENTOS HF top on a modern stack — and the foundation for the next stage already on facts, not slides.

---

FAQ

Do I have to mention AI when selling to the customer?
No. Often it's enough to show the speed and quality of the demo. AI is an internal delivery accelerator, unless it itself is the product's value.

Why can't we close all Blum lines at once?
Because then MVP disappears again: longer to first proof, more expensive hypothesis error. First one credible path.

What was the most important technical decision?
Separating the domain calculation from the UI and maintaining the link with the Excel reference. This gave trust at the demo and a foundation for integrations.

How do I know the multi-pain MVP worked?
If after the demo the conversation shifts from "do we need this" to "in what order do we expand" — the acquisition hypothesis worked.