The working day is over, but the owner of a small installation company is still sorting through enquiries. A prospective client has sent photographs and a sketch, yet essential details are missing. Before anyone can prepare a quotation, the owner has to piece together the information and chase the unanswered questions.
This fictional example points to a practical opportunity for a software entrepreneur. An AI-supported service could organize the material and prepare the follow-up, giving the owner more time for the business. But would the relief be valuable enough to pay for, and could you deliver it profitably?
Those are the questions that turn an AI idea into a business proposition. Start with the work that causes a customer trouble, find out what a useful solution would be worth, and prove that you can deliver it. The agents come after that.
Why the focus is shifting from tools to outcomes
Recent research helps explain why this approach matters. As of October 18, 2026, the recurring issue is how to turn growing AI use into useful changes in the way a business works.
The OECD's April 2026 D4SME survey describes expanding use of ready-made AI applications and some experimentation with agents, while time, maintenance costs and skills hinder integration. Its non-representative sample of more than 2,000 SMEs across 12 countries offers insight into those businesses' experiences, rather than a population adoption rate.
McKinsey's October 5, 2026 analysis makes a related point: individual productivity gains do not automatically become business value. Workflows and responsibilities need attention too. For a solo entrepreneur, that means following a piece of work through to the customer, without importing the organizational machinery of a large enterprise.
The March 2026 working paper Mapping AI into Production examines that search in 515 high-growth startups. Firms shown examples of how others reorganized around AI discovered more applications; the authors also report customer-acquisition and revenue gains concentrated toward the stronger end of performance. As the HBS explanation clarifies, this tested a way of broadening the search for applications, not “agents versus no agents.” It does not predict the return for a typical local business.
For our installation-company example, the useful question is therefore quite specific: can we reduce the work of preparing enquiries at a price that works for both the owner and the service provider?
An AI-built MVP is only part of the product
That question is easy to lose sight of when social media celebrates another app built over a weekend. Treat these stories about AI-built minimum viable products (MVPs) skeptically as evidence of a profitable business. A polished demonstration shows what someone could build. It tells you much less about who will pay, how to reach them and whether serving them will leave a worthwhile margin.
AI can shorten production time and help with prospect research, sales material, enquiries and follow-up. It does not automatically create paying customers. Those activities become useful when they connect a credible offer with people who need it. More leads and more messages alone do not establish demand or trust.
Geoffrey Moore's “whole product” concept helps explain the gap. His guidance on positioning looks beyond the core technology to the services, support and complementary products a customer needs to achieve the promised outcome. For the installation company, that means fitting the existing enquiry process, helping staff get started and handling exceptions reliably. This builds on Theodore Levitt's 1980 discussion of product differentiation, which includes delivery, terms and support among a buyer's expectations.
A complete solution also needs a viable business around it: a way to win customers, price the offer and serve them at a sustainable margin. Steve Blank's Customer Development Manifesto therefore pairs customer development with agile development in the search for a repeatable, scalable business model. Technical readiness, a complete customer solution and commercial viability each need their own evidence.
Winning those first customers usually takes direct effort. Paul Graham's 2013 essay Do Things that Don't Scale describes the importance of recruiting early users and learning through close contact with them. Faster development leaves that work to be done.
So when an MVP success story catches your attention, look beyond the launch. Ask who paid, what it cost to acquire and serve them, and whether they stayed. A revenue screenshot leaves most of that unanswered. A fast MVP is useful when it helps test an offer with customers; repeat demand and the economics tell you whether to build a business around it.
Musk's distinction: digital work and moving atoms
The work surrounding a physical service is an interesting place to look. In The Joe Rogan Experience #2404, published on October 31, 2025, around 2:34:26, Elon Musk predicted that AI would take over digital jobs rapidly, while hands-on occupations would last longer. He contrasted computer-based work with “anything that's physically moving atoms,” naming welding, electrical work, plumbing, cooking and farming. The passage is also available in a timestamped transcript.
Musk also envisaged AI and robots eventually changing physical work, so his forecast gives trades no permanent protection. Nor is it an established timetable for job losses. The ILO's 2025 occupational-exposure study instead considers transformation more likely than complete replacement for most occupations, which combine tasks that still require human input. Potential exposure is different from actual displacement.
For an entrepreneur, a nearer-term opportunity is to help people do the work they already have. An assistant could prepare the information for a plumbing job while the plumber carries out the repair. The same idea could apply to administration in a restaurant or gardening business; gardening is our additional example here, rather than one Musk named. Whether such a service earns its fee depends on the customer's experience. That is where discovery begins.
Start with a recent incident
“Would you use an AI assistant?” usually produces opinions. Ask a prospective customer to walk through the last time the work went wrong.
For the installation company, useful questions include:
- Show me the last enquiry that needed several rounds of clarification.
- What was missing, who noticed it and what happened next?
- How much active work did this create, and how long did the customer wait?
- What do you already pay for software, administration or outside help?
- Who owns this problem, and who controls the budget for solving it?
- What would a satisfactory result look like in an actual customer file?
With permission, inspect a few completed cases and record the handling time, delays, clarification rounds and corrections. Keep personal information out of discovery notes wherever possible. An agent can help organize approved, redacted observations, but the founder needs to hear how the problem affects the customer's day.
Separate the user, beneficiary and buyer. An office assistant may lose the time; the owner may lose the evening; the owner or operations manager may authorize the purchase. Your offer needs to make sense to that buyer.
Turn those findings into a short working note: who has the problem, what triggers it, how they handle it today, what it costs and who could approve a purchase. Describe the desired result and the next paid experiment. Include reasons to abandon the idea too: perhaps enquiries are too infrequent, existing software already helps enough, or the proposed service does not fit the way customers work.
Commercial evidence becomes stronger when customers commit time, money and repeat business. Each step answers a different question; none guarantees the next.
Sell a small result that someone can accept
Once the problem is clear, turn it into an offer small enough to test. For our fictional company, that might read:
For one installation business, we turn up to 20 eligible enquiries per month into estimator-ready request packs. Each pack contains the supplied facts, source references, missing information and a draft clarification message. Your team approves every outgoing message and quotation. The trial runs for four weeks with an agreed scope and fee.
The phrase “estimator-ready” gives you something concrete to agree on. Required fields must contain supported facts or be marked missing where the checklist allows it. Material facts need source references; dimensions must never be guessed from photographs. Unreadable attachments and unusual requests need human handling. The estimator should be able to use the pack for the next step.
Agree on the input channel, supported documents, turnaround, volume, price and exceptions. Promise something you can assess, such as the completeness and timeliness of the pack. A promise to increase quotation conversion would require evidence about many more factors.
You can deliver the first version manually with AI assistance, learning what the customer needs before building integrations. Payment for a useful result is stronger evidence than enthusiasm for a demonstration. Renewal at a sustainable price is the next test.
Give agents bounded responsibilities
The offer tells you what to automate. One step extracts candidate facts, another checks for gaps and contradictions, and a third drafts the clarification message. Ordinary application logic handles case identifiers, deadlines, permissions and status changes.
These responsibilities can be implemented with one model, a few calls or more specialized components. Choose the simplest arrangement that works. Anthropic's engineering guide Building effective agents makes this distinction between predefined workflows and agents that direct their own process. It offers useful design guidance, rather than evidence of business returns.
In the proposed process below, incomplete drafts go to a person for completion, and every pack is reviewed before delivery. Record the effort and corrections along the way: the cost of recovering from a failed attempt belongs to the service too.
Proposed BPMN 2.0 process: the provider prepares and reviews the pack, then exchanges messages with the customer. An editable model is included in the toolkit; it has not been run in a process engine.
The UML sequence shows the handover more closely. The AI component prepares a draft or reports an exception; the owner completes the review and delivers the result.
Illustrative UML sequence. Delivery is a human action in this design. Customer acceptance is recorded separately from successful technical processing.
Before deployment, the service also needs controls for customer data, tool access and instructions embedded in uploaded documents. Keep records of inputs, outputs, reviews and delivery, and resolve an uncertain sending outcome before retrying. These are requirements for the proposed design; the toolkit does not implement production connectors or test live-model accuracy.
Define “done” before an agent starts
The handover needs a clear standard. An agent may say “done” after producing a file or receiving a successful tool response, even though the result still needs work. If that goes unnoticed, the customer inherits the corrections and the provider loses time and margin.
A Definition of Done (DoD) makes that standard explicit. The 2020 Scrum Guide uses the term for the quality requirements an Increment must meet. We can adapt the idea to this service by agreeing on a baseline for every request pack, alongside case-specific acceptance criteria such as the fields required for a particular installation. This is a proposed application of the idea to agent work, rather than an agent-specific Scrum rule.
For the proposed pilot, a request pack is ready for owner review only when:
- The scope is clear: the customer, enquiry, input set and checklist version are identified.
- Facts are traceable: material facts have source references, gaps and contradictions are visible, and guesses are not presented as facts.
- Checks have evidence: actual check results are retained with the pack version. Use deterministic checks where possible and human review where judgment is needed.
- Exceptions are handled: unreadable input, unresolved conflicts and failed checks route to manual handling. Reaching a deadline or retry limit does not make the work complete.
- The handover is usable: the owner can open the pack, see the proposed clarification and understand the next action. No message or quotation has been sent without authorization.
When several steps or agents contribute, pass that evidence along with the work: the artifact version, check results, open issues and next responsible person. Otherwise, “draft produced” can quietly become “customer request resolved.” Anthropic's account of long-running agent harnesses describes premature completion as a practical failure mode addressed through explicit requirements and verification. Those practices help make progress inspectable; a checklist alone cannot guarantee reliability.
Keep ready for review, delivered and customer accepted separate. The first requires the checks above; the second requires owner approval and a recorded delivery outcome; the third requires the agreed customer response. If delivery times out ambiguously, resolve what happened before marking it complete or sending again. Manual recovery may still produce a successful case, but the extra effort must remain visible.
Agree on the rules before execution and version them as the service changes. An agent must not weaken a criterion to make its own work pass. The toolkit includes a proposed DoD checklist; enforcing it requires controls beyond the example calculator. This gives us a basis for the economic calculation: count the accepted results as outcomes, and include every attempt, review and recovery in the effort.
Make the economics work on both sides
Now put a price on that work. The following fictional monthly EUR figures exclude VAT and taxes; they illustrate the calculation, rather than measured savings or a recommended price.
Suppose the installation company handles 20 eligible enquiries a month, spending 30 minutes on each. With the service, that falls to 10 minutes, including checking and corrections. Valuing the released time at EUR 45 per hour gives EUR 300 per month. Another EUR 120 of separately documented avoided rework brings the estimated customer value to EUR 420.
At a monthly fee of EUR 299, the customer would retain EUR 121 of that estimated benefit. The time saving becomes useful if it avoids expenditure, creates room for productive work or provides relief the owner values. It is not automatically a cash saving. Also check that the EUR 120 rework benefit does not count time already included in the handling reduction.
On the provider's side, two hours of delivery and review at EUR 60 per hour account for EUR 120 of economic cost. Add EUR 20 for tools and all model attempts, plus a separate EUR 40 support allowance. The total variable cost is EUR 180 per customer, leaving EUR 119 to contribute toward fixed costs.
If recurring fixed economic costs are EUR 600, six customers are needed to cover them. That leaves just EUR 114 a month after the modeled costs, a narrow buffer. Owner time is already included, so this figure should not be confused with revenue or total take-home income.
Small changes show how fragile the offer could be:
- Double delivery effort: four hours instead of two produce EUR 300 variable cost and a EUR 1 loss per customer.
- Only five customers: contribution totals EUR 595, leaving a EUR 5 monthly shortfall against fixed costs.
- No separate rework benefit: customer value falls to EUR 300, leaving only EUR 1 above the fee.
This is why the pilot should measure exceptions, customer checking, support and failed attempts. A faster draft can still create more work somewhere else.
Keep one-off setup work separate: a EUR 600 setup fee that covers EUR 600 of effort adds nothing to recurring margin. Include acquisition effort either in fixed costs or in a separate acquisition calculation, without counting it twice. Finally, track actual receipts and payments alongside these economic estimates. Valued owner time, invoiced revenue and available cash are different measures.
Let the pilot decide what happens next
Use the first paid pilot to replace the assumptions with observations. A four-week experiment could work like this:
Week one: understand one segment. Speak with a few prospective buyers, perhaps five, and inspect recent cases to establish a baseline. Treat those conversations as a starting point. Identify who can buy and why they would act now.
Week two: sell a bounded pilot. Agree on the fee, scope, acceptance checklist, data handling and review responsibilities. Include ordinary cases and known exceptions so the economics reflect the work you will actually receive.
Week three: deliver and measure. Record accepted packs, handling and correction time, turnaround, founder effort and cash costs. Compare cases of similar complexity and note changes in staffing, volume or document quality. A small before-and-after comparison informs your decision without proving that the service caused every difference.
Week four: discuss renewal. Review the results with the customer and ask what they would miss if the service stopped. Find out whether they will renew at the intended price. Then check your own capacity: can you deliver reliably to the number of customers the business needs?
Continue when the work is useful to the customer, the economics survive realistic setbacks and repeat demand looks reachable. Redesign if recurring exceptions consume the margin. Stop if the problem matters too little, the buyer will not pay enough or the service merely shifts work onto them. Learning that early can save a much larger investment.
Beyond the pilot, watch renewal, support effort, concentration risk and acquisition cost. Six customers on a spreadsheet do not constitute six reachable customers. One large account can also dominate both revenue and interruptions. Keep interviewing customers after the first sale: their priorities and alternatives will change.
Optional toolkit: explore the example
If you want to vary the figures, the optional toolkit includes a small Python calculator with run instructions, the proposed DoD checklist and editable BPMN/UML models. The calculator reproduces the example and stress scenarios and has 20 passing tests. It checks arithmetic using human-supplied assumptions and evidence flags; it neither runs agents nor verifies customer demand or DoD compliance. You can follow the same calculation in a spreadsheet, without programming.
Build the business around the customer outcome
The installation-company owner does not need to know how many agents prepared the enquiry pack. They need the information to be usable, the follow-up to be reliable and the service to be worth its price.
That is the foundation for the organization discussed in our earlier articles on AI-supported solo businesses and a versioned business manual. First find work a customer values enough to buy. Then build a reliable way to deliver it, measure what it takes and learn whether they want it again.