MAKER GULLY
It was a one-line fix.
Honestly, it was embarrassing how small it was. A label in Tap and Call that read a little off in the dark mode. The kind of thing you'd notice, frown at, and forget. I caught it, fixed it in about ten minutes, and felt that little hit of satisfaction you get from tidying something up.
And then I remembered I couldn't actually ship it.
Not yet. It had to go into a review queue first. So there I was, sitting with a fix that was done. Tested, ready, correct. And I still couldn't get it to the people who'd been staring at that clumsy label. I'd have to wait days to fix a ten-minute problem.
I remember just sitting back in my chair, a bit deflated, thinking: this doesn't feel right.
I'd built Tap and Call the way you're supposed to. Native iOS. Native Android. Because that's what a real product looks like, right? Real products live in the stores. Anything less felt like I hadn't fully committed.
But that night, holding a fix I wasn't allowed to give anyone, I started quietly asking myself who I was really building for.
The part nobody warns you about
Everybody talks about the 30% cut. That one's easy to see and easy to complain about.
The cost that actually got to me was quieter. It was time, and it was doubled effort, and it was the slow drip of both.
Two native apps meant I built everything twice. Every feature, every screen, every little decision, once for one platform and again for the other. Some weeks it felt like I was doing double the work just to stand still. And even after all that, nothing reached people when I was ready. It reached them when a reviewer somewhere got to it.
When it's just you, that's more than annoying. It quietly takes away the one thing you actually have going for you.
I can't outspend anyone. I can't out-hire anyone. The only edge I've ever had as a team of one is that I can move. See something, fix it, ship it, learn from it, all before a bigger team has finished scheduling the meeting. The review queue took that edge and put it on ice. And I hadn't really noticed how much it was costing me until I was sitting there with that one small label.
Turns out I was late to the argument
I'd love to say I figured all this out on my own. I didn't. I just finally admitted something other people had been saying for years.
David Heinemeier Hansson, the guy behind Ruby on Rails and one of the founders of Basecamp and HEY, has been loud about this for a long time. When Apple rejected HEY and threatened to yank it from the store, he didn't just eat it and move on. He pushed back, pointed at the open web, and basically asked: why are we asking permission to ship our own software?
The first time that really landed for me, it stung a little, because I'd been the one dutifully standing in line.
His point was never that native is bad. It's that somewhere along the way we started treating the store as the product itself. But nobody thinks Figma isn't real because it opens in a browser. Nobody feels shortchanged watching Netflix without installing anything. The web didn't make those things lesser. It just let the people building them keep their hands on the ship button.
That was the reframe I needed. The store wasn't the finish line. It was one road to my users, and for what I was building, it was the long way around.
What I got back
So I moved Tap and Call to the web. Same product, same features, just a shorter path between me and the people using it.
Here's what actually changed, day to day:
- I stopped building everything twice. One codebase. All that energy I'd been spending keeping two apps in sync went straight back into the product.
- "Fixed" and "live" became almost the same moment. I make a change, push it out, and it's there. Minutes, not days.
- There's nobody standing between me and my users anymore. Something breaks at 11pm, I fix it at 11pm. Not next Thursday, pending someone's approval.
That last one is really the whole thing. For a team of one, being able to ship the second you're ready isn't a nice-to-have. It's the difference between a product that keeps learning and one that just sits there between releases.
I won't pretend it's all magic. The web has its own headaches, and I've met most of them. But the trade felt like finally being handed back my own steering wheel.
To be fair to native
I don't want to swing all the way to the other side and tell you native is dead. That's just the same stubbornness pointed in the opposite direction.
And I'd be lying if I did, because I still build native apps. Most of the games I've made are apps. FlashDrop, a little utility of mine, is an app. None of them are especially complex, and that's kind of the point. They live on the phone because that's where they make sense: quick to open, tapped at a red light or on the couch, and in most cases they have no reason to route through a browser.
Which is what makes the Tap and Call story funny in hindsight. My simplest projects stayed native. My most involved one moved to the web. If complexity were really the deciding factor, it should have been the other way around.
So the line was never "complex things go native, simple things go on the web." That framing is comfortable and wrong. The real question is what the product actually needs. Deep hardware access, heavy offline use, an experience that has to feel platform-perfect down to the last gesture, those earn native its weight. A fast-moving product whose whole advantage is how quickly it can change does not.
That should be a choice you make on purpose, not a default you inherit. Ask what this specific product needs, not what a "real" product is supposed to look like. For a lot of software, especially the kind one person builds alone, the web now does the job with far less drag.
The goal was never a badge on someone's home screen. It was to close the gap between noticing a problem and fixing it, over and over, faster than anyone else can.
The moment shipping needs someone else's approval, you've quietly given away the thing that made you quick in the first place. I moved Tap and Call to the web to take that back.
I didn't leave the stores because native was too hard. I left because I was tired of asking permission.
That's the reality of being a team of one.
#TeamOfOne #BuildInPublic #WebDev #SideProjects #IndieHackers