Storytimebaker - a consumer iOS and Android app with its own backend, built end-to-end

A consumer-shaped product - AI-generated bedtime stories with audio narration, personalised to a child profile, available in multiple languages, sold by subscription on both app stores - that exists in our catalogue as the reference build for “we ship the whole mobile-app-plus-server stack”. Built by the studio top-to-bottom: a real native iOS app, a real native Android app, a marketing site, and the serverless backend behind all three, with a shipped-client contract that holds across version-floors and a test harness that catches schema drift before it reaches a user.

Live: storytimebaker.com · iOS via TestFlight · Android in development

The brief

The category - “a bespoke mobile app for my business” - is the one most agencies decline to scope. The cost is “call us back when you’ve got £80k and twelve months”; the recommendation is “go off-the-shelf, you don’t need this”; and the few that say yes hand the client a shell that breaks the moment Apple’s Human Interface Guidelines move under it or Google deprecates an API. The Storytimebaker build exists to make the opposite case: a real consumer app, built native on both platforms, with a backend that scales to zero between users, shipped through both app stores, with a contract that holds across version-floors and a test harness that catches breakage before a user sees it.

The product itself is consumer-shaped - a children’s-stories app sold by subscription - but the build pattern is the load-bearing artefact in our catalogue. It’s what we’d ship for a gym member app (class-booking, member-card check-in, workout-tracking, retention nudges), an equine yard or syndicate-owner app (per-horse calendar, race-day pass, statement, syndicate group thread), a pet-services owner app (booking, photo-update, payment, vaccination calendar), a parent app for a nursery group (term-fee, safeguarding consent, photo-update, parents’-evening booking), an independent-garage customer-side service-history app, or any other vertical where the customer comes back regularly enough that “go to our website” isn’t the answer.

What it actually does

A real native iOS app. Built in Swift, signed and shipped through TestFlight into the App Store pipeline. Apple subscriptions through StoreKit, push notifications, App Tracking Transparency for telemetry, full HIG-compliant UI. A structured localisation pipeline feeds multiple languages from a single source of truth - so when the Spanish copy lands, it lands across both platforms in parity.

A real native Android app. Built in Kotlin, with Google Play Billing for subscriptions, push notifications, and the same localisation source feeding the Android string resources. Build and deployment automated through to the Play Store so a release is a tag and a push, not a Saturday-afternoon manual upload.

A serverless backend, built to last across releases. A serverless backend behind both apps - auth, purchases, story generation, audio narration, profiles, sharing, push tokens, error reports, version-gate. It scales to zero between users and to the spike when a school holiday lands without anyone touching a server. Story generation runs across multiple AI providers tuned per stage for cost, quality, and latency; audio narration runs through a text-to-speech pipeline; assets stored with signed-link retrieval so the customer’s content is only readable by the customer.

The shipped-client contract - the rule we ship under. Every endpoint a TestFlight or Play Store build has ever hit is part of the shipped contract. Additive-only changes: new optional fields, new optional parameters, new endpoints - fine. Renames, removed fields, required-parameter additions, response-type changes - only allowed after raising the version floor in the client config, shipping a new client build that self-enforces it, and waiting until the old-floor cohort is below 1% of usage. Then we verify the client at the new-floor tag no longer reads the removed field, in a change that references the bump. When in doubt, additive. That contract is enforced by a contract-snapshot harness - 155 tests against a real in-memory database seeded from production migrations - and shape drift fails the build before a release lands.

The migration discipline. Database changes apply through a gated step that’s idempotent against a migrations tracker, so a failed migration prevents the backend from deploying against a half-migrated schema. No on-the-fly fixes to production, no Wednesday-night manual change that breaks Thursday-morning customer-side flows. The story of what we’d build for your customer-facing app starts with we won’t break your shipped users when the next feature lands.

Subscription billing on both stores. Apple subscriptions through StoreKit, Google subscriptions through Play Billing, both with the receipt-verification and renewal-notification flow that catches grace-period downgrades and lapsed renewals before they become customer-support tickets. The same shape ports cleanly to one-off purchases, family-sharing entitlement, or a fully no-billing app where the value sits behind an account rather than a subscription.

The outcome

For Storytimebaker itself: a real product with real subscriptions, real users on TestFlight, and a backend that has stayed contract-stable across every iteration of the iOS build. Build 60 was submitted and withdrawn before approval - never in users’ hands, which the contract rule treats as distinct from shipped - and build 72 is the effective first-shipped client once Apple approves. The Android version-gate endpoints already exist on the server, so the client wires its version floor without blocking on the server when that release lands.

For our catalogue, Storytimebaker is the proof that we ship the full mobile-app-plus-server stack: native on both platforms, marketing site, serverless backend, contract testing, version-gating, App Store and Play Store billing integration, localisation, push-notification infrastructure. When a new client comes to us with “I want our own [gym / yard / nursery / repair-shop / clinic] app”, this is what we can build that actually means.

The shape ports cleanly across a member app for a gym, an equine yard or syndicate-owner app, a pet-services owner app, a parent app for a nursery group, an EV-installer customer-side app (charge-session history, warranty register, paperwork archive - referenced from the EV installer spoke), an independent-garage customer-side service-history app, and any vertical where the customer comes back often enough that an app earns its place on their home screen.

Which verticals this fits

The generic mobile-app-plus-server capability proof, referenced anywhere a custom customer-facing app is the build sketch:

Regular-return consumer-facing apps

• Gym fitnessincluding the personal-trainer spoke
• Pet servicesowner-side app
• Tutors and nurseriesparent-side app

Specialist verticals where the customer wants the app on their home screen

• Equineyard and syndicate-owner app
• Independent garagescustomer-side service-history app
• Trades - electricians / EV installercustomer-side warranty / charge-session app
• Agricultureround-side contractor app
• Holiday letsguest-side concierge app for portfolio operators

Which problems this solves

Generic mobile-app capability proof rather than a seed for any specific solution - but referenced where the build sketch is “and the iOS / Android app for your customer”:

• Customer & Third Party Portalthe native-app version of the per-customer portal
• Multi Channel Comms Threadthe app as one of the channels the thread runs across

Want a bespoke mobile app for your customers?

Tell us what they’d open the app for, how often they’d come back, and what “go to our website” currently fails to deliver. Tell us whether iOS-first or both-platforms-at-once matters for your customer base, and what the subscription / one-off / no-billing shape would be. We’ll come back with a sketch of what we’d ship native, what the backend would look like, what the version-floor / additive-only contract means for your business as the app evolves, and what the first three months would deliver. No demo, no calendar widget - email reply, scoped sketch, you decide.