Taking an AI startup's MVP to production

The context

A startup launched an AI platform that helps people create content. The product is live, it has its first users, and the founding team has no technical department able to absorb fixes, product changes and integrations all at once. A product that is alive is a product whose needs never stop.

The platform was built with Lovable, which got them quickly to a version they could show and sell. The startup’s people are now busy with marketing and advertising: they cannot run product development and brand building side by side.

The challenge

A product to grow continuously, with no internal technical team. Four strands, run in parallel.

Making the existing product reliable

A dozen targeted fixes. The founder could no longer maintain the product with Lovable: a change in one place broke something in another, and they lacked the technical bearings to settle architecture questions.

This is the typical situation of people using these tools: entrepreneurs with good ideas and without the technical skills to build them. Lovable removes a real barrier and gets you to a working prototype very fast. Architecture, performance and search visibility still call for a developer.

Improving the quality of the AI results

This is where the product’s perceived value sits. The work goes into structuring the instructions sent to the model, into the settings, and into processing written upstream to prepare the data before it is sent.

Most of our clients have a hazy idea of what AI actually is. It is taken to be somewhat magical, sometimes even to reason like a person. That impression comes from conversational interfaces, which made the technology accessible by hiding entirely how it works. Today’s models are impressive and remain algorithms: understanding what they can and cannot do is what makes their output dependable. We were testing the first large language models back in 2022, when they were still a developers’ curiosity.

Reworking the interface

A generation tool produces either a standard interface or exactly what it was asked for. In the first case it does not fit the need; in the second it stacks features up over successive iterations, as the idea takes shape. Both end up in the same place: an interface that has become a contraption.

We reworked that interface from a full, priced audit, delivered as a report with interactive mockups. The client approves the mockups, then we build. Adjustments happen on the mockup, before any development.

Assessing and pricing third-party integrations

Video avatar generation, speech synthesis, automatic subtitles. The client hears about a service, wants to integrate it, and does not know whether it is the best on quality or on price, how far they will be able to go with it, or what it will cost.

Working with APIs is our daily job. We analyse what a service genuinely allows, and we go beyond the one we are handed: we look for the competitors and compare them on the criteria the client gives us, price, availability, GDPR compliance, where the data sits. We test the products before giving an opinion, and the report is not a comparison produced by an AI that nobody read. No risk of finding out halfway through the build that what was planned is not possible.

What we did

• A dedicated support channel. The engagement runs over time: the support address is wired into our request tracking tool. Every request is logged, numbered and followed, instead of getting lost in an email thread.
• A feasibility study before each heavy topic. For integrations, a written analysis, comparison and price, handed to the client to decide on. They only commit to a build knowing what it involves.
• A documented UX and UI audit, then an iterative rework, tested and adjusted against feedback and usage statistics.
• A pace that suits a startup. Small batches, approval at each step: the team moves forward while the client tests.

The outcome

For several months now, this client has had a technical team behind their project: fixes, product changes, integrations and continuous improvement of the AI, without hiring. The product moves at a steady pace, and every topic is logged and priced before it starts.

What this case shows

• An MVP that finds its users needs more than a repair job: it needs a product partner over time.
• A written feasibility study protects the budget: you price before you code, rather than setting off blind.
• Ticketed support turns an email relationship into a trail both sides can follow.