Case study · Apps

Simply Rest

An idea with no brand, no screens, and no developer account, taken to a published Google Play listing. Here is every artifact that got produced along the way, in the order it got produced, so you can see what an app engagement actually hands you.

01Brand & prototype
02Design & build
03Published

The situation

Sleep sound apps are a crowded category and almost all of them run on subscriptions, accounts, and tracking. The gap was a paid-once app simple enough for someone in their seventies to operate half asleep in a dark room. No one had built that, so we did — on our own money, which is the part that matters here.

Simply Rest was not a client project. It is the one we funded ourselves, which means every decision, every mistake, and every artifact below is ours to show you in full. A studio that has only ever designed for other people has never had to carry a product through store review, payment plumbing, or a bug that only appears at three in the morning.

What got produced

Four stages. The same four we run on client work. This is the deliverable list, not a narrative — what you would receive, and roughly when.

Stage 01

Discovery

Before a single screen. Who it is for, what already exists, and what it should cost.

  • Competitive teardown. The subscription incumbents pulled apart on pricing, onboarding friction, account requirements, and what they do to you at 2am.
  • Target user definition. Older adults and the subscription-fatigued, written as a constraint rather than a poster. Every later decision was tested against it.
  • Pricing and positioning decision. A one-time $3.99 unlock, with the reasoning written down: competitor pricing, conversion psychology, and an explicit rejection of launch-discount gimmicks.
  • Accessibility constraints. Operable half awake, in the dark, by someone who does not want to learn an interface. This became the acceptance test for every screen.
Stage 02

Design

Brand and screens, built as a working prototype rather than a slide deck.

  • Brand identity. Name, mark, colour tokens and type, carried through to an adaptive Android icon set, a monochrome themed icon, splash art and a favicon.
  • Interactive HTML prototype. Not a mockup. A clickable, playable prototype held as the design source of truth for the entire build, and kept in lockstep with the app to the end.
  • Screen inventory. Five screens, full navigation, global state, and the empty and first-run cases most projects discover too late.
  • Documented interaction rules. What happens when a timer changes mid-playback. What the play state looks like. Each decided once, written down, and applied to both prototype and app.
  • Design rationale log. Including the things we tried and killed — a pulsing glow behind the play button was built, tested on a real device, and rejected.
Stage 03

Build

The working app, plus the production pipeline behind it.

  • React Native application. Built on Expo, with real-device builds sideloaded for testing rather than simulator-only validation.
  • Audio pipeline. Twenty sounds sourced or self-recorded, cut into seamless loops, loudness-normalised as a family so none jumps out, and pre-rendered for the app.
  • Background playback architecture. Rebuilt on a native foreground service after overnight testing proved the obvious approach silently fails. This is the kind of thing that only surfaces if somebody actually sleeps with the app running.
  • Purchase integration. One-time non-consumable unlock, entitlement handling, restore-on-reinstall, and refund revocation wired through to the store.
Stage 04

Launch

The paperwork and the assets. Usually the part nobody warns you about.

  • Store listing package. Short and full description, 512px icon, 1024×500 feature graphic, and captioned phone screenshots taken from the shipping build.
  • Compliance declarations. Data safety, content rating, store category, health-app declaration, and a foreground service permission declaration with the demo video it now requires.
  • Privacy policy. Written, styled to match the app, hosted, and its URL registered with the console.
  • Closed testing programme. Twelve testers recruited and run through a full fourteen-day cycle, including a complete purchase-and-reinstall validation.
  • Marketing and process suite. A set of PDFs built on a shared visual system — the collateral you hand to press, partners, or anyone asking what this is.

A look at the deliverables

Not every artifact, but the ones a client asks to see before signing anything.

Identity and palette

A sleeping crescent with a wave, built to stay legible at 48 pixels on a home screen and at 512 in a store listing. Adaptive and monochrome Android layers shipped alongside the primary mark, and the palette was fixed as tokens before a single screen was designed.

IDENTITY App icon Adaptive Monochrome PALETTE #212952#1A2047#F5C24A#FFFFFF#7E8ACB Simply Rest Sleep sounds. One payment. No accounts. View Demo
Brand sheet — swap for the real export

The screens

Five screens, no more. Each one was tested against a single question: could somebody operate this half awake, in the dark, without having seen it before? That constraint is why there is no settings screen, no onboarding carousel, and no account.

Welcome Choose sounds Play $3.99one time, foreverPurchase Demo
Screen flow — swap for real captures

The store package

The part most people discover two weeks after they thought they were finished. Feature graphic, icon at every required size, captioned screenshots taken from the shipping build, and every console declaration answered — data safety, content rating, category, health-app scope, and the foreground service permission with its demo video.

STORE PACKAGE Simply Rest Sleep sounds. One payment. Feature graphic 1024×500 Captioned screenshots 512px icon Console declarations All caught up
Store assets and console state — swap for real captures

The marketing plan

Built before launch, not after. Three channels, chosen because they suit a paid app with no ad budget.

Store optimisation

Title, short and full description, and screenshot captions written against the terms the audience actually searches — not the terms the category uses. The listing opens with a plain statement that it is not a medical device, which keeps it out of a regulated classification and reads as honest rather than defensive.

The channel that compounds.

Caregiver and senior-tech outreach

The buyer is frequently not the user. Adult children and caregivers choose apps for parents, and they read different publications, in different places, with different criteria. Targeting them directly is cheaper than competing for the general sleep-app keyword.

Find whoever actually pays.

The build story

One designer, no mobile experience, an AI-assisted build documented start to finish. That is a story press and communities will run, and it carries the app with it. The book is the long form of the same story, and each one sells the other.

Press, communities, and the book.
Marketing collateral was produced as part of the engagement, not bolted on afterwards: a suite of PDFs built on the same visual system as the app, so what you hand a journalist, a partner, or a potential buyer looks like it came from the same company as the product.

What changed

The app is live, the purchase works, and it survives the thing a sleep app has to survive: running all night, screen locked, without being killed or draining the battery.

The decisive finding. With the screen locked, Android suspends the app’s JavaScript. Native audio keeps playing, but shutoff timers never fire — so a thirty-minute timer played past thirty minutes and only stopped when the phone was unlocked. Nothing in a simulator shows you that. It took sleeping with the app to find it, and a rebuild on a foreground service to fix it.

$3.99
one payment, unlocks everything, forever
20
sounds, each processed into a seamless loop by hand
0
accounts, subscriptions, or tracking of any kind
12
closed testers through a full fourteen-day cycle
All night
verified playback, screen locked and app backgrounded

What this looks like for you

Same four stages, same deliverables, your idea instead of ours. Three things worth knowing before you start.

14 days

is the floor, not the estimate

Google requires twelve testers and a fourteen-day closed testing window before you can apply for production. Nobody gets under it. What we can compress is everything either side — and that is where projects normally lose months.

3 points

where we need you

Approving the direction after discovery, reacting to the prototype, and signing off the store listing. Between those, you are not in meetings. Most of our own build happened without a single status call.

You own it

all of it, outright

Source code, design files, prototype, brand assets, store account, and the listing. Published under your name or your company’s. No retainer required to keep it running, though we are happy to.

Want the whole method?

This page is the what and the in what order. Prompt to Play Store is the how — every prompt, every console field, and every failure, written up so you can run it yourself. Simply Rest is the app the book builds.

Have something that needs fixing

Tell us what you have and who uses it. We come back with what is wrong, what it is costing you, and what fixing it would take. If nothing needs fixing, we say that too.

Request an audit

Or building one yourself

Get told when the book lands, when a console section gets re-checked, and when a prompt in the library stops working. No other email, ever.

Join the list