An investor leans back and asks: "If a competent team with AI coding tools tried to rebuild your product, how long would it take them?" You have heard versions of this question more often this year. It feels like a trap, because the honest answer for many early products is "not that long."
The short answer: be honest about the code, then explain what does not come with it. Code is cheaper to write than it was three years ago, and investors know that. What a competitor cannot copy in a month is your customer data, your integrations that took months of back-and-forth to get approved, your understanding of the edge cases that only appear in production, and your distribution. Answer the question by separating those things clearly.
Why investors are asking now
AI coding assistants have changed how investors think about software defensibility. A feature set that took a small team a year can, in some cases, be approximated far faster. That does not mean products are worthless. It means the value has shifted further toward the things that are slow to acquire.
This is a different question from whether your AI features depend on someone else's model, which is covered in AI moat diligence. Here the investor is asking about the whole product, AI or not.
Do not oversell the code
The weakest answer is "it would take years, our code is very complex." Experienced investors will discount it immediately, and some will test it by asking their technical advisor to look at your product for an afternoon. Complexity is also not a moat; it is often a cost.
Give a real estimate instead. Something like: "The core screens and logic, a capable team could rebuild in two to four months. Getting to where we are with customers would take far longer, and here is why."
What does not come with a rebuild
Walk through the parts that are actually slow. For most early-stage B2B products, it looks something like this:
Data that compounds
Historical customer data, usage patterns that power recommendations or benchmarks, labeled examples your models learn from. A competitor starts at zero. If your product gets better with more usage, show the evidence.
Integrations and approvals
Marketplace listings, partner API access, payment and banking approvals, healthcare or financial compliance sign-offs. Many of these take months of review regardless of how fast the code is written.
Production knowledge
The odd file formats one customer sends, the time zone bug that only appears in March, the retry logic for a partner API that fails every Tuesday. This knowledge lives in your code and your team, and it is earned only by running in production with real customers. A rebuild gets the happy path; you have the other 30 percent.
Distribution and trust
Customers who already put your tool into their workflow, the security reviews you already passed, the champion inside each account. Switching costs are a business moat, but they show up in technical form: how deeply you are wired into the customer's systems.
Evidence beats claims
Claims about moats are cheap. Bring evidence:
- The number of customer-specific edge cases handled in the last six months, from your issue tracker.
- How long your hardest integration or approval actually took, from first request to live.
- Retention or expansion in accounts with deep integration versus shallow use.
If you cannot produce any of this, that is useful to learn before an investor does. The prove the technical claim approach applies here: every defensibility claim in the deck should have something behind it.
When the honest answer is "fast"
Sometimes the product really is a thin layer that could be copied quickly, and the business has not yet built anything that compounds. That is not automatically a reason investors will pass, especially at pre-seed, but your answer has to change. Talk about the speed of your team, the insight behind the product, and what you plan to build that will compound, such as proprietary data, deep integrations, or workflow lock-in, and when.
What you should not do is pretend. The investor asking this question is usually trying to see whether you understand your own position.
Prepare the answer before the meeting
Spend an hour with whoever owns engineering and write down four things. First, an honest rebuild estimate for the core product, in weeks, assuming a strong small team using current tools. Second, a list of the integrations, approvals, and certifications you hold, with how long each one took. Third, the data you collect that a new entrant would not have, and whether the product actually uses it yet. Fourth, the three nastiest production edge cases you have handled, described in one line each.
That page does two jobs. It gives you a calm, specific answer in the room, and it shows you where the business is still thin. If the list of slow-to-copy assets is short, that is a roadmap input, not just a pitch problem.
FAQ
How should a non-technical founder answer this?
Ask your engineer for an honest rebuild estimate before the meeting, then focus your answer on data, integrations, production knowledge, and customers. You do not need to defend the code itself.
Is open-sourcing or using common frameworks a weakness here?
No. Using standard tools is normal and makes your team faster. The defensible parts of a business are rarely the framework choices.
Will investors run their own test?
Some will ask a technical advisor to review your product or try to sketch a rebuild. Assume it may happen and keep your answer consistent with what they would find.
Does a patent help?
Software patents are slow, expensive, and rarely the deciding factor at seed. Speak to a lawyer if you believe you have something genuinely novel, but do not lead with it.
If you want to pressure-test your defensibility answer before the meeting, a technical teardown gives you an outside view of what is hard to copy and what is not, or book a call to rehearse the question.