This one is less of a guide and more of an accounting. A year of small releases, run out of Delaware County, alongside other work, without a publisher — here's what actually changed our minds.
Some of it is what you'd expect. A fair amount of it is the opposite of what we believed going in.
Small games finish; big games teach you nothing
The most valuable thing about a small release isn't the release. It's that finishing forces you through every stage of the process — store submission, privacy disclosures, icon variants, a support address, the first bug report from a stranger — and you cannot learn any of that from a project that stays in development.
An unfinished ambitious game teaches you about your engine. A finished small game teaches you about the actual business you're in. If you've never shipped, the correct scope for your first project is embarrassingly small, and then smaller than that.
Launch day is not a thing
We planned around launch days the way you would for a console release: get everything perfect, ship, watch. For a small mobile title with no marketing spend, launch day is mostly indistinguishable from the day before it.
What matters instead is the slope afterwards — whether the store starts showing your app to people over the following weeks, which depends far more on conversion rate, ratings and how long people stay than on anything that happens in the first 24 hours.
The practical change: we stopped treating release as an event and started treating it as the beginning of a measurement period. The work that used to go into launch-day coordination now goes into the first month of iteration, which is where it does something.
Screenshots outperformed everything else we changed
Across the year, the changes that moved store performance most were not features. They were the first two screenshots and the subtitle.
That's a deflating finding when you've spent a month on a difficulty curve. It's also actionable: store page work is fast, cheap, reversible and doesn't require app review for some of it. If you have a limited number of hours and a game that's basically working, the hours go into the product page first.
The corollary we didn't expect: improving the store page also improved retention, not just installs. A page that accurately represents the game attracts people who wanted that game. Vague pages attract people who bounce.
Cadence beats polish beyond a threshold
There's a level of polish below which a game is unshippable, and we're firm about clearing it. Above that line, though, the returns fall off sharply, and the extra weeks would have been better spent on the next release.
Two releases a year that are each 85% as good as one release a year is a better trade for a small studio — more shots on goal, more store surface, more learning per calendar month, and a portfolio that cross-promotes itself. The failure mode is polishing a single title indefinitely because it's more comfortable than starting the next one.
Working around a day job is a scheduling problem, not a will problem
Most people making games in this region are doing it alongside something else. We are. The lesson isn't "work harder" — it's that fragmented time punishes certain kinds of work far more than others.
Deep design and debugging need long uninterrupted blocks and go badly in 45-minute gaps. Asset production, store copy, build configuration, documentation and testing survive fragmentation fine. So the calendar gets sorted by task type: the rare long blocks are reserved for the work that can't be chopped up, and everything else fills the gaps.
This sounds like productivity advice. It's really a scoping decision — it means choosing projects whose hard parts are small enough to fit in the long blocks you actually have.
Being local didn't sell a single download
We went in with a vague theory that a Philadelphia identity would help. It did not sell games. Nobody in another state downloads a puzzle app because of where it was made.
What being local did do was different and, in retrospect, more useful: real playtesters who watched us watch them, contractors we'd met in person, contract and consulting work that funds the game development, and a small number of people who now know what we do. That's not marketing. That's a business staying solvent between releases, which is the actual constraint on a small studio's survival.
Things we'd do differently
- Instrument before launch, not after. Retrofitting analytics means the first cohort — the one you most want to understand — is unmeasured forever.
- Build remote config into the first release. Every time we wanted to change a value quickly and couldn't, we lost days to app review that a config flag would have made instant.
- Localise store metadata immediately. The cheapest unclaimed distribution available to a small game, and we left it sitting for months.
- Write the store page first. If you can't write a compelling subtitle and three lines about the game before building it, that's information about the concept, not about your copywriting.
- Ask for ratings earlier and less apologetically. At the right moment, after a win. Ratings volume compounds and we started too late.
What stays the same
The core bet hasn't changed: small, finishable puzzle games, shipped often, built by a tiny team that owns its own tools and doesn't need permission from anyone to release. The genre suits the constraint, the constraint suits the region, and the cadence is what turns a year of work into a portfolio rather than a folder of prototypes.
If you're doing something similar around here — or thinking about starting — we'd genuinely like to hear about it. The scene is small enough that the people in it are findable, and a fair amount of what we know came from someone else being willing to answer an email.