PRD — Enterprise-Embedded Test Kitchen

Summary

Product managers today wait weeks for engineering to build throwaway prototypes, or use external tools that produce artifacts disconnected from production systems. The Enterprise Test Kitchen lets a PM describe an idea in plain language, get a working full-stack app running against sanctioned internal services within minutes, share it with real customers for feedback, and — when it passes validation — promote the design and code to production through the same review and compliance gates any engineer would follow.

Problem & goals

Problem

• PMs cannot cheaply test hypotheses with real users.
• Prototypes built externally don't map to production stack, blocking promotion.
• Engineering capacity is spent on throwaway validation work.
• Validated ideas take weeks to re-implement for prod.

Goals

• PM → working app in under 5 minutes.
• Every prototype uses the org's design system and platform primitives.
• Validated prototypes promote to prod with zero rewrite.
• Full audit trail from prompt to production commit.

Non-goals

Native mobile apps, multi-tenant SaaS delivery to external customers, replacing the org's IDE/CI, AI model training, and white-labeled embeddables.

Users & personas

Primary

Tara — Product Manager

No-code. Wants to test an idea with 20 customers this week without pulling engineers.

Secondary

Ravi — Engineer / Reviewer

Reviews generated code before promotion. Needs diff-friendly, standards-conformant output.

Secondary

Sam — Platform / Security Admin

Owns guardrails, quotas, audit, and policy-as-code enforcement.

End-to-end journey

1
Ideate
PM signs in via SSO, describes the app in natural language.
2
Generate
AI scaffolds a full-stack app using the internal design system, auth, and platform services.
3
Iterate
PM refines visually and via prompts; each change is a traceable commit on a feature branch.
4
Test with users
One-click deploy to a governed sandbox with synthetic data. Shareable link, no PII.
5
Collect feedback
In-app reactions, session recordings, and analytics flow into the org's tools.
6
Validate
Automated gates run: tests, security, a11y, perf, design-system, policy-as-code.
7
Review
Eng reviewer, design, and (if required) security/compliance approve the PR.
8
Promote
Merge → staged rollout behind a feature flag → production. Rollback in one click.

Functional requirements

Natural-language, context-aware generation

Prompt-to-app that resolves against the org's design system, component library, domain vocabulary, and approved stack. First-pass output must pass lint and typecheck.

R1a

Enterprise branding standards conformance

Generated apps automatically apply the enterprise brand system — logo, color tokens, typography, iconography, voice/tone, legal footers, and accessibility contrast rules. Brand assets are versioned; a branding-conformance gate blocks promotion on drift.

R1b

Enterprise API integration

First-class integration with the enterprise's internal APIs (identity, customer, catalog, billing, entitlement, notifications, etc.) via a curated, discoverable catalog with pre-approved SDK clients, typed schemas, scoped credentials, and per-call audit logging. No direct, unvetted API calls from generated code.

R1c

Azure Cloud deployment target

Sandbox and production deploy to Microsoft Azure using the enterprise's landing zone: Azure App Service / Container Apps or AKS for runtime, Azure AD (Entra ID) for SSO, Azure Key Vault for secrets, Azure Monitor + Application Insights for telemetry, Azure DevOps or GitHub Actions on Azure runners for CI/CD, and region pinning for data residency. IaC via Bicep/Terraform under policy-as-code.

No-code interface, code-faithful output

PM never sees code. Visual edits produce deterministic, diff-friendly commits that engineers can review.

Bring-your-own-stack scaffolding

Generated apps target the org's real framework, database, auth provider, feature flags, telemetry, and logging via pre-approved SDK templates. No shadow infrastructure.

Governed sandbox environment

Every prototype runs in an isolated sandbox with synthetic or masked data. No prod PII, secrets, or side effects. Shareable link with SSO or time-boxed guest access.

Native repo integration

Prototype is a branch in the target repo from turn one. Every AI change is a commit with prompt-to-diff audit metadata. Promotion = open PR.

Automated validation gates

Type check, lint, unit + integration tests, SAST, dependency CVE scan, secret detection, WCAG AA, perf budget, design-system conformance, and policy-as-code — all required before promotion.

Human approval workflow

Configurable required approvers: eng review, design, and (where scope requires) security / compliance / privacy. Approvals recorded in the audit log.

Staged rollout & kill switch

Promoted apps launch behind a feature flag with cohort targeting. One-click rollback and instant kill switch available to any approver.

SSO, RBAC, and audit trail

SAML/OIDC via the corporate IdP. Roles: PM, Reviewer, Admin. Immutable log of every prompt, generation, edit, approval, deploy, and rollback — exportable for SOC 2 / ISO 27001.

R10

Secrets & data governance

No secrets in generated code. Runtime injection from the org's secret manager, scoped per environment. Data access via a proxy with masking and audit logging.

R11

Policy-as-code guardrails

Configurable rules the generator cannot violate: forbidden libraries, mandatory auth wrappers, PII handling, required headers. Enforced at generation time.

R12

Customer feedback loop

Built-in reactions, comments, session replay, and event analytics wired to the org's analytics stack. Feedback attaches to the prototype version that produced it.

R13

Cost & quota controls

Per-team quotas on AI generations, sandbox compute, storage. Chargeback reporting for finance.

R14

Version history & rollback

Every version restorable. Branch, fork, and compare prototypes side by side.

R15

Leadership decks & business cases

A PM can generate a digital slide deck or Excel business case summarizing the prototype’s purpose, user journey, requirements, and validation results when prompted. Output is downloadable and shareable via link for leadership review, with branding applied from the enterprise design system.

Non-functional requirements

Time to first working app

≤ 5 minutes from prompt to shareable sandbox URL.

Iteration latency

≤ 30 seconds for typical prompt edits.

Availability

99.9% for the builder; inherits prod SLOs after promotion.

Security

SOC 2 Type II, ISO 27001, data residency pinning.

Accessibility

Builder UI and generated apps meet WCAG 2.2 AA.

Browser support

Latest two versions of Chrome, Edge, Safari, Firefox.

Architecture at a glance

  PM (No-code UI)
        │
        ▼
  ┌───────────────────────────┐
  │  AI Generation Service    │──▶ Design System + Domain Context
  │  (policy-as-code enforced)│──▶ Approved SDK Templates
  └───────────────────────────┘
        │  commits
        ▼
  ┌──────────────┐   deploy   ┌────────────────────┐
  │  Repo (PR)   │──────────▶ │ Sandbox Environment│
  └──────────────┘            │ synthetic data     │
        │  passes gates       └────────────────────┘
        ▼                              │
  ┌────────────────────┐               │ feedback + analytics
  │ Validation Gates   │◀──────────────┘
  │ tests · sast · a11y│
  │ perf · policy      │
  └────────────────────┘
        │  approvals
        ▼
  ┌────────────────────┐
  │ Staged Prod Rollout│ ── flags · rollback · audit
  └────────────────────┘

Success metrics

Activation

70% of invited PMs ship a prototype in their first week.

Cycle time

Median idea → validated prototype ≤ 3 days (baseline: 3 weeks).

Promotion rate

≥ 30% of prototypes that pass user validation are promoted to prod.

Eng offload

≥ 5,000 engineering hours/year saved on throwaway prototypes.

Gate pass rate

≥ 80% of first PR submissions pass automated gates without manual fixes.

Safety

Zero prod incidents attributable to Test Kitchen output in the first year.

Risks & mitigations

Generated code drifts from org standards

Mitigation: Enforce design system + policy-as-code at generation time; block PR merge on conformance gate.

PMs ship untested features to prod

Mitigation: Automated gates are non-bypassable; human approvals required; staged rollout with flags.

Sandbox becomes a shadow prod

Mitigation: Synthetic data only; sandbox TTL; no prod secrets; usage quotas.

Compliance / audit gaps

Mitigation: Immutable prompt-to-commit audit log; scoped RBAC; regional data pinning.

AI hallucination on domain logic

Mitigation: Domain context grounding, retrieval over internal docs, and mandatory reviewer sign-off before promotion.

Milestones

M1 · FoundationsQ1SSO, RBAC, repo integration, sandbox environments, audit log.
M2 · Generation MVPQ1–Q2Prompt-to-app on approved stack + design system, no-code editor.
M3 · Validation gatesQ2Automated gate suite + human approval workflow.
M4 · Promotion pathQ2–Q3PR-based promotion, staged rollout, feature flags, rollback.
M5 · GAQ3Cost controls, analytics, org-wide rollout.

Open questions

• Which repo host and CI system anchor the promotion path (GitHub Enterprise, GitLab, internal)?
• What is the canonical design system and component library to ground generation?
• Which approvers are required by default vs. optional per policy tier?
• How is synthetic data generated for domains with complex referential integrity?
• What is the initial pilot scope — one BU, or cross-org from day one?

Lovable Business vs. Enterprise-Embedded Test Kitchen

Which requirements a commercial Lovable Business/Enterprise account can deliver today, versus what an enterprise-embedded Test Kitchen built by an internal platform team is required to add. Legend: ✓ Delivers ~ Partial ✗ Gap

Requirement	Lovable Business	Test Kitchen	Why the gap
R1 · NL generation	✓	✓	Both generate full-stack apps from prompts.
R1a · Enterprise branding conformance	~	✓	Lovable can style to a brand, but has no versioned brand-asset registry or blocking conformance gate.
R1b · Enterprise API integration	~	✓	Lovable can call APIs; it lacks a curated internal catalog with scoped credentials, typed SDKs, and per-call audit.
R1c · Azure Cloud deployment (landing zone)	✗	✓	Lovable hosts on its own infra; enterprise landing zone, Entra ID, Key Vault, region pinning require internal deployment.
R2 · No-code, code-faithful commits	✓	✓	Both produce reviewable code.
R3 · BYO internal stack	~	✓	Lovable targets its default stack (React/Vite/TanStack + Cloud). Internal frameworks, DBs, and platform SDKs are Test Kitchen scope.
R4 · Governed sandbox with synthetic data	✗	✓	Lovable previews are public-ish sandboxes without enterprise data masking, TTLs, or synthetic data pipelines.
R5 · Native repo integration (GH Enterprise/GitLab/internal)	~	✓	GitHub.com sync is supported; GitHub Enterprise Server, GitLab, and internal hosts need Test Kitchen adapters.
R6 · Full automated validation gates	~	✓	Type/lint pass out of the box; SAST, CVE, a11y, perf, design-system, and policy-as-code gates are Test Kitchen scope.
R7 · Human approval workflow (eng · design · sec · compliance)	✗	✓	No configurable multi-role approval gate tied to the org's compliance tiers.
R8 · Staged rollout & kill switch (flags)	✗	✓	Flags, cohort targeting, and one-click rollback into prod are outside Lovable's scope.
R9 · SSO, RBAC, immutable audit trail	~	✓	SSO available on Business/Enterprise; a SOC2/ISO-exportable prompt-to-commit audit log is Test Kitchen scope.
R10 · Secrets & data governance via org secret manager	~	✓	Lovable stores its own secrets; runtime injection from Key Vault + data-access proxy with masking is internal.
R11 · Policy-as-code guardrails at generation time	✗	✓	No enterprise-authored ruleset the generator cannot violate.
R12 · Feedback loop wired to org analytics	~	✓	In-app feedback exists; native piping to the org's analytics/session-replay stack is Test Kitchen scope.
R13 · Per-team quotas & chargeback	~	✓	Seat-based billing exists; per-team compute quotas and finance chargeback need internal metering.
R14 · Version history & rollback	✓	✓	Both provide version history.
R15 · Leadership decks & business cases	~	✓	Lovable can generate decks, PPTX, and Excel business cases when prompted; Test Kitchen can also generate them on request, with enterprise branding and validation results wired in.

Lovable Business delivers

Prompt-to-app generation, no-code editing, code-faithful commits, GitHub sync, SSO, version history, and prompt-generated collateral (decks, PPTX, Excel business cases) — enough for external prototypes and standalone products.

Only Test Kitchen delivers

Azure landing-zone deploys, curated internal API catalog, brand-conformance gate, policy-as-code, sec/compliance approvals, staged rollout with flags, synthetic-data sandboxes, org-secret-manager injection, and leadership decks with business cases tied to each prototype's validation results.