If a customer can vibe code a version of your product, find out whether they also want to own its maintenance, exceptions, and operating risk. Their ability to reproduce the interface is a signal to investigate your value, not proof that your business is finished.
It is an uncomfortable conversation because it can sound like a verdict on months of work. A buyer says they made something similar over the weekend. Your instinct may be to explain everything they have missed. A better first response is curiosity: what did they build, what is it doing, and which part of the original problem remains?
Ask whether you are competing with a prototype
A prototype can be the right answer for a customer. It may serve a narrow internal workflow, use familiar data, and require very little support. Do not assume every internal tool will collapse under its own complexity.
At the same time, a screenshot reveals little about ongoing responsibility. Who restores deleted records? Who changes access when an employee leaves? Who notices that an integration stopped updating? Who handles a change in the underlying service?
GitHub's responsible-use documentation discusses limitations and the need to review generated suggestions. Generated code should be understood in the context of the wider application, not treated as a guarantee of correct operation. See GitHub's guidance.
That is not an argument against AI-assisted building. It is a reason to compare complete operating choices rather than the speed of creating the first screen.
Use the customer's decision as research
Ask to see the workflow, with their permission. Focus on the job and avoid requesting confidential information you do not need.
Useful questions include: what made building attractive, which parts were easy, what remains manual, who maintains it, and when would they prefer to buy again? The answer might be price. It might also be that your onboarding was excessive, your data model did not fit, or the customer only needed a small fraction of your product.
Write down the answer without immediately defending your roadmap. If several buyers independently build the same small feature and are happy, the market may be telling you that this feature is becoming easier to supply. Adding a dozen unrelated capabilities will not necessarily restore demand.
A hypothetical example: meeting follow-ups
Suppose your startup turns meeting notes into follow-up tasks. A customer creates an internal script that does the same thing for their own team. It works well enough and they cancel.
You could chase them with a cheaper subscription. Or you could discover whether other buyers face a harder problem: connecting follow-ups across client accounts, handling permissions, preserving approved wording, and showing whether commitments were completed.
This does not automatically justify building an enterprise suite. It identifies a different job to test. You might interview three account leads, offer a bounded manual pilot, and see whether the coordination work is important enough to pay for.
The example is hypothetical. The point is to avoid turning one cancellation into either a universal doom story or a reflexive feature expansion. Investigate the actual difference in needs.
Explain ownership costs without using fear
A buyer should not need a lecture about how software is secretly impossible. Show the specific work your service takes off their plate and the boundaries of that promise.
For example, describe supported integrations, recovery procedures, access controls, and the human support available. Show a sample failure state and how it is resolved. Avoid claiming unlimited reliability or implying that a nontechnical customer cannot make sensible choices.
Google describes toil as repetitive operational work without enduring value. Read the explanation. Compare that ongoing burden with the customer's first build.
Your commercial question is which recurring responsibilities the customer would happily delegate. Sometimes the honest answer will be none. Let that inform your target customer rather than treating every prospect as a conversion problem.
The failure mode: moving the goalposts
Founders can respond to a copyable feature by endlessly redefining their moat. Yesterday it was the code. Today it is the community. Tomorrow it becomes proprietary data that the company does not actually have permission to use.
Instead, write a falsifiable value statement: this buyer pays us to complete this recurring job, to this standard, while removing these named responsibilities. Test it against renewals, usage, and candid conversations.
A second failure mode is offering bespoke maintenance for every customer's generated application. That can be a legitimate service business, but price and position it as one. Do not accidentally inherit unlimited support obligations under a small software subscription.
A conversation worksheet
When a customer says they built it themselves, capture:
- The exact task their version completes today.
- The person responsible for maintenance.
- Their recurring time and service costs, if they are willing to share.
- The parts they deliberately chose not to build.
- Their acceptable failure consequences.
- The condition under which buying would become attractive.
Then make a decision: improve the offer for this segment, pursue a different segment, provide a clearly scoped service, or accept that building is sensible for them. A customer who can build is still a customer with limited attention. Earn that attention with a responsibility they want you to carry.