When Does an Offline Business Actually Need an AI Product — and Where to Start

For the past couple of years, I've been having the same conversation over and over — with owners of offline businesses.

These aren't startup founders or product managers. These are people who've already built solid companies: service networks, law firms, education ventures, healthcare providers. They have revenue, teams, clients. The business works. But almost every one of these conversations eventually arrives at the same question: "Do we need to build some kind of AI product too?"

There are usually two motivations behind that question. The first is perfectly rational. They want to cut costs, automate parts of their operations, improve margins. Many processes really are moving into the digital space, and ignoring that is no longer an option. The second is far less rational — but entirely understandable. The fear of falling behind.

Every week, there's a new tool in the feed: Claude Code, OpenAI Codex, Cursor, Replit Agent. And with each one comes a story. "I sat down one evening and built a working service." "Replaced my entire finance department with a single prompt." "Automated all of marketing over the weekend." "Built an AI assistant that handles 80% of support requests." Replace your spreadsheets, replace your sales team, replace your service managers — and so on down the list.

The pace of technological development and its real-world application have reached the point where ignoring it genuinely isn't an option. Competitors are launching apps. Customers are solving problems through ChatGPT. Startups are doing in a month what used to take a year. It starts to feel like if you don't act now, in a few years you'll simply be left on the sidelines.

That fear isn't irrational. It's real. But fear alone isn't a strategy. And this is exactly the moment when companies most often make their first serious mistake.

The Most Common Mistake When Launching an AI Product

Here's a real story. Details have been changed, but the essence is exact. An offline services company. About ten years in the market, a wide network of locations across the country. The business runs well — clients come in, services are delivered. The company's core asset is its specialists' expertise and client trust. Personal relationships are everything.

But the market is shifting. Tasks that only specialists used to handle are starting to be covered by automated services. Some interactions are moving online. ChatGPT can already do things that clients used to pay a live expert for. The founder develops an ambition: build an AI-powered service and shift a significant part of the business into digital. The decision seems logical. A product manager is hired, a development team assembled, app development begins.

A year later, the product exists — but only technically. The founder himself describes it rather precisely as a "blank template." The technology is there. The interface is there. But several fundamental questions were never answered.

First — who exactly is this product for? The company offers dozens of service types to completely different client segments: from individuals who need one-time help to businesses that require ongoing support. They need different things, they're willing to pay for different things, and a digital product looks different for each of them. Trying to build for everyone resulted in a product that worked for no one.

Second — why would a client choose an app over their trusted specialist? In a services business where the core value proposition is trust and personal rapport, this is anything but obvious. People come to a specific expert because they believe in that person's experience. Transferring that trust to an interface is a separate, non-trivial challenge that good design alone cannot solve.

And third — a fundamental fork in the road that was never resolved. Is the company building a standalone IT platform that will eventually become its own business? Or is it enhancing the existing service with technology so that specialists can work more efficiently? These are different products, different teams, different budgets, and entirely different payback horizons. Without an answer, development drifts in both directions simultaneously and achieves results in neither.

While the company searches for answers, development continues and gradually turns into a rather expensive experiment. According to McKinsey, roughly 70% of digital transformation initiatives fail to meet their objectives — and the reason is almost never the technology. In projects like these, team costs easily reach $100,000–300,000 per year — even before marketing.

Stories like this are far more common than people think. Launching an AI product without answering the question "why" is a pattern I've explored in the context of entering new markets, and in digital products it plays out in exactly the same way.

Why Offline Companies Get Digital Products Wrong

There's a non-obvious reason why offline companies fall into this trap more often than others. They know their customer well. Ten years of operations, thousands of interactions, a finely tuned understanding of what people will pay for. This is a strength — but it's precisely what gets in the way. Because a digital customer is not the same person, just holding a phone. It's different behavior.

A person might trust their doctor or lawyer personally — and yet never install that company's app. Or the reverse: they might use a digital service regularly but only turn to a live specialist in emergencies. Some people are willing to pay for convenience, others for expertise — and these are different product propositions with different economics.

An offline company, accustomed to its customers, projects that understanding onto digital and ends up with a product that makes perfect sense internally — but isn't needed externally. "We know our customers" is the most dangerous phrase at the start of a digital product. You know your offline customers. How they'll behave in digital is an open question, and the answer is often surprising.

The second part of the trap is the illusion of progress. Hiring developers, showing a prototype, counting completed tickets — that's visible work. A CEO from an offline background is used to tangible results. Strategic work — research, interviews, modeling — looks like "people just talking." So development starts earlier than it should. Not out of stupidity — out of a habit of action.

