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

A contribution that passes the gate + approvals publishes and starts earning its share — a 12-month royalty, scaled by your deployment tier, usage-based.

Your run-rate

every shipped feature earns for 12 months and stacks

0

features live

$0

monthly run-rate

$0

projected 12-mo

Royalty = $30/mo base × tier factor (full-online 0.6 · hybrid 0.8 · own-computer 1.0) × usage, for 12 months. The platform's 10% is charged only on money earned after credits — a productive contributor's bill trends to zero.

Publish a cross-platform ticket from the Review Queue (approve it 3×) to watch a feature land here and start earning.

Live royalty ledger

immutable · attribution recorded at publish · co-built features split by weight

No features published yet. Approve & publish a contribution to begin.

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?