How Can Marketing Ship to Production? AppOS architecture, learning from your phone
Stephan Schmidt ยท Amazing CTO
How can marketing ship to production? Many orgs face the reality of everyone vibe coding Engineering is the new bottleneck for reviewsAgents write more code than senior engineers can review Saying no doesn't work, people deploy to Vercel on their own How can engineering feel safe and trust the code? Everyone coding is the biggest lever for productivity and time to market Your iPhone has solved this You trust code from unknown developers with your bank account iOS and Android have app permissionsapps only do what they are allowed to do App Store review checks apps for bad or malicious behavior AppOS Principles Adapt that model to applications: apps written by marketing, a shell/kernel owned by engineering Possible architecturesWASM gives the strongest isolation inside one process Plugins and modules are easier, but the language has to hold the boundary Services put a network between app and shell, a gateway checks permissions App Permissions Apps do only what their manifest grants Automatic App Review Every app is checked before it runs App / Unit Marketing ships one small unit Sandbox / Harness Each request runs inside hard limits From marketing code to production Negotiate manifest Marketing codes Use AI to write the app against the API Automatic app review Check code Check manifest Deploy check API check Runtime sandbox Runs in production Permission checks at runtime AppOS architecture Browser Shell / Kernel App App App 1 2 3 IO, e.g. database 1 App permissions 2 App in sandbox (CPU, memory) 3 Manifest file AI code needs to pass more authorizations Authentication Password ok? Application One user Authentication Password ok? Authorization Can token do X? Application Individual users Authentication Password ok? Authorization Can user do X? Authorization Can token do X? App Individual users Authentication Password ok? Authorization Can app do X? Authorization Can user do X? Authorization Can token do X? App Individual users Most teams today Developers write the code, we trust it AppOS Marketing codes the app with AI, we check every call Permissions Every app declares capabilities like pods-read or bookings-write in its manifest The manifest is negotiated: nobody approves permissions one by oneA deploy that uses an API not in the manifest is refused Roles still apply: an app with pods-write doesn't let Alice write if she is not allowed toBusiness rules stay in the platform, like one booking per pod and hour People only review the permissions App permissions User permissions Can the booking app read pods? Can Alice read pods? Automatic App Review ("Hardening")1 Every app is checked before it runsmanifest, host function catalog and the code Quality before malice: Apple rejected 1.93M of 7.77M apps in 2024, 1.24M for crashes and bugs, ~43k for hidden features Fuzzing with fake host functions (planned)Finds crashes, n+1 queries, corrupted data, security holes and "DDoS" Pass or fail, no human bottleneck It catches mistakes early, the sandbox still enforces every rule Apple, App Store Transparency Report 2024 Runtime Sandbox ("Harness") Each request runs in a fresh sandbox without files, network or a database of its own The app reaches the world only through the host functions its manifest grants Every call checks the app's grant and the user's role Every request has a budget for I/O, time, CPU and memoryOver budget, the app's slot shows unavailable and the page still renders Five failures in a minute roll the app back automatically App HTML can't run scripts, the shell sets a strict CSP A broken app can't take down the shell or other apps Gardening Everyone deploys: the CEO to Vercel, a marketer to Fly.io Shadow apps keep running and hold data, but nobody knows about them or patches them With AppOS we know what runs, who owns it and what it may do Every app has an owner, and when they leave the app is handed over or switched off Every manifest is written against one API version Manifests expire after 90 days and the app has to be reinstalled Unused permissions are flagged and removed Roomer already shows versions, usage and one-click rollback per app Roomer: AppOS in practice Roomer books office pods for meetings or quiet work Engineering owns the shell with sign-in, layout, data and permissions Agents wrote four apps on topBooking grid and Quick book for Product Pod stats for Marketing Pod admin for the Platform team Each app is handed over as one .wasm with its manifest Everything on the next slides runs today Roomer example AppOS architecture Example app: Booking grid Book a pod in three steps: pick a pod, pick your hours, confirm Written by an agent for Bob from Product, shipped as one .wasmBob can optimize, A/B test, layout changes, add features safely without engineering Shipped without a manualcode review, the worst case is a wrong booking Its manifest grants four permissions:pods-read: list the podsbookings-read: the day's bookings and bookable hoursbookings-write: book a pod, cancel only your own bookingsidentity: who is booking See running apps and permissions WASM under the hood Built with cargo for wasm32-wasip2WebAssembly components of 55 to 150 KB One export: request in, HTML out At deploy the shell checks the imports against the manifestA component lists the WIT interfaces it imports Any import the manifest doesn't grant is refused Each request gets a fresh wasmtime instanceLinked only to granted interfaces, no files, network or environment Casbin checks every call: the app's grant and the user's role Budget of 100 I/O units, 200 ms, 64 MB and CPU fuel, 8 parallel requests per app interface pods-read { all: func() -> list<pod>; } interface bookings-write { create: func(pod-id: u32, date: string, hour: u8, subject: string) -> result<booking, string>; cancel-own: func(id: u32) -> result<_, string>; } world app { import pods-read; import pods-write; import bookings-read; import bookings-write; import identity; import log; export handler; } Prior art OSGi: bundles declare imports in a manifest, checked before anything runs Portlets: the portal owns the page, each portlet renders a fragment EAR: deployment descriptors declare security roles, the container enforces them Browser extensions: declared permissions and store review Atlassian Forge, Shopify, Salesforce: apps inside someone else's product Firebase: untrusted code is fine if the rules hold WebAssembly component model: capabilities as interfaces Portals taught us the platform should own the page. OSGi taught us to check dependencies before anything runs. App stores taught us to review the submission up front.
What AppOS doesn't solve Content, design and SEO stay with marketing New APIs and new data still need engineering An app can misuse what it is granted, like booking pods nobody needs Apps can't call third-party services unless the shell offers an API for them The shell team becomes a platform team Where to start Pick one app marketing wants to ship Marketing and engineering write its manifest together Put a shell in front that owns sign-in, layout and data Without WASM, start with a plugin interface or a gateway with per-app tokens Start with the import check, add fuzzing and gardening later Engineering reviews the manifest instead of the code About Stephan Coding for 45 years , since 1981: from Z80 machine code to RustSerial startup founder, engineering manager, CTO of an eBay Inc. company Studied artificial intelligence at university in the 90s CTO coach at Amazing CTO, 1200+ coaching and sparring sessions amazingcto.com 
