AI product development FAQ
Kings Landing builds working web apps and MVPs, connects AI workflows, deploys the release, and provides ongoing maintenance and support. People stay responsible for accepting AI results.
Discuss your buildThese answers describe our published service scope and workflow guidance. Ownership, provider data terms, hosting, and support commitments need agreement for your project.
Build and handoff
What can Kings Landing build for us?
We build working web apps and MVPs for founders and companies, including AI integrations and connected workflows. Our services also cover deployment and ongoing maintenance and support. The first release is scoped around your users, core journeys, data inputs, and integrations. Research, design, and prototypes guide the build. The specific features and delivery commitments belong in the agreed project scope.
How does an MVP move into maintenance or a team handoff?
Our published process continues from the first working release into deployment, maintenance, fixes, and further improvements. Before launch, agree who runs the product and accepts changes, which accounts and integrations need access, and what documentation or knowledge transfer your team needs. Those are handoff requirements to scope, not a standard package promised on our site. For AI workflows, include review roles, permission rules, evidence sources, correction paths, and recovery procedures so the next team can maintain the decisions as well as the screens.
Who owns the code, design, accounts, and product data?
Ownership and access need a written project agreement. Our public service pages do not state a universal IP-transfer or source-code ownership policy. Before work starts, agree rights to code and design deliverables, control of platform accounts and repositories, access to product data, and any export or transfer requirements. Identify third-party licenses and subscriptions separately. Our offer includes building and supporting products; it does not by itself establish what you own or how every platform can be transferred.
How do you use Lovable, Webflow, Claude, and Ploy?
We work with Lovable, Webflow, Claude, and Ploy according to the product and agreed scope. We do not prescribe the same combination for every build. Agree which tool handles which part of your product, what it may access, where the release will run, and what your team can maintain afterward. Our workflow guidance treats AI output as a proposal where human acceptance is required. Naming these tools is not a claim of certification, partnership, a particular paid plan, or an automatic no-lock-in guarantee.
Human control and data
Who decides whether an AI draft becomes an accepted record?
The person assigned that responsibility decides, not the model. Our workflow guidance separates AI drafts, review, submission, and approval so users know what has changed and what happens next. Review requirements depend on the consequence of an error and whether an action is reversible. A confirmation button alone is insufficient. People need supporting evidence and a practical way to correct or reject the proposal. In our documented BauBau design, people review, correct, and submit AI-assisted entries before authorized approval.
What evidence should people see when reviewing AI output?
Our guidance recommends showing the relevant photo, note, or document beside the proposed field and distinguishing supplied information from generated interpretation. Missing evidence should be visible; fluent wording is not proof. BauBau's documented design connects photos, versions, reviews, and amendments to the record they support. Your project must define which sources and versions are needed for review. This is a traceability approach, not a promise that every generated statement is correct or independently verified.
Can people correct, reject, or regenerate a wrong result?
Our workflow guidance calls for different paths for editing a small error, rejecting an unusable proposal, and regenerating after inputs change. Regeneration should explain what will be replaced and preserve a way back to earlier work rather than silently erasing human corrections. Shared editing also needs an explicit conflict policy. We recommend testing a deliberately wrong field before building. The correction, version, and conflict behavior for your product needs to be included in its requirements; the guide does not claim every suggested feature has shipped in BauBau.
How are permissions handled for people and connected agents?
Define who may create, review, submit, approve, amend, and export each record. Our guidance assigns permissions to roles rather than prompts and includes technical permission checks, not just interface labels. A connected agent should receive only the information and actions its role permits. BauBau's design shows role-bounded project visibility and human confirmation. Rules such as whether someone may approve their own work are decisions to resolve with your organization, not a universal policy. Implementation and verification must match your agreed scope.
What data can AI tools access, and where does it go?
Data boundaries must be agreed for the specific product and providers. Start by naming the inputs AI may receive, the records and actions each role may access, and what must stay outside the workflow. Before using sensitive data, confirm storage locations, retention, deletion, provider processing, model-training terms, and any required contractual safeguards. Our site describes input and permission boundaries but does not publish a blanket data-residency, no-training, or compliance guarantee for Lovable, Webflow, Claude, or Ploy. Using a named tool does not settle its data terms.
What happens if generation, uploads, or synchronization fail?
Our guidance puts recovery beside the successful path. A generation failure should preserve the person's input and offer a manual path. An upload failure should distinguish local, queued, and server-received files. A retry should make completion and possible duplication clear. An unsupported AI conclusion needs a rejection path even if no technical error occurred. Sending a report outside the product requires a separate decision about recipient and content. BauBau's design documents offline drafts, upload states, retries, and conflict handling; the exact recovery behavior is scoped and tested for your build.
Launch and support
Do you deploy the product, and what needs agreement before launch?
Yes. Deployment and launch are part of our published service offer. Agree the release scope, hosting and account responsibility, integrations, operating costs, and who authorizes the launch. Define the recovery approach and any required backup or rollback behavior for that product rather than assuming it is included. Our Services page describes testing core journeys, human review, permissions, and failure states during the build. It does not specify one hosting provider, a universal deployment architecture, or a standard uptime guarantee.
What ongoing maintenance and support do you provide?
Our offer includes maintenance and support after launch, with fixes and further improvements agreed as part of the project scope. Confirm what is covered, who reports and prioritizes issues, who can approve or deploy changes, and how provider or integration changes are handled. Support hours, response times, fees, monitoring, and incident responsibilities need explicit agreement. The public offer does not promise 24/7 cover or a fixed service-level agreement. For AI workflows, maintenance should preserve the agreed review, correction, permission, and recovery rules as the product changes.
What project evidence can we review before hiring you?
Review the BauBau AI Construction Diary case study for Kings Landing's documented product definition, AI interaction design, role-based workflows, responsive UX, and product screens. It shows how drafts, human confirmation, permissions, and evidence connect. It is evidence of our design contribution, not proof that Kings Landing owned the full development, deployment, or ongoing operation of BauBau. The workflow guide distinguishes those project decisions from broader recommendations. Neither source establishes quantified accuracy, time savings, or results for your future product.
What should we bring to a first project discussion?
Bring the product goal, intended users, one important workflow, existing tools, and the data or evidence that workflow needs. Name who should review and approve AI output and which actions AI must never take automatically. Describe failure cases, the first release you need, and who will run it after launch. Use the workflow guide's pre-build checklist to expose unresolved decisions. Kings Landing's service process starts by agreeing those requirements before building, integrating, deploying, and supporting the product.