Why I build small.
Most of the apps on my phone do too much. The ones I use every day do one thing. I want to build the second kind, so I built the studio around that posture: one small app per quarter, by one person, on purpose.
When I left my last contract, the obvious move was to build a big app. Pick a hot space, raise a small round, hire two people, ship in twelve months. That is the conventional path. I did not take it.
I picked the opposite. One person. No round. One app per quarter. Apps that you can describe in a sentence, that work without an account, and that stay on the homescreen because they earn it. The studio's name is beg1nner because nobody ships their best work in their first quarter, but you can ship work that is honest about being small.
The math that made it click
A startup that builds a sprawling app makes a bet that goes something like this: 18 months of runway, a feature set big enough to sustain venture-level growth, and a hope that the market wants it. Most fail. The survivors look back at the original feature set and realize that maybe 10% of it mattered.
My math is smaller and less interesting. If I ship one focused app per quarter, after eight quarters I have eight apps. If even three of them find an audience, the studio is real. If none of them do, I have eight finished products to point at when I look for the next contract.
That is a much lower-variance bet than "one big swing." The upside is smaller. The downside is also smaller. For a one-person operation, that is the right shape of bet.
What "small" actually means here
I do not mean "MVP" small. I mean complete small. The apps I have shipped so far each solve one specific problem really well and then stop:
- rece1pt stores receipts on your iPhone and tells you when warranty windows close. It does not do tax, it does not do budgeting, it does not have a social feed.
- m1nesweeper is the classic, rebuilt. Daily seed, no logins, no daily-streak harassment. You play, you win, you close the tab.
- n0n0gram is sixty hand-designed nonogram puzzles. There is no procedural generator, no microtransactions, no "energy" to refill.
Each one would be a feature in a bigger product. I think that is exactly why they are good. Removed from a bloated parent, they breathe.
The trade-offs I accept
Building small means turning down a lot of nice things. Investors mostly do not care about a one-person studio that ships small apps for low prices. The press cycle is shorter. The compound effects of an enterprise sales motion are not available to me.
What I get in exchange:
- I ship. A small surface area means I finish things. Eight quarters in, three live apps and a fourth in the oven. No drawer of dead prototypes.
- I do not have a roadmap committee. Every "should we build X" question is one person deciding, which means decisions take minutes.
- I keep the studio at the size I can love. No team meetings, no Slack noise, no agency-style billing hours.
- I sleep. Quarterly cadence forces honest pacing. No twelve-week crunches.
What I think builders get wrong
The common advice is "validate before you build." I think that is good advice for big companies and mostly noise for a one-person studio. A founder validates by shipping, watching, listening, and shipping again. If I run a Typeform survey before I build something, the answers are mostly polite hallucinations of what people think they would do. If I ship a small thing they can actually try, the answers are real.
The other piece I push back on is "build for scale." I am building for one person to maintain, forever. That changes every architectural decision. No microservices, no Kubernetes, no GraphQL layer in front of a wrapper around a cache. SQLite, plain HTTP, a single static frontend. If a future me hates a piece of code, that is a sign I built it for someone else.
What is next
The current build is SHELFLIFE, app #04. I will not say what it does yet because the rule is that the studio talks about apps after they exist, not before. The /upcoming page tracks progress with honest percentages, not press releases.
If you build solo, or you are thinking about it, the only advice I have that I am confident is true is this: make the thing small enough that you can finish it before you lose interest, then ship it, then start the next small thing.
Everything else is taste.