Buy a working first release, not a convincing demo
An AI MVP is a minimum viable product that uses AI for a specific user task. It needs enough working software to test that task with real users. A generated screen, clickable prototype, or successful model response can help you learn, but does not by itself prove that the product can save work, enforce permissions, handle failure, or operate after launch.
This guide is for founders and company teams deciding what to build and what to ask a delivery partner. Kings Landing's recommendations below are a buying framework, not a fixed package, price, or delivery promise.
1. Agree the first release before choosing tools
Start with one user group and one job. Write down the input, the useful output, and what happens next. Decide what AI should do and what ordinary software rules should enforce. Required fields and access checks should not depend on a model following a prompt.
Include the complete path for that job. If someone uploads a document, the first release may need upload validation, saved results, editing, and a clear retry path. Those are part of delivering the job, not optional polish.
Keep unrelated roles, channels, reports, and automations out of the first release unless the core task depends on them. Put them in an explicit later list so different suppliers quote the same work.
An example first-release brief
This is a hypothetical support-drafting product, not a Kings Landing client result.
- User: A support teammate preparing replies.
- Input: One customer question and an approved knowledge source.
- AI task: Suggest a reply with references to that source.
- User action: Edit and approve the suggestion.
- Saved result: The accepted reply and its source references.
- Failure path: Keep the question available for a manual reply.
- Not included: Automatic sending, every help-desk integration, or a new customer portal.
This brief makes a useful boundary. It also exposes the questions that need answers before a builder can estimate the work.
2. Choose the build approach around the unknowns
There is no universal best stack for an AI MVP. An existing product, available data, and a simple user task can change the sensible starting point.
| Approach | When to consider it | What to verify |
|---|---|---|
| Extend | Your current app already handles the user journey and records. | Access to its code, data, and integration points. |
| New app | Users need a separate working interface and workflow. | Accounts, storage, permissions, testing, and deployment. |
| Validate | Useful output or data quality is still uncertain. | A bounded test and the decision that justifies a full build. |
A prototype can test interaction choices. A model experiment can test output quality. Neither should be sold as a deployed application without the rest of the agreed scope.
Kings Landing works with Lovable, Webflow, Claude, and Ploy. Those names are not a substitute for a build plan. Ask which tool handles the interface, stored records, AI calls, integrations, and hosting. Also ask which requirements would need a different approach.
For example, Lovable's publishing documentation separates publishing an app from reviewing security findings. A live URL is a release step, not evidence that every product requirement has been tested.
3. Check data access and integrations early
List the information the AI needs, where it lives, and who can authorize its use. Bring representative examples, including incomplete or awkward inputs. A clean demo document may hide the work needed for actual customer data.
For each connection, specify whether the product only reads information or can also change it. Agree how accounts are connected, what happens when access expires, and how the user knows whether an action succeeded.
A read-only draft and an automatic update to a business system carry different consequences. Do not let a proposal describe both simply as an "AI integration."
Ask how private data, credentials, and permissions will be handled. If the chosen backend is Supabase, its production checklist calls for appropriate database access policies, load testing, and availability checks. This is a platform-specific example, not a claim that every Kings Landing build uses Supabase.
4. Define acceptance tests before the demo
Agree what the team must demonstrate before you accept the first release. Test the application journey and the AI output separately.
For the application, check that a permitted user can complete the task, the result stays saved, and a different user cannot access restricted information. Test retries and failures as well as the successful path.
For AI output, collect realistic examples and define what makes a result usable. That may mean correct fields, relevant source references, an acceptable response time, and a clear indication when the evidence is insufficient. Set targets from actual tests and the consequence of error, not a promised accuracy figure.
Anthropic's evaluation guidance recommends specific, measurable, relevant success criteria and task-specific tests that include edge cases.
Keep review behavior in scope when people must approve results. Our human-controlled AI workflow guide covers that design in detail. It is a separate topic from buying and launching the application.
5. Compare build cost with operating cost
A useful estimate separates the initial build from what it costs to run and change the product. Do not compare quotes using only the headline total when they assume different data, integrations, or support responsibilities.
| Cost area | What changes the work or bill | Ask the builder |
|---|---|---|
| Build | User roles, screens, data preparation, and testing. | What is included and explicitly excluded? |
| AI use | Model choice, input and output size, and repeat attempts. | How will usage and spend be measured? |
| Connect | Access requirements and each external system's behavior. | Which connections are included? |
| Operate | Hosting, storage, monitoring, fixes, and product changes. | Which fees and responsibilities continue? |
Anthropic's API pricing distinguishes input and output tokens and additional feature charges. A subscription used to help build software is not the same budget as the product's ongoing model usage.
Ask for the assumptions behind the operating estimate, including expected task volume, input size, and retry behavior. Request a spending limit or alert plan appropriate to the chosen services. No universal budget or delivery timeline is reliable before the scope and dependencies are understood.
6. Agree launch, ownership, and support
Before launch, identify who controls the domain, hosting, database, model account, and connected services. Ask what access, documentation, and data export options you receive. Record any platform restrictions instead of assuming every part can be moved elsewhere without work.
Agree the release process, how problems are reported, and who can restore a previous working version. Where backups are available, confirm what they cover and how recovery will be tested. A backup that excludes uploaded files may not restore the whole product.
Separate fixes for the agreed release from new features. Define the maintenance arrangement, response expectations, and how improvements are scoped. A support promise without those boundaries is hard to compare.
Kings Landing's AI product development services include working web apps and MVPs, AI integrations, deployment, and ongoing maintenance and support. The responsibilities for your particular product should be agreed before delivery starts.
Your checklist before committing
A proposal should make these questions answerable.
- Who is the first user, and what complete task will they do?
- What is included in the working release, and what will wait?
- Which data and accounts are needed before work can start?
- Which integrations read information, and which change it?
- What tests define an acceptable application and AI result?
- What happens when an upload, AI call, or connection fails?
- Which initial, third-party, and ongoing costs are separate?
- Who controls the product's accounts, records, and deployment?
- What fixes and support are included after launch?
If key answers are missing, narrow the scope or resolve the uncertain dependency before approving the build. The checklist is Kings Landing's synthesis; the linked platform documentation supports the specific technical examples, not a guaranteed outcome.
Discuss your first release
Tell Kings Landing who the product is for, what it needs to do, and which data or tools it must connect. We can discuss a working first release, deployment, and support. Discuss your product.
