First Enterprise Customer for a Solo AI Product
A large company emailed about your side project. Three questions to send back before you spend eighty hours finding out it was research.
First Enterprise Customer for a Solo AI Product
The first enterprise customer for a solo AI product usually arrives as a short, flattering email from someone with a job title you cannot place. Before you answer it as a win, price it as a cost. A serious enterprise sale takes a solo founder somewhere between 40 and 120 hours across security review, legal, procurement and onboarding, most of it before any money moves. That is worth it for some deals and ruinous for others, and you can usually tell which within two replies.
Answer these three questions before anything else
Reply to the first email with genuine interest and three questions folded into it. The answers, or the absence of them, tell you nearly everything:
Who else needs to approve this? If they cannot name anyone, you are talking to someone exploring, not someone buying.
Is there a budget line for this already, or would it need to be created? A new budget line adds a quarter, minimum.
What happens if they do nothing? A concrete answer means a real problem. A vague one means you are a nice-to-have.
A contact who answers all three crisply is worth your 80 hours. One who answers none is a researcher building a comparison sheet for a decision that was made before they emailed you, and the correct response is a helpful reply, a link to your docs, and no further investment.
What a small vendor actually gets asked
The security review is the part that surprises people. A company with more than a few hundred staff will send a questionnaire that assumes you are a company rather than a person, and it will ask things your product genuinely does not have yet:
They ask for | What a solo product usually has | Honest answer |
|---|---|---|
SOC 2 Type II report | Nothing | Not yet, here is the roadmap and the compensating controls |
Named security contact | You | You, by name, with a response-time commitment |
Sub-processor list | Never written down | Write it: model provider, host, email, analytics |
Data retention policy | Whatever the default is | Decide it, document it, then implement it |
Penetration test | Nothing | Offer a recent dependency and code audit instead |
The instinct is to bluff. Do not. A wrong answer on a security questionnaire is a contractual representation, and it is discovered at the worst possible moment. The winning move for a small vendor is a fast, specific no with a mitigation attached, which reads as competence rather than weakness. Our walkthrough of getting an AI product through a client security review covers the questionnaire in more depth, and whether SOC 2 is worth it at your stage covers the certification question specifically.
The sub-processor list deserves its own note, because it is the one small AI products consistently fail. If your product sends customer text to a model provider, that provider is a sub-processor, and enterprise contracts require you to disclose it and often to notify before changing it. You will be asked. Have the list written before you are.
The three ways this deal goes wrong
The pilot that never ends
They propose a free or nominal pilot to prove value. Six months later you have built three custom features and invoiced nothing. Fix this at the start: a pilot has a fixed length, a stated success criterion, and a price, even a small one. A buyer who will not pay anything for a pilot will not pay for the product.
The one-customer product
The deal is real, the money is real, and every requirement they add pulls your roadmap toward a product only they would buy. Six months on you have a consulting business with one client and a codebase nobody else can use. This is the exact trap in when your biggest customer wants a custom feature, and the defence is to decide in advance which requests are product and which are paid custom work.
The contract that eats your margin
Enterprise paper arrives with uncapped liability, 90 day payment terms, a right to audit, and an SLA with credits attached. Each of those is negotiable, and a solo vendor has more leverage than they believe, because the buyer has already spent internal effort choosing you. Cap liability at fees paid, push payment to 30 days, and never sign an availability SLA you have not measured yourself.
Whether a solo AI product should take its first enterprise customer
The case for yes is not the revenue. One enterprise contract is rarely transformative money for a solo product, and the hours it consumes would often generate more selling to twenty smaller customers. The case for yes is that it forces you to build things you were going to need anyway: SSO, an audit log, a data deletion path, a real uptime story. If those are on your roadmap regardless, an enterprise deal funds and schedules them.
The case for no is when the requirements are specific to that one buyer and nothing they ask for makes the product better for anyone else. A single-tenant deployment in their cloud, their compliance regime, their identity provider, and none of it reusable. That is a services contract wearing a product costume. Price it as services if you want it, and read when a customer wants a self-hosted AI tool before agreeing to anything that ships your code into their infrastructure.
A practical rule: say yes if at least half of what they need is on your roadmap already, and say no, politely and with a referral, if less than a quarter of it is. The middle is a judgement call about whether you want to be an enterprise company at all, and that is a real choice rather than an obvious one. Declining well is worth doing properly, because the person who emailed you will move companies and may well email again from the next one.
How to quote it
Price higher than feels comfortable. Enterprise buying processes treat an unusually low number as a signal of risk rather than value, and the cost of your time through procurement is real and should be in the price. A reasonable starting point is your normal annual price multiplied by three to five, with the multiple justified by the specific things enterprise buyers get: the security work, the contractual commitments, the named support path. This is a different exercise from setting your public price, which we cover in the wider guide to making money from an AI product.
Ask for annual, paid up front, for a first enterprise deal. It removes the working capital problem that 90 day terms create for a one-person business, and the discount you offer for it is cheaper than the alternative. The broader mechanics of offering an annual plan apply here with more force than usual, because a solo founder feels a cash gap that a funded company simply absorbs.
Frequently asked questions
Should a solo founder sell to enterprise customers at all?
Only when the buyer's requirements overlap what you were going to build anyway. If at least half of what they ask for is already on your roadmap, the deal funds work you wanted. If almost none of it is, you are being paid to build a product for one customer, which is a services business with extra steps.
What do I say when they ask for SOC 2 and I do not have it?
Say so directly, then describe what you do have: your data handling, your sub-processors, your access controls and your incident process. Many buyers accept a documented security posture from a small vendor for a low-risk use case. A bluffed answer becomes a contractual representation you cannot support.
How much should I charge my first enterprise customer?
Typically three to five times your standard annual price. The multiple covers the security review, the contract negotiation and the named support commitment, all of which are real costs that your self-serve price does not include. Quoting near your self-serve price signals risk rather than value.
Is a free pilot a good idea for a first enterprise deal?
No. Give a pilot a fixed length, a written success criterion and a price, even a nominal one. A paid pilot forces the buyer to secure internal approval, which is the single best signal that a real budget exists behind the conversation.
What contract terms should I push back on?
Uncapped liability first, since it is the one that can end you. Then payment terms longer than 30 days, any availability SLA you have not actually measured, and unilateral rights to audit your systems. Capping liability at fees paid in the preceding twelve months is a standard and usually accepted ask.
How did this land?
About the author

Growth & SEO Lead
Manuele covers distribution: SEO, content strategy, and how AI-built products find their first thousand users. He tests everything he recommends.


