How I Ship 10+ Products Solo
The actual principles, toolchain, and trade-offs behind shipping and maintaining a portfolio of software products as a single developer.
People ask how I manage to build and maintain this many products as a solo developer.
The honest answer is: not by doing everything. The slightly longer answer is that the question assumes a set of constraints that don't actually apply.
Let me explain what I mean.
The Portfolio
Robworks Software has over a dozen active products across three categories — Learning, Productivity, and Fun. Some of them are shipped and in production. Some are in active development. Some are early-stage experiments. They include a Mac App Store app with a CLI and MCP server, a K-12 education platform in beta, an Electron desktop app, two iOS apps, and several web services.
That is genuinely a lot for one person. Here is how it works.
Not Everything Is the Same Kind of Work
The first thing to understand is that "maintaining a product" spans a wide range of actual effort.
A shipped, stable Electron app with a small active user base doesn't require much ongoing work. You monitor for crashes, respond to support questions, and ship a bug fix when something breaks. That might be a few hours a month. An iOS app in active development is different — shipping to the App Store is a specific kind of effort, and TestFlight management and review turnaround add coordination overhead.
The mistake people make when looking at a product portfolio is treating every product as equivalent to a production SaaS with a growth team. Most of these products are not that. Some of them are utilities that I use myself and happen to have published. Hexal, my D&D hex crawl campaign manager, is an Electron app I built for my own tabletop campaigns. It has users because I open-sourced and distributed it, but the maintenance burden is low.
Understanding which products need active investment and which need only passive maintenance is the first layer of how this works.
Ruthless Scoping
The second principle: ship less than you think you should.
Every product in the portfolio started with a narrower scope than I initially imagined. QuikGIF's first version did one thing: record a screen region to a GIF. That was it. No settings, no presets, no upload integration. One thing, done well.
Feature creep is the tax that kills solo projects. You start with something small and useful, then spend three months adding things that seemed important during planning and turn out to be irrelevant to actual use. Meanwhile the thing you originally shipped goes unmaintained because you're always building the next feature.
My default approach: ship the smallest version that's actually useful. Then wait. See what users ask for. See what I need. Add only what the real usage pattern demands, not what I imagined the usage pattern would be.
This sounds obvious. It is genuinely hard to do because there is always a more complete version of the thing visible in your head.
Shared Infrastructure
Third: I reuse infrastructure aggressively.
Authentication, user management, analytics tracking, email delivery, storage — these are solved problems. Every project in my stack uses the same set of services: Supabase for auth and storage, Turso for database, Vercel for hosting, the same analytics setup. When I start a new project, I'm not choosing a database or figuring out session management. Those decisions are already made.
This matters more than it might seem. The cognitive overhead of maintaining six different auth systems, four different database configurations, and three different deployment pipelines is not zero. Standardizing on a stack means the infrastructure knowledge transfers between projects. I can debug a Supabase RLS issue on LessonCraft and immediately apply that understanding to a different service.
The same principle applies to component libraries and design systems. I maintain a shared set of UI components. A button in QuikGIF's web interface and a button on the Robworks Software site are built from the same component. Style changes propagate. Accessibility fixes propagate.
AI-Assisted Development
This one is real, and I think people underestimate how significantly AI tooling has changed solo productivity.
I use Claude Code as my primary development assistant. Not as a code generator I blindly accept output from — as a pair programmer I collaborate with. The distinction matters.
What this changes: the cost of context-switching between projects drops significantly. Coming back to a codebase I haven't touched in three months used to mean a multi-hour orientation session — reading old code, reconstructing mental models, figuring out where I left off. With an AI assistant that can read the codebase, summarize what it does, identify where I was in a previous session, and answer specific questions about implementation details — that orientation time compresses dramatically.
It also changes the cost of exploring unfamiliar territory. I am not an expert in every layer of every stack I'm using. When I need to dig into something I don't know well — SpriteKit physics for a game, SwiftUI animations for an iOS app, a specific Postgres query optimization — having an assistant that can explain, propose, and iterate means I'm not blocked by my own knowledge gaps in the same way.
I still make all the architectural decisions. I still review everything that goes into production. But the mechanical work of implementation moves faster.
Time Management Is Actually Portfolio Management
I'm a father of two. I also have accessibility constraints that make some kinds of work slower than they used to be. I have a finite number of productive hours.
This means I have to be explicit about where those hours go. I maintain a rough priority ordering of products: what needs attention this week, what can wait, what I'm actively building versus what I'm passively maintaining. That ordering changes, but having it makes the default answer to "what should I work on" obvious rather than requiring a decision every morning.
The failure mode for solo developers with multiple projects is not shipping nothing — it's shipping a little bit on everything and making sustained progress on nothing. Avoiding this requires actual prioritization, not just intention.
The Goal Is Not 10 Products
Here's the thing I want to be clear about: the goal is not to have a lot of products.
The goal is to build tools that solve real problems for real people. I happen to have found more than one such problem worth working on. The portfolio is a consequence of that, not an objective in itself.
Some of these products will grow into significant things. Some will stay small utilities that serve a narrow audience well. Some will probably get deprecated when the problem they solve no longer needs solving, or when a better solution exists.
What I'm not trying to do is maintain the appearance of a large portfolio. If something isn't working and isn't worth fixing, I'll shut it down. Sunsets are underrated.
The right number of products is however many you can build well and maintain honestly. For me, right now, that's somewhere around where I am. Ask me in a year.