MAKER GULLY
The email came in on a Sunday morning, which felt about right.
It was about one of the puzzle games. Nothing dramatic - a player had noticed that a screen looked slightly wrong after an OS update. Polite, helpful, the kind of message you're glad to get. And my first honest reaction wasn't gratitude. It was a small, tired sigh.
Because I'd basically forgotten that game existed. Not really, but in the way you forget a plant in the other room until the leaves start to droop. I'd shipped it, celebrated it for an afternoon, and moved on to the next thing. The player hadn't moved on. The product was still very much alive, and it was still very much mine.
That's the part the launch-day dopamine hides from you. You think you're crossing a finish line. You're actually signing an adoption paper.
The launch is the cheap part
Everyone frames shipping as the hard, heroic act. Build the thing, push it live, feel the rush. And it is a rush. I'm not knocking it - most of this newsletter is me arguing that you should ship more, and faster.
But the launch is a single moment. What you're actually committing to is every moment after it.
I've shipped a fair number of things through Maker Gully this year. Games, utilities, weekly puzzles that are supposed to keep running well into next year. Each one felt like a win the day it went out. What I didn't fully price in was that each one also quietly joined a list. A list of things that can now break, get a bad review, confuse someone, or need a fix at an inconvenient hour.
A team with a budget calls that list a "maintenance backlog" and assigns someone to it. When you're a team of one, that someone is just you, on top of everything else you're trying to build next.
The bill nobody itemizes for you
The costs don't show up on launch day. They arrive later, in small unglamorous pieces:
- The platform moves. An OS update, a browser change, a deprecated API. You didn't touch the code, and now it's broken anyway. Software rots even when you leave it perfectly still.
- People actually use it. Which is the whole point, and also the source of every support email, edge case, and "hey, is this supposed to do that?" you'll ever get.
- Your own memory fades. Six months later you're staring at code you wrote and can't remember why. Past-you is a stranger who left no notes.
- The little stuff compounds. One product is easy. Ten products, each needing an hour a month, is a part-time job you accidentally hired yourself for.
None of these are disasters on their own. Together, they're the reason a lot of solo builders slowly grind to a halt. Not because they can't build - because they're too busy keeping the last five things alive to start the sixth.
What actually keeps it survivable
I don't have a clever trick that makes maintenance disappear. It doesn't. But I've changed how I build so the future bill stays small enough to pay.
I build like I'll have to fix it half-asleep. Same instinct as the Tired Tuesday version of me picking a stack. Fewer moving parts today is fewer 2am mysteries later. Every dependency I add is a subscription to someone else's future breaking changes.
I leave notes for the stranger I'm about to become. A short README, a line explaining why a weird bit of code exists, a note on how to redeploy. It feels like overhead when you're excited. It feels like a gift when you come back cold.
I decide, on purpose, how much a thing is worth. Not everything deserves the same care. A weekly puzzle people rely on gets real attention. A tiny experiment gets an honest label: this is a toy, I may not maintain it. The mistake isn't having low-priority projects. It's pretending everything is high-priority and then quietly abandoning all of them equally.
I let some things go, deliberately. That doesn't always mean sunsetting the product itself. I recently retired the native iOS and Android versions of Feeder Rater and moved it to the web instead. The product is still available at the same URL, feeder-rater.makergully.com, but I no longer have two native apps to maintain alongside it. Sometimes letting go means choosing the version of a product you can realistically keep supporting. And sometimes it does mean winding a product down cleanly. A zombie project you refuse to either fix or bury is the one that actually drains you.
The part I had to make peace with
For a while this all felt like a reason to slow down. If everything I ship is forever, maybe I should ship less?
I landed somewhere else. The answer isn't to build less. It's to build knowing the full price, so the things I ship are things I'm genuinely okay owning.
That Sunday-morning email, the drooping-plant one? I fixed it that afternoon. Ten minutes, because past-me had left just enough of a trail to follow. And weirdly, I didn't resent it anymore. Somebody was still using a thing I made months ago and cared enough to tell me it was a little off. That's not a burden. That's the whole reason to do any of this.
The applause is loud and short. The upkeep is quiet and long. If you only build for the applause, the upkeep will bury you. Build for the long, quiet part, and the applause takes care of itself.
You don't ship products and walk away. You adopt them. So adopt fewer, adopt on purpose, and take care of the ones you keep.
That's the reality of being a team of one.
#TeamOfOne #BuildInPublic #IndieHackers #SideProjects #SoftwareMaintenance