What's Actually Worth Understanding Before You Start

The first thing worth doing is not asking your customers whether they need a digital product. They'll say "yes" out of politeness or "no" because they can't imagine something that doesn't exist yet. Both answers are useless.

What matters far more is understanding who you're actually competing with. And here's where it gets counter-intuitive. The main competitor of a digital service in a traditional industry isn't another service. It's habit. People have been solving the problem a certain way for years — through a trusted specialist, through a phone call, through "eh, I just won't bother." That inertia is stronger than any interface.

And recently, a second unexpected competitor has appeared: ChatGPT and similar tools, which already cover some of these needs for free, right now. For your product to beat "free and right now," it needs something that free doesn't have: client context, depth, trust, convenience.

Second — break down your own value chain and put numbers on it. Not in abstract terms, but literally: what does it cost to acquire a client, what does each stage of service delivery cost, where are the most expensive operations, where are the longest ones. When the chain is laid out and quantified, the picture almost always looks different from what the CEO imagined.

And sometimes it turns out the company doesn't need a customer-facing app at all — an AI assistant that drafts documents for specialists or auto-processes routine requests would suffice. That's not a digital product in the traditional sense. It's a change in cost structure that can deliver more impact than any app.

And third — talk to the people you don't usually talk to. Not executives, and not clients in the form of "would you like an app." Talk to the employees who work on the front lines every day — location managers, operators, the specialists who deliver the service.

They see where clients get confused, where processes break down, where the company loses money. They've often already invented workarounds — nobody just asked. In my experience, these conversations yield more product insights than any formal market study.

What AI Has Changed About Launching Digital Products

Until recently, even testing a product hypothesis required serious resources. You needed a team: a developer, a designer, a product manager. Infrastructure. Several months of development planned out. The minimum budget for a working prototype started in the tens of thousands of dollars — just to find out whether the market even needed it. Today, much has changed.

When I was launching Growly, an AI service for parents, I put off development for a long time. Not because I lacked an idea — but because the technical barrier to entry felt too high. Databases. APIs. Integrations. Architecture. Even a landing page on Tilda took days and never looked quite right.

All the talk of servers and deployment created the impression that you couldn't manage without a developer. And hiring a developer means time, money, and a management overhead that a non-technical founder is usually unprepared for.

One evening, I tried building a prototype with Claude Code. A working MVP on my phone appeared in about an hour. It was far from perfect, but it was already a live product, not a mockup in Figma. I spent another month refining it, a few hours each day — adjusting logic, tweaking the interface, adding features, refactoring, security, integrations, prompting. Working directly with the product, not with a specification for someone else.

But this doesn't mean developers are no longer needed. Architecture, infrastructure, integrations, UX — at a certain point, these still require specialists. The difference is that the cost of testing an idea has dropped by an order of magnitude. A founder with a clear vision can build a working product themselves, take it to market, and then decide based on results: scale, pivot, or shut it down.

And this changes the very logic of team-building. Launching a digital product used to mean: hire ten people, build processes, start sprints. Today, at the early stage, AI tools and one or two people in key roles are enough. Some code gets reused later; where needed, you bring in specialists surgically. A full development team appears not at the hypothesis stage, but at the scaling stage — when you already know what to scale.

I've written separately about how AI is changing not just individual tools, but the very model of how businesses interact with their customers.

But Here a New Trap Appears

Sometimes the accessibility of tools leads to the opposite extreme. If a product can be built quickly, the temptation is to just start building and see what happens. The logic seems airtight: since launching has become cheap, let's test more hypotheses, discard faster. Five concepts in a month, fifty in six months.

But customers are not a laboratory for experiments. Especially in a services business, where relationships are built on trust. If someone tries a half-baked product a few times and gets no value, they'll simply stop coming back. Worse — they'll stop taking you seriously. You can't approach your audience with thirty different offerings to see what sticks. By the third or fourth attempt, people stop responding to your messages. Trust is a resource that burns fast and recovers slowly.

This is especially critical for an offline business moving into digital. Your greatest asset is your reputation and the client relationships you've built over years. Every failed digital experiment your client encounters doesn't hit the "test product" — it hits your core brand.

So the sequence hasn't actually changed. First, understand who the product is for, what problem it solves, and why a customer would use it. Then build.

AI doesn't eliminate the need for strategy. It dramatically lowers the cost of validation — but what you need to validate is a considered vision, not random ideas. Think first, research, talk to people, form a hypothesis. Then — yes, test it in a week for next to nothing. Without hiring a team. Without spending hundreds of thousands on the first test. That's a fundamentally different economics. But the discipline of thinking remains the same.

When a Digital Product Actually Makes Sense — and When It Doesn't

The most honest test I know goes like this: can you name a specific customer behavior that your product will change?

Not "improve the client experience." Not "automate processes." But specifically: right now, the client calls and waits on hold for twenty minutes — and they'll get an answer in thirty seconds. Right now, a specialist spends three hours preparing a document — and they'll spend twenty minutes. Right now, the client leaves after the first purchase — and they'll keep coming back because the service remembers their context.

If no such change exists — if the product simply transfers an existing process into an app without fundamentally altering anything — it probably isn't needed. The customer won't use it, because they have no reason to change their habits.

And the change doesn't have to be customer-facing. Sometimes the strongest impact is internal. The company doesn't need a customer app. It needs an internal tool that changes the economics of every transaction: an AI assistant for specialists, business process automation, a system that reduces the cost of delivering a service. That's not a "digital product" in the conventional sense — but it can deliver more than any customer-facing application.

How to Start Building an AI Product for Your Business

When an offline business comes with an idea for an AI product, the task is almost never to start development right away. The task is to shift the conversation from "what we want to build" to "what a customer will actually pay for." And that means answering specific questions.

Why do we need this product, and what business problem does it solve? Not "build an app," but specifically: reduce service delivery costs through automation. Or shorten the repeat purchase cycle. Or create a new revenue channel. If you can't articulate the problem in one sentence, you're not ready to start building.

Who is this product for? Not "our customers in general," but a specific segment with a specific problem. Who are these people, what situation are they in, how do they solve the problem today, what frustrates them, would they pay for a different solution. Answering these questions without customer research — depth interviews, quantitative surveys — is impossible. Everything else is guesswork.

How are business processes currently structured? Where in the value chain are the most expensive operations? Which steps take a disproportionate amount of time? What are employees doing manually that they shouldn't have to? Often, the answer to "do we need a product" lies not in customer needs but in your own operations — in the cost of each transaction, in specialist workload, in manual routine that erodes margins.

Who is our real competitor? Not the one building a similar product, but the one solving the same customer problem. For a digital service in a traditional industry, the main competitor is the habit of doing things the old way. Or ChatGPT, which already covers some needs for free. Many teams focus on direct analogs and completely miss these alternatives.

How will it make money? A monetization model isn't "how much the subscription costs." It's value architecture: what's free to attract; what's paid to generate revenue; how revenue per customer grows over time. For some businesses, the best model isn't monetizing the product directly at all, but using it to reduce costs in the core business.

What level of investment is needed, and when do we expect returns? Unit economics across several scenarios, estimated CAC (customer acquisition cost) and LTV (total revenue a customer generates over their lifetime), payback horizon. Without this, any budget is just a number.

The answers to these questions aren't abstract "strategic work." They're a concrete set of actions: market and competitor analysis, depth interviews with clients from different segments, quantitative hypothesis testing, product vision development, business model design, go-to-market strategy. The output isn't a presentation — it's a document that anchors everything that follows: what we're building, for whom, how we make money, and how much we need to invest.

In practice, the depth of this work depends on the situation. Sometimes a full deep dive is needed; sometimes a quick validation is enough.

If there are many unknowns — the company is only thinking about a digital product, the market is unclear, customer segments haven't been studied — it makes sense to go through the full cycle. Comprehensive market and competitor research, including indirect competitors. Customer interviews. Quantitative validation. Product vision. Business model: monetization scenarios, economics, investment estimates, and payback horizon. Go-to-market strategy.

This takes several months, but the output is a clear understanding of what to build, in what order, and with what team. And most importantly — whether to build at all.

If there's strong market expertise but no confidence in the digital bet — you can start faster. In a few weeks, select one or two of the most promising customer scenarios where technology could deliver a real leap. In parallel — a quick market mapping: what already exists, which ideas are working, what can serve as a foundation.

Design the scenario and build a working MVP — not slides, but a product you can touch. Get it to a state where it can be shown to real customers. In three weeks, you have a working prototype and a concrete answer: is this worth serious investment.

Both approaches solve the same problem: making a decision based on data, not intuition. Sometimes a quick test makes it clear that full-scale research is needed. Sometimes it shows the product is ready to scale. Sometimes it reveals that nothing should be built — and that's a result too.

Either way, it costs a fraction of a year of building in the dark. I work in this format and call it Product-to-Market Sprint.