What Is an Indie App Studio? Inside How We Ship 36 Apps

When people hear "app company" they usually picture one of two things: a venture-backed startup betting everything on a single product, or an agency building other people's ideas for a day rate. An indie app studio is the third thing — a small, self-funded team that designs, builds and operates its own portfolio of apps, and lives or dies by whether real users choose to keep them installed.

RiekApps is one of those studios. At the time of writing our portfolio spans apps, games and desktop tools — 36 products in total — plus the occasional client build. This post is a straight answer to the question in the title, and an honest look at how the model works from the inside.

The portfolio model, explained

A single-product startup concentrates all of its risk in one bet. A studio spreads it: many small products, each cheap to build and cheap to run, where a few winners pay for the experiments that didn't land. The economics only work if three things are true:

• Shipping has to be cheap. Shared infrastructure, shared design language, shared release tooling. The tenth app must cost a fraction of what the first one did.
• Products have to be small enough to finish. Every app in our portfolio does one job. Quicksign signs documents. TidyDisk cleans Mac disks. Scope creep is the studio killer, because an unfinished app earns nothing.
• Operating cost per app has to stay near zero. Which pushes you toward on-device processing, boring reliable stacks, and ruthless pruning of features that need servers to babysit.

What a week actually looks like

Studio work is a rotation, not a pipeline. In any given week some products are in maintenance (store updates, OS compatibility, support email), one or two are in active development, and there's usually a prototype being poked at to see whether it deserves to exist. The discipline is in the kill decisions: a prototype that doesn't feel right in two weeks gets shelved, not rescued. The portfolio model gives you permission to be wrong quickly.

Why small teams ship this much

It looks improbable from the outside — dozens of products, a team you could fit in a booth. The honest answer is that constraints do most of the work:

• No coordination tax. The person who designed the screen is the person who builds it. Decisions take minutes, not meetings.
• Reused bones. Analytics, purchases, onboarding, release scripts — solved once, copied everywhere. New products start at 60%, not 0%.
• One owner per product. Nothing waits in a queue for a specialist. Whoever owns the app fixes the bug, writes the store copy, answers the reviews.

Indie doesn't mean amateur

The bar users hold you to is identical whether you're a solo developer or a thousand-person company — the App Store and Google Play don't have an indie section with gentler reviews. Privacy policies, accessibility, support: table stakes. If anything the indie constraint pushes quality up in one specific way — with no marketing budget, the product has to earn its own installs through ratings and word of mouth. Our party games spread because a group plays one at a party and someone asks what it's called. There is no other growth plan.

Why users should care who built their app

Buying from an indie studio is like buying from a small workshop: the defaults are different. Our tools do their processing on-device because renting servers to hold your documents is a cost and a liability we don't want. TidyDisk is open source because for a disk utility, "trust us" is weaker than "read it". When you email support, the reply comes from someone who has the codebase open. None of this is virtue — it's just what the small-studio shape naturally produces.

The short version

An indie app studio is a small team running many small bets, funded by its own products, kept honest by its own users. It's not a stepping stone to becoming a startup — it's a different, older shape of software business: build useful things, charge fairly or not at all, keep the lights on, repeat. If that shape sounds appealing, the best introduction is the work itself — start with the apps, or say hello.