LEDesign Studio
Contributor Builder Platform · the AI Builder keystone
Interactive prototype · client-side only · no live secrets

Connect your agent

Build features on LE PRO with your own agent, or use ours. Every feature you ship pays you a monthly royalty. Start by choosing how you want to build.

Choose your build mode

this sets whose compute runs the build — and what you earn
☁️ Use our agents
Zero setup. Build from a phone. Our agents, our sandbox, the live test view — all seamless in-system. We carry the compute cost.
◆ Earning tier ≈ 0.6–0.8 · we host
💻 Bring your own agent
Build on your own machine with your own agent, then submit updates (diffs, HTML, build plans). Your horsepower → you earn the most.
◆ Earning tier ≈ 1.0 · max earn
Either way, the control plane is ours. The Builder, the credit ledger, and the verification gate always run on our platform — even when the build compute is yours. That's what keeps the money and the trust central.

The onboarding handshake

bring-your-own selected → provision your agent with a secure, scoped grant
STEP 1
Mint code
server-signed · single-use · 15-min TTL · bound to your account
STEP 2
Paste prompt
into your terminal / agent — contains no secrets
STEP 3
Agent pulls manifest
public capability spec only — reading it grants nothing
STEP 4
Agent submits specs
toolchain + capabilities, with the one-time code
STEP 5
Scoped session minted
least-privilege · preview-only · revocable · audited
# Paste this into your terminal or agent connect --to https://studio.lepro.app/bootstrap \ --grant LEP-1CODE-PENDING \ --submit-specs
Grant status: not minted
--:--
The paste-prompt is the biggest attack surface, so it carries no secrets — only a public URL and a single-use, identity-bound code. A leaked prompt is worthless without your authenticated account.

The built-in AI Builder

Choose what you're building, watch it build, and see the end-to-end UI test run live — the verification gate, in-system, on every change.

What are you building?

this auto-classifies the change — personal customization vs cross-platform core
Change class Personal customization → tenant-scoped, 1 light approver, cannot touch shared core.

Plan → Execute → Test, one screen

you see exactly what the agent sees
✏️
Plan
sketch + preview the UI
⚙️
Execute
agent writes code, live
🔬
Test & track
the 6-level gate, live
Live end-to-end view — idle mode: use our agents
preview URL · synthetic data only
never prod · auth-gated · short-lived
Press Run the build + gate to watch the agent build, deploy to a preview, and drive the real UI through all 6 verification levels.
The gate re-runs every test in our sandbox — even for bring-your-own submissions. We never trust a contributor's own green light. Try "inject a linkage bug" to watch level 3 catch the payment↔invoice collision class.

Review & approval queue

Automated gate AND human approval. Personal customizations are light. Cross-platform / white-label core needs the gate green plus three distinct approvers.

How the two classes differ

Personal customization
  • Blast radius: one tenant (your own instance)
  • Automated gate: required
  • Human approval: 1 light approver (or self-serve config)
  • Cannot touch shared core — enforced structurally
Cross-platform / core
  • Blast radius: every tenant
  • Automated gate: required
  • Human approval: 3 distinct approvers, roles enforced
  • Security Reviewer mandatory for auth/payments/data
  • No self-approval · staged behind a feature flag

Publish → start earning

You become a partner by implementing features. Each one earns a share of the income from the users who actually use it — and it grows as the platform grows. Move the sliders to model your run-rate.

Earnings simulator

usage/adoption-based · one-layer referral · consistent with the master-plan Key Matrix
25
1,000
100 → 1,000,000 users · logarithmic — more users means every feature earns more
25
features live
$300
monthly run-rate
$3,600
projected 12-mo
One-layer referral (Key Matrix): you also earn a 5% override on the earnings of contributors you bring in — the same usage-based pool, one layer deep, no pyramid. The platform's 10% is charged only on money earned after credits, so a productive contributor's bill trends to zero.

Live royalty ledger

a sample of contributed features — each earns from the users who actually use it, at your current user base

How it's wired

Two planes on the LE Pro backbone. The one rule that dominates every decision: every external contribution lives in an isolated, ephemeral, synthetic-data sandbox that can never reach production, secrets, or another tenant.

Two planes

  • Control plane — always ours. Builder orchestrator, credit ledger, verification gate, review queue, publish, registry, audit log. Runs on our platform even when build compute is the contributor's.
  • Compute plane — ours OR theirs. Where code is written + run. Mode A = our sandbox (our compute, lower tier). Mode B = their machine (their compute, max tier). Build compute may be theirs; gate compute + control plane are always ours and bounded.

The security model — #1 risk, head-on

  • Hard isolation per contribution — ephemeral per-contributor sandbox, synthetic seed data only, Firecracker/gVisor-class, per-run CPU/mem/time quotas, kill-on-anomaly.
  • Deny-by-default egress — can't reach prod, secrets, or arbitrary internet. Stops tampering and exfiltration.
  • No prod secrets in the sandbox, ever — even total compromise yields an empty synthetic box.
  • Server-side tenant scoping is the last line — no cross-tenant read is possible.
  • We never trust contributor test results — the gate re-runs everything in our sandbox with adversarial mutation testing.
  • Prompt-injection resistant — contribution text is data, never instructions to the gate.
  • Supply-chain + artifact scan before publish — secret-scan, static analysis, dependency pinning, CSP/SRI; no phone-home rides a passing bundle.
  • Survives launch — runtime guardrails + scheduled self-alerts + per-feature kill-switch + revenue clawback on abuse.

Flaws found → fixed

the full 16-item ledger is in DESIGN_STUDIO_PROJECTS_PLAN.md — highlights here
  • Paste-prompt attack surface → single-use, identity-bound, TTL'd signed code; public-only bootstrap; scoped preview-only creds; revoke + audit.
  • Gamed tests → re-run in our sandbox; mutation testing; a test that passes with the feature deleted is a build failure.
  • Merge chaos → personal = overlay that can't edit core; core = trunk + rebase + semantic conflict check + feature flags.
  • Attribution disputes → immutable record at publish, weighted split, original-author floor, arbitration.
  • Approver collusion → distinct identity-verified approvers, enforced roles, mandatory security reviewer, no self-approval.
  • Revoked-but-in-flight → revoke propagates to kill the sandbox; in-flight writes only ever hit the preview.
Open questions for Levi: who fills the 3 approver roles at launch (can Dispatch be one)? · self-serve threshold for personal customization? · identity-verification bar before a grant issues? · the attribution split formula + original-author floor? · Mode-A compute budget defaults per level? · revenue-clawback window?