Skip to content
OTFotf
All posts

Deploy AI-Powered Apps smoothly Across Web and Mobile with OTF Kits

D
DaveAuthor
7 min read
Deploy AI-Powered Apps smoothly Across Web and Mobile with OTF Kits

The fastest way to ship an app today is to describe it. Cursor, Lovable, Bolt, v0, Rork — they'll scaffold a working UI in an afternoon, and that loop has changed what a solo builder can produce in a week. The model writes 400 lines of JSX, you see it in the preview, you iterate by prompting. Genuinely new, and worth taking seriously.

Then you click "deploy" and the velocity stalls.

This isn't the AI tools' fault. It's the gap between "runs on localhost" and "exists on a real domain with a real certificate, in the App Store and Play Store, with auth, billing, and a database the agent doesn't touch again." Agents are great at the first 80%. The last 20% — the part that actually puts the app in front of a paying user — is a different job, and no amount of better prompting makes it faster.

That last 20% is what OTF kits wire up before you start.

Two very different jobs

Scaffolding is generative. You describe a screen, the model writes the markup, you see it in the preview. The loop is fast because the feedback is fast — a screenshot, a hover, a click.

Deployment is operational. You can't iterate on a TLS certificate by clicking around. You can't "vibe-check" whether your DNS A record points to the right load balancer. The work is checklist-shaped: register the domain, point the records, wait for propagation, request the cert, install the cert, configure the redirect, set the env vars, build the mobile binary, sign it, upload it, fill in fourteen store metadata fields, submit for review.

No model is going to make that fast by writing more code. The speed limit is set by certificate authorities, app store reviewers, and DNS TTLs.

So you have a choice. Either you do it manually every time, or you pre-wire a script that does it once and runs identically for every project.

What manual deploy actually costs

I watched a friend ship a SaaS last month. Three platforms, two weekends of evenings. The manual path looked roughly like this:

# web — register domain, set DNS, request cert
vercel link
vercel env add STRIPE_SECRET_KEY production
vercel domains add app.example.com
vercel dns add app.example.com CNAME cname.vercel-dns.com
# wait 5 minutes for propagation
curl -I    # hope for 200

# ios — open Xcode, archive, sign, upload, fill metadata
# wait 3 days for App Store review

# android — build AAB with release keystore, sign, upload
# fill content rating, data safety, target audience forms
# wait 1-2 days for Play review

Multiply that by the number of side projects you actually finish. Most don't get finished because the deploy step eats the will to continue.

One codebase. iOS, Android, and web.

The Fitness Kit ships with auth, a database, and a backend already connected — no setup. Live demo at fitness-preview.otf-kit.dev.

See the live demo

What a pre-wired deploy looks like

An OTF kit ships a single script. From the project root:

./scripts/deploy.sh production

That's the whole interface. What it actually does, in order, is the boring 20%:

  1. Build the web bundle.
  2. Push it to the edge with the production env baked in.
  3. Register the custom domain if it isn't already claimed.
  4. Set the DNS records (A, AAAA, CNAME) to point at the edge.
  5. Request a TLS cert via ACME and install it.
  6. Set up the www → apex redirect.
  7. Build the iOS archive with the right provisioning profile and bundle id.
  8. Build the Android AAB with the right signing key.
  9. Upload both to their respective stores.
  10. Print a summary of every external resource now pointed at your app.

You run one command, you walk away, you come back to a deployed app. The script is idempotent — running it twice doesn't double-register the domain or create a second certificate. Re-running is how you ship the next change.

The mobile half is where most agents bail

Web deployment is almost solved. A model can hand you a vercel.json and you're ten minutes from a live URL.

Mobile is not solved. The build chain alone — Xcode workspace, provisioning profile, signing certificate, push notification entitlement, App Store Connect API key — has more failure modes than a typical agent has seen in training. So the agent cheerfully scaffolds a "run on simulator" path and stops. You discover the gaps when you try to upload.

The deploy script in an OTF kit encodes the parts that don't change:

# deploy.toml — committed in the kit root
[ios]
bundle_id     = "com.example.app"
team_id       = "ABC123XYZ"
profile       = "AppStore.mobileprovision"
asc_api_key   = "AuthKey_XXXXXXXXXX.p8"
asc_key_id    = "XXXXXXXXXX"
asc_issuer    = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"

[android]
package_name     = "com.example.app"
keystore        = "release.keystore"
keystore_alias  = "upload"
service_account = "play-console-sa.json"

A coding agent reads this file and knows what to do. No re-discovery, no prompt loops, no hallucinated Gradle flags. The configuration is the contract between the agent and the deploy step.

AI agents extend the kit instead of regenerating it

This is the part that actually compounds. Most AI tools regenerate — you describe the app, they rewrite the whole codebase, your custom code lives nowhere stable. Next time you prompt, it might still be there, might not.

An OTF kit ships with the config an agent needs to extend:

# CLAUDE.md (excerpt)
This project is an OTF kit. The components in @otfdashkit/ui and
@otfdashkit/ui-native are the source of truth — do not regenerate them.

To add a screen, scaffold the route file and import existing components.
To change the theme, edit tokens.css. The same change ships to web and
native automatically.

For deploy, run `./scripts/deploy.sh <env>`. Do not invoke the deploy
subcommands directly — the script handles the store credentials and DNS.
# .cursorrules (excerpt)
- Never modify files inside src/components/ui/ — those are owned by the kit.
- New screens go in the screens directory with matching web and native entries.
- Mobile and web share the same component API. Write once.
- Theme tokens live in src/tokens/. Change once, ship everywhere.

Twenty-some tested prompts live in ai/prompts/ — the agent knows how to add a Stripe webhook, how to add a new screen, how to swap auth providers, without you re-explaining the project every session.

So when Cursor or Claude Code scaffolds the next feature for you, it scaffolds it inside a deployable system, not on top of one you'll have to wire up yourself.

prompt lands → agent reads CLAUDE.md and .cursorrules → agent extends existing kit compone

What this actually enables

Three concrete outcomes that matter when you're shipping AI-assisted:

1. Side projects actually ship. The deploy step stops being a separate weekend. It becomes git push plus ./scripts/deploy.sh production. The will to keep going survives, because the finish line isn't a maze.

2. The agent stays useful across sessions. Because the kit's CLAUDE.md and .cursorrules describe the architecture instead of forcing the agent to rediscover it, your second prompt is as cheap as your first. The agent doesn't have to re-read 200 files to figure out where the button lives — it imports the component and moves on.

3. Web and mobile stay in sync. The same <Button> renders on iOS, Android, and web from one codebase. The agent writes it once, you ship it three places. No "looks different on Android" followup tickets, no "the web team moved on, mobile is two versions behind" debt.

The first 80% — the part AI is genuinely good at — gets faster every quarter. New models, new editors, new agent loops. The deploy step doesn't get faster on its own, because the constraints aren't technical, they're procedural: certificates, store reviews, DNS. A pre-wired script is how you lock in that 20% once and stop paying for it every project.

How to use it today

From an empty directory:

# pick a kit — SaaS Dashboard, Fitness, or Booking
npx otf-kit@latest init my-app --template fitness
cd my-app
npm install

# edit deploy.toml with your real domain and store credentials
$EDITOR deploy.toml

# ship it
./scripts/deploy.sh production

One command at the end. Everything below it — DNS, certs, store uploads, the redirect from www — runs whether you remember the steps or not.

The split, in one line

AI coding tools win the scaffolding. OTF kits own the deployment. Use both, and the part that doesn't change when the model does is the part that actually gets you paid.

ai-toolsarchitecturecross-platform
OTF Fitness Kit

Stop wiring. Start shipping.

  • Login, database, and backend already connected — nothing to set up
  • iOS + Android + web from one codebase
  • AI configs pre-tuned + 40+ tested prompts included