The architecture · one flow · two surfaces · two-way sync
Edit in Kite. Ship via GitHub. Both surfaces stay in sync.
The previous draft framed Gold and Blue as a choice — full takeover or PR-only. That fork is gone. The new architecture combines them: all editing happens in the Kite environment (gold), and every change ships as a PR on the customer's GitHub repo (blue). Customer keeps their domain, their CI/CD, their existing deploy preview. Kite hosts an additional preview at appsmith.kite.space. When a PR merges to main, both surfaces update — webhook-driven, not polled. Feature branches are namespaced kite/<slug> so the two-way sync stays scoped.
Gold · Kite environment
Where the change is drafted & live-previewed
Kite mirrors the codebase, runs the editing loop, hosts the working preview at appsmith.kite.space. The preview tracks main always — there is no kite/main branch; that ambiguity is the thing we explicitly removed.
Blue · Customer GitHub
Where every change ships from
Each Kite session opens a feature branch like kite/hero-headline-change and a PR on the customer's own repo. Their CI/CD, their reviewers, their domain. No major refactor — Kite adapts to whatever they already have.
Kite-hosted preview
appsmith.kite.space
Tracks current main. Updates on PR merge.
⇄
Two-way sync
webhook-driven · scoped to kite/*
Customer's own deploy
appsmith.com
AWS / Vercel / wherever they are. Untouched.
The flow · one track, two surfaces
PathKite surfaceGitHub surfaceDrop-off
★ The crux
The old "Big Decision" — move to Kite or just raise PRs? — has been retired. The new design says both, always: edit on Kite, ship via GitHub, sync both ways. The risk surface shifts to Station 11 (sync) and Station 10 (merge conflicts). Get the webhook plumbing right and the LLM-merge right, and the rest is downstream.
The decisions
Six calls that shape the integration.
Captured from the GitHub-integration sync. These are the load-bearing choices behind the flow above — the ones that aren't visible in the code yet, but constrain what gets built next.
5 architecture 1 platform swap 1 launch flag
Architecture · branching
No kite/main
Kite-created branches use the kite/<slug> namespace (e.g. kite/hero-headline-change). There is no kite/main — the customer's main is the only main. Avoids the "which main is real" confusion that surfaced in the v0.4 review.
Architecture · sync
Webhooks, not polling
GitHub webhooks drive the two-way sync. Applies to kite/* branches and to merges into main — not to every branch in the repo. Customer-side workflows (formatters, codegen, lint fixes) flow back into the Kite environment.
Architecture · conflicts
LLM resolves at PR stage only
We do not continuously sync main into in-flight feature branches. Merge conflicts are handled by the LLM at the final PR step. Optional user-triggered re-sync if main moves a lot mid-session.
Architecture · preview
Dual preview, dual confidence
Kite hosts appsmith.kite.space (always tracks main). Customer's existing deploy preview (if any) stays alongside. Showing both lets the marketer trust the change before it touches production infra.
Platform · integrations
Composio → PipeDream
Composio has been unreliable around signup/invites. Migrating to PipeDream for user-level integrations (Notion, etc.). Platform integrations (GitHub, Slack) stay direct — they're load-bearing enough to own ourselves.
Launch · feature flag
Secrets button · AppSmith only
The "Secrets" entry point ships behind a feature flag, enabled only for AppSmith users in the first pass. Lets us shake out the credential-flow design (see drop-off D3) on a friendly cohort before exposing it broadly.
The exits
Six places where customers leave.
Each red exit on the map maps to a card below. Drop rates are pre-data estimates — replace with real values after the first 100 sign-ups. Hover a card to highlight its exit on the chart above.
3 setup exits 1 replicate exit 2 ship exits
D1 · 20%Station 03 · Auth
Platform lead denies the GitHub App install
The marketer asks for Kite; the VP-Eng or platform team is the one approving the permission scope. If the install scope feels broad — especially the deploy-adjacent scopes — they say no on instinct. The load-bearing risk from the v0.4 research read; the combined architecture does not change it.
Install with the minimum scope only. Defer write/deploy-adjacent scopes to the point we actually need them. Add inline plain-English explanations next to every permission.
D2 · 12%Station 04 · Scan
Stack Kite can't manage yet
The scan returns WordPress, Wix, Squarespace, Webflow, or a custom monorepo with exotic Webpack config. Kite can't credibly own the runtime, so the journey ends here.
Catch this at Station 01, not at 04 — pre-flight the URL the moment it's pasted. For unsupported stacks, capture the framework as a waitlist signal instead of leaving the user with a dead end.
D3 · 8%Station 05 · Replicate
Credentials withheld by their security team
Replicating the codebase into the Kite environment needs API keys, env vars, CMS tokens, CDN credentials. The platform team approved the GitHub App but draws a hard line at handing over secrets — especially production ones. This is what the AppSmith-only Secrets button is designed to de-risk first.
Two paths: (a) Start with staging-only credentials and gate prod creds behind explicit migration. (b) Offer a Vault-style integration so secrets stay in the customer's vault and Kite reads them at runtime, not at install.
D4 · 7%Station 05 · Replicate
"Extras" Kite can't replicate
The site depends on things outside the repo: a Contentful pipeline, a Segment proxy, an internal auth gateway, a custom CDN ruleset. Kite spins up the runtime and pieces are missing. The combined architecture partially defuses this — Station 09's dual preview surfaces the gap before merge — but doesn't make it disappear.
Run a pre-flight "extras inventory" at Station 04 (scan), not at 05. Tell the customer up-front what we can replicate, what stays connected via their accounts, and what we can't take.
D5 · 5%Station 08 · PR
Engineering team rejects the PR
Kite's diff doesn't match the team's house style — wrong import ordering, wrong component pattern, touched files outside scope. PR sits, then closes. Webhook sync (Station 11) is designed to absorb their formatter / lint workflows back into Kite, so this exit narrows over time — but only after the team merges at least once.
Run a "style match" pass against the repo's recent merged commits before opening any PR. Match conventions; don't impose them. Auto-message on the PR explaining what Kite did and what it deliberately didn't touch.
D6 · 6%Station 10 · Merge → CI/CD
Customer's CI/CD is too slow
The PR merges, but their pipeline takes 14 minutes to build and deploy. From the user's seat, the Kite preview already looks done — and then they wait. The dual-preview design helps, but the customer's prod surface still lags.
Surface the expected wait time the moment the PR merges (borrowed from GitHub Actions / Vercel UI). Make it explicit that appsmith.kite.space updates immediately while appsmith.com follows when their pipeline finishes.