Indie App Studio Architecture: How We Ship Across iOS, macOS, Android, and Web
By Samuel Coe, founder of CoeCode · Last Updated: March 2026
Shipping and maintaining multiple live apps as a single-founder studio requires deliberate architecture choices — in technology stack, infrastructure, deployment pipelines, and time allocation. CoeCode currently maintains five active products: BrewLogica (iOS, AI-powered coffee logging with a subscription backend), Fitscape (iOS and Apple Watch, fitness RPG with HealthKit integration), Linc (iOS, privacy-first friendship tracker), BuildBot (macOS menu bar build companion for iOS and Android developers), and Yoto Guardian (web, real-time parental controls for Yoto audio players). Each sits on different infrastructure, uses different backend patterns, and has different release cadences. The architectural goal is maximum code reuse and deployment automation without sacrificing product quality. This is what that looks like in practice — the decisions made, the tradeoffs accepted, and the tools that make a multi-product indie studio possible for one developer.
The CoeCode Product Portfolio
Understanding the architecture requires understanding what's being maintained. CoeCode's five products represent five distinct technical profiles — they aren't instances of the same app.
AI-powered coffee logging. Requires server-side infrastructure for AI API calls, cross-device sync, and MCP endpoint. Supabase for data, Cloudflare Workers for edge functions, custom AI parsing pipeline. Most complex backend of any CoeCode product. Subscription: $49.99/year.
Fitness RPG. Heavily integrated with HealthKit for passive health data ingestion. Companion Apple Watch app for workout tracking. Firebase for leaderboards and social features. Pixel-art assets and character progression logic are the bulk of the codebase complexity. Free.
Friendship tracker. Intentionally zero backend — all data stored in iOS Core Data, notifications are local, no network required. Simplest architecture in the portfolio. This simplicity is the product: privacy requires it. Premium subscription via In-App Purchase for unlimited friends.
Desktop developer tool for one-click iOS and Android builds, installs, and launches from the macOS menu bar. Distributed as a one-time purchase with a 14-day trial. Sits between product and tooling: customer-facing software that also shortens internal release loops.
Parental controls for Yoto audio players. Web-first because the Yoto API is web-facing. Real-time updates via MQTT and Server-Sent Events. React frontend, deployed on Cloudflare Pages. AI-assisted metadata parsing for audiobook uploads. Free tier with Pro features via Stripe.
Shared Infrastructure and Decisions
The most important architectural leverage a small studio has is shared infrastructure — components, services, and patterns that work across multiple products without duplication.
Netlify / Cloudflare Pages
All marketing sites and web apps deploy to either Netlify or Cloudflare Pages. Both support atomic deploys, branch previews, and form handling. coecode.io and Yoto Guardian's marketing pages are on Netlify. This standardizes deployment without lock-in.
Supabase for Structured Data
Apps that need a backend use Supabase (PostgreSQL + Auth + Storage + Edge Functions). BrewLogica's brew and bean data lives in Supabase. The Supabase client SDK works well in Swift with async/await, and the Row Level Security model handles per-user data isolation cleanly.
Fastlane for iOS Releases
Both iOS apps use Fastlane for automated builds, screenshot generation, and App Store Connect submission. The Fastfile is checked into each repo and parameterized per app. A single developer can ship an iOS update in 15-20 minutes of automated pipeline time vs. 2+ hours manually.
GitHub Actions for CI
All repos run GitHub Actions for continuous integration — build validation, test runs, and deployment triggers. macOS runners handle iOS builds. Shared action templates across repos avoid duplicating CI configuration logic.
Platform Strategy: When to Go Native vs. Cross-Platform
The biggest architectural decision for a multi-platform studio is whether to go native (Swift for iOS, Kotlin for Android) or cross-platform (React Native, Flutter). CoeCode's current position: native iOS for apps where platform integration is a core feature, web for apps where the target use case is browser-native.
Decision Framework
- • App requires deep HealthKit, Core Motion, or WatchOS integration (Fitscape)
- • App needs local-only, privacy-first architecture (Linc with Core Data)
- • App needs Apple platform design language to feel right
- • Target platform is already web (Yoto's API is web-facing, users are on desktop)
- • Feature set doesn't require native platform APIs
- • You need faster iteration without App Store review cycles
- • Core feature set is UI + logic with no deep native APIs
- • You need Android parity without a second full native codebase
- • Team has React Native or Flutter expertise already
CoeCode's iOS apps are native Swift/SwiftUI. The studio has explored React Native for a potential Android expansion of Linc — the local-first architecture would port cleanly — but the current focus is on iOS quality over Android coverage.
Full Tech Stack Reference
| Layer | Technology | Used In |
|---|---|---|
| iOS Development | Swift, SwiftUI | BrewLogica, Fitscape, Linc |
| Watch Development | WatchOS, SwiftUI | Fitscape |
| Web Frontend | React, Astro | Yoto Guardian, coecode.io |
| Styling | Tailwind CSS | All web properties |
| Backend / Database | Supabase (PostgreSQL) | BrewLogica, Yoto Guardian |
| Real-Time | MQTT, Server-Sent Events | Yoto Guardian |
| Social / Leaderboards | Firebase Realtime DB | Fitscape |
| Edge Functions | Cloudflare Workers | BrewLogica MCP, Yoto Guardian |
| Deployment | Netlify, Cloudflare Pages | All web properties |
| iOS CI/CD | GitHub Actions + Fastlane | BrewLogica, Fitscape, Linc |
| Payments | StoreKit 2 (iOS), Stripe (web) | All monetized products |
| AI / ML | Anthropic Claude API, Core ML | BrewLogica, Yoto Guardian |
| AI Integration | MCP (Model Context Protocol) | BrewLogica |
Time Allocation and Focus
The hardest part of running a multi-product studio isn't technical — it's attention. Every product competes for the same developer hours. Without an explicit system, the loudest problem (whichever app has a bug or a 1-star review today) dominates, and strategic work gets deferred indefinitely.
CoeCode runs on a quarterly planning cadence. Each quarter has one "primary focus" app for new feature work and one "maintenance" rotation for the others. The primary app gets the majority of development time. Maintenance apps get time-boxed work: bug fixes, iOS compatibility updates, and small improvements that fit within the time box.
The ruthless prioritization this requires is uncomfortable but necessary. A single developer maintaining multiple live products cannot iterate on all of them simultaneously. Knowing which ones are getting attention this quarter, and communicating that to users who ask about features, makes the situation manageable.
Current quarter focus (Q1 2026)
About CoeCode
CoeCode is an indie app studio founded by Samuel Coe, based in Missoula, Montana. We ship mobile and web products with a focus on AI-native features, clean architecture, and privacy-first design. Available for custom mobile development — iOS, Android, and web.
Frequently Asked Questions
What does an indie app studio actually look like?
An indie app studio typically means a solo developer or very small team (1-3 people) that maintains multiple live applications across platforms. Unlike a freelance developer, a studio has its own product portfolio — apps built on spec, not on contract. CoeCode is a single-founder studio with five live products across iOS, macOS, and web.
How do you manage multiple iOS apps simultaneously?
The key is standardization. CoeCode uses shared backend infrastructure (Supabase for apps that need it, Cloudflare for edge functions), shared CI/CD pipelines via GitHub Actions and Fastlane, and shared code where practical. Each app gets its own AppStore Connect configuration, but deployment scripts are templated and reused.
What's the benefit of shipping on multiple platforms?
Platform diversification reduces risk. If Apple changes App Store policies in ways that hurt one app category, having products across iOS and web means you're not entirely exposed. It also opens different monetization models — iOS apps can use In-App Purchases, web apps can use Stripe directly — which often means higher margins on the web.
How do you handle app maintenance while building new products?
We categorize apps by lifecycle stage: active development, maintenance mode, or end-of-life. Active development apps get feature work. Maintenance mode apps get bug fixes and iOS version compatibility updates only. This explicit categorization prevents the trap of spreading attention too thin — every active development session is focused on one product.
What is Fastlane and why does CoeCode use it?
Fastlane is an open-source automation tool for iOS and Android apps that handles tasks like building, signing, and submitting to the App Store. CoeCode uses Fastlane to automate screenshot generation, certificate management, and App Store Connect submissions. What would take 2-3 hours of manual work per release takes about 15 minutes of automated pipeline execution.