Short answer
Building is cheap now, which means your competitors can build too — so the product is not the position. Durable advantage comes from proprietary data that improves with use, a distribution channel others cannot access, being embedded in a workflow, or the customer relationship itself. Watch unit economics from week one: a product that calls a model has a real cost per use, so flat pricing fails precisely on your best customers. And decide the stop condition before you start.
What got easier, and what that did to the market
A functioning first version of a software product can now be produced in a fraction of the time and cost it took a few years ago. For anyone who has tried to get a product off the ground, that is a genuine and welcome change.
It also applies to everyone else. The barrier that protected an early product — that a competitor would need months and a team to copy it — has thinned considerably. The consequence is uncomfortable and worth sitting with: shipping first buys you less time than it used to, and the things that were always the real barriers are now a larger share of what determines the outcome.
An AI feature is not a position
The strategic error LYVIA sees most often in this category is treating the AI capability as the differentiator. Anything built on a public model is available to anyone else with the same API key, and the model providers keep absorbing popular use cases into their own products.
| Looks like an advantage | Why it is not | What compounds instead |
|---|---|---|
| A clever prompt or model chain | Reproducible by anyone who uses your product for an afternoon. | Proprietary data that gets better as customers use it. |
| Being first | Buys weeks now rather than quarters. | A distribution channel competitors cannot access. |
| A better interface | Copyable, and increasingly cheap to copy. | Being embedded where the work happens, so leaving costs something. |
| A broader feature set | Invites a focused competitor to beat you on the part that matters. | The customer relationship, and knowing their problem better than they can state it. |
None of the right-hand column is built in a sprint. All of it is built by shipping something useful to real customers and staying close to them, which is the unglamorous answer that the tooling revolution did not change.
The wrapper problem, and the ways out
A wrapper takes what the user typed, sends it to a model, and returns the result inside your interface with a subscription attached. It works, it demonstrates well, and it has no defense — the base model improves and absorbs the use case, or the customer works out they can do it directly.
Three exits exist, and they are all about owning something the model does not have.
- Data the model cannot see. Your customers’ own material, structured and retrievable — the mechanism is retrieval over company documents, and the defensibility comes from the data being theirs and staying with you.
- Integration into where work happens. A product that writes into the systems a team already uses is worth more than a better answer in a separate tab, and it is far harder to displace.
- An opinionated workflow. Not “ask anything” but a specific sequence that took domain knowledge to design and encodes judgement about what good looks like. That knowledge is what a competitor cannot copy from your marketing page.
Unit economics that behave differently
Classic SaaS economics rest on a marginal cost near zero: the tenth thousand customer costs almost nothing to serve. A product that calls a model breaks that assumption, and you do not have to take that on trust — model providers publish per-token rates, and Anthropic’s public pricing page is one place to read them. The break points the wrong way: your most engaged users are your most expensive.
Three consequences follow. Flat pricing fails exactly when you succeed, because the power users you wanted are the ones losing you money. A free tier is a variable cost rather than a fixed marketing budget, and it can be abused. And gross margin becomes something to actively engineer — through caching, through routing simple requests to smaller models, and through pricing that reflects usage at least in tiers.
Instrument cost per active account from the first paying customer, not when the invoice surprises you. It is a single number, it takes an afternoon to build, and it is the one metric in this category that LYVIA sees founders add too late most often.
Building from a services business
If you already sell services, you start with two assets that pure product founders spend years acquiring: a specific problem you have watched many companies get wrong, and people who will take your call.
That is a strong starting position, and it comes with its own failure mode. The tool you built for one client is shaped by that client, and the next three want it slightly differently. Saying yes to each variation produces a bespoke system with a subscription attached — the economics of services with the margins of software — the combination LYVIA sees go wrong most often.
The discipline is to say no to variation until a shape repeats across several customers, and to treat the first paying customers as evidence rather than as the specification. The same first-version logic applies as in commissioning custom software: narrow, real, and in use before it is widened.
What to build first, and what to fake
Build only the part that proves someone will pay. Everything around it — onboarding flows, admin panels, billing self-service, an analytics dashboard — can be done by hand for your first customers and nobody minds, because early customers care about the outcome and not the polish.
Doing that work manually also teaches you what to automate, which is the same argument the rest of this cluster makes about automating anything: understand the process by running it before encoding it, as in our process audit method.
One thing not to fake: security and data handling. Early customers forgive a rough interface and do not forgive their data being mishandled, and a startup has no reputation buffer to absorb it — the relevant practices are in our note on AI and cybersecurity.
Distribution is the actual project
If building takes weeks and selling takes years, then the plan should be mostly about selling. In the plans LYVIA reviews, most are mostly about building — because building is under your control and pleasant, and selling is neither.
Concretely: know before you start who the first twenty customers are and how you will reach them. “We will do content marketing” is not an answer — it is a category. An answer names the channel and why you specifically can use it: an existing client base, a community you belong to, a partner whose customers have this problem. Being found when buyers ask an assistant is now part of that picture and is a discipline of its own, covered in our guide to getting cited by ChatGPT.
Deciding in advance when to stop
Write the stop condition down before the first line of code, while you can still be objective: what has to be true after a defined period for this to continue.
A usable version is customers outside your existing relationships paying real money and continuing to use it. If that has not happened after a few months of genuine effort, the constraint is distribution, and building more product is the most comfortable available way to avoid discovering that. Deciding the condition early is what makes stopping a decision rather than a defeat.
If this turns out to be a distraction from the operating business, the alternative use of the same year is set out in our AI strategy roadmap.
Frequently asked questions
Can you really build a SaaS product with AI now?
You can build a working product far faster than a few years ago, and that is genuinely new. What has not changed is that building was rarely, in LYVIA's view, the reason software businesses failed. Distribution, retention and unit economics were, and none of them got easier — arguably distribution got harder, because everyone else can now ship a competing version in a couple of weeks of work.
Is an AI feature a competitive advantage?
Almost never on its own — LYVIA's view, not a published finding. Anything built on a public model can be replicated by a competent team quickly, and the model providers themselves keep absorbing features into the base product. Durable advantage comes from things that compound: proprietary data that improves with use, a distribution channel others cannot access, switching costs from being embedded in a workflow, or a relationship with the customer. The AI is the mechanism, not the position.
What is the wrapper problem?
A product that passes a user prompt to a model and returns the answer, adding a form and a subscription. It works, it demonstrates well, and it has no defense: the underlying model gets better and absorbs the use case, or the customer discovers they can do it directly. The way out is to own something the model does not have — your customers' data in a structured form, an integration into where the work actually happens, or an opinionated workflow that took domain knowledge to design.
How do the unit economics differ from ordinary SaaS?
Traditional SaaS has a marginal cost close to zero, which is why the model works. A product calling a model has a real cost per use, and heavy users cost more rather than less. Flat pricing therefore stops working exactly when you succeed with power users. Measure cost per active account from the first week, and design pricing around usage before growth makes the problem visible.
What is the advantage of building from a services business?
You already have the two things pure product founders lack: a specific problem you have watched many companies get wrong, and people who will answer the phone. In LYVIA's experience with services-to-product clients, that combination is the strongest starting position available. The risk is the opposite one — building the tool you needed for one client and discovering the next three want it slightly differently.
How do you know when to stop?
Set the condition before you start: what has to be true after a defined period for this to continue. As a working rule from LYVIA's own engagements rather than a published benchmark, if nobody outside your existing relationships has paid for it after a few months of genuine effort, the constraint is distribution rather than the product — and building more product is the most comfortable way to avoid finding that out.
If you are weighing turning a service into a product, the useful first conversation is about distribution and the stop condition — the build is the part we already know is possible. Book a call.
