AI product development, by a team that ships its own
We have launched four products of our own, from a voice assistant for Mac to an AI interior design tool to a typing trainer for programmers. Each taught us where AI products really fail: not in the model, but in the cost per user, the onboarding, and the billing page nobody planned for. The honest version of those lessons is in four products in, what we got wrong.
An AI MVP with us is a product, not a prototype. It is positioned, designed, built around the model with the boring parts done, and launched to real users within 12 weeks.
The thing that makes AI products different
Ordinary software has a marginal cost near zero: one more user costs you nothing meaningful, so growth is margin. An AI product pays a bill on every single use.
That one difference reorders the whole build. A flat monthly price against per-request costs means a heavy user can cost more than they pay, and enthusiasm becomes a loss rather than a win. So pricing is a product decision made in week one, alongside the model choice, rather than a finance question deferred until launch.
Decornoa is our clearest example. Its hard problems were generation cost, queueing under load and quality control, not whether the rooms looked good. That is typical, and it is why we design the economics before we build the feature.
What actually goes in an AI MVP
The AI is usually a fraction of the build. The rest is what turns a feature into something people pay for.
| Part | Why it is not optional |
|---|---|
| Sign-up and onboarding | The first five minutes decide adoption, especially when you must ask for data or permissions |
| Payments and plans | Including declines, refunds and a plan that survives a heavy user |
| Per-user cost controls | Rate limits, caching and a cheaper model for simple steps, or growth hurts |
| An evaluation set | So you can tell whether a model change made the product worse |
| Admin and analytics | You cannot improve what you cannot see, and week one is when to instrument it |
| The AI feature itself | Genuinely the part we worry about least |
Should you use no-code instead?
For testing demand in a fortnight, no-code is often the smartest first move, and we will say so rather than sell you a build. A landing page with a manual process behind it answers "does anyone want this" faster and cheaper than any MVP.
It stops working sooner for AI products than for ordinary ones. Usage costs money from the first user, so you need cost controls, model choice and rate limiting earlier than a normal product would, and those are exactly the things no-code platforms abstract away from you.
Our AI MVP development process
- Define, week 1. The job, the buyer, the smallest provable version, the model options and their cost per user. A fixed-price plan.
- Design, weeks 2 to 3. Flows, screens, identity, and a clickable prototype you can show to first users.
- Build, weeks 4 to 10. The product, weekly demos, an evaluation set for the AI parts, and analytics from day one.
- Launch, weeks 11 to 12. Store or web launch, feedback loops, and the first round of improvements.
Timeline logic, and what stretches it, is covered in how long does it take to build an MVP, and the cost of each size of first version is in our MVP development cost guide. The largest variable is not our speed; it is how fast decisions come back.