For a long time I thought "simple" meant clean UI and fewer bugs. If the layout was tight and the app felt fast, I assumed I was on the right track. That was wrong, but in a subtle way. Simple is not what the builder sees. Simple is what the user understands in the first few seconds. And getting to that point is rarely about adding one more polish pass. It is about removing things you already built, things you were proud of, things that felt like progress at the time.
Illustration about cutting down to a simple solution. Created with GPT Image.
Simple looks easy from the outside
When you look at a product that feels obvious, you do not see the versions that came before. You do not see the features that got cut, the screens that got deleted, the ideas that sounded smart in a meeting and turned out to be noise. You just see the result and think: of course it works like this. Why would anyone build it differently?
That is the trap. Simple looks like less work. In reality it is more decisions. Every time you say yes to a feature, you are saying no to clarity. Building simple is complicated because you have to fight your own momentum. Adding feels productive. Cutting feels like going backwards. But most of the time, cutting is the actual product work.
I learned this across three apps I still care about. From building too much, explaining too much, and watching people nod politely before they stopped using what I made.
SWIQ: the link was the product
With SWIQ I wanted to help people make decisions. Which haircut? Which outfit? Which logo? You create a question, others vote. On paper that is simple. In my head it became a social app. Register, set up a profile, stay inside the app, discover challenges, build a feed. I was proud of the UI. It was fast and clean and modern. And still I got stuck on a question I should have asked on day one: why would someone install an app and go through a whole flow just to vote on ten or thirty challenges?
It did not make sense for the user who only wanted a quick opinion. It made sense for me because I was thinking like a founder who wants retention, not like someone who wants to remove friction. Asking friends to "try my app" never felt cool. It felt like asking for a favor. Every time I did it, I sensed I was not selling the product. I was selling a hurdle.
The simple solution was not prettier buttons. It was removing a step entirely. Anonymous voting on the web, without an install. You get a link, you tap, you vote, you are done. People used it because it worked in the moment they needed it. The product became the link, not the app store page.
That was uncomfortable at first. Simple, in this case, meant accepting that the best version of SWIQ might live outside the app I originally imagined.
Ballin: too much to explain in one sentence
Ballin went the other direction. I built a complex app because complexity felt like depth. Many ideas, many corners, many "we could also do this" moments. I was excited about what it could become. And at some point I could not explain the core in one sentence anymore. Not in a embarrassed way. In a warning-sign way. If I as the builder cannot say what the app is for, how should a new user know?
There was a shareable object in there from the start: the player card. In theory that was the simple core. Something you create, something you send, something that works even when nobody else is online yet. In practice I buried it under everything else I wanted Ballin to be. I kept building the big vision instead of perfecting the one moment where someone says: I want that card.
Monetization made it worse. What should cost money? Why would anyone pay? I had answers in my head, but none of them felt natural because the product itself was not simple enough.
Today, when I think about Ballin, I start with a different question. What does the user want to do in the first ten seconds? That question hurts because it forces you to kill ideas you still like.
Ballin is still ahead of me. It is not in the stores yet. That gives me time to cut before I ship again. I would rather cut now than launch something I have to explain.
Fupla: one question instead of an ecosystem
Fupla taught me the same lesson from a different angle. Football, players, opponents, clubs, camps, pitches. Many sides, many connections, a lot of potential. I built too many features without a clear starting point and without a small local community to grow from. At one point I had around four hundred users. That sounds good on paper. In reality they were not active. The app existed, but not much happened inside it.
I allowed tournaments without promoting them properly, without having the right users for them. Again the pattern: I built something that should work when everyone else is already playing along. Not something that already makes sense for one person on a Tuesday evening who just wants to find a game.
The simple version came late. Not "everything for football," but one concrete question: I am looking for football. One need, one region, one moment. Not a social network for the whole sport on day one. That focus did not arrive because I planned it perfectly. It arrived because the broad version stopped moving.
Fupla is in the app stores now. I am still sharpening that focus. Being live means you can no longer hide behind "we will simplify later."
What I do differently now
I still love building. I still get excited about new ideas. The difference is where I start. Before I write code, I try to describe the one moment that works for user number one. Not the roadmap. Not the platform. The moment. With SWIQ it was the vote via link. With Ballin it should be the card. With Fupla it is the search for a game.
I prototype faster and polish less at the beginning. A beautiful screen for a feature nobody needs is still waste.
I am also suspicious of the sentence "we could also." Every "also" is a small tax on clarity.
Simple is finished when you are slightly afraid you removed something important, and you ship anyway.
For builders who feel their app is too much
I am writing this for people who are building something right now and sense that it is too heavy. Maybe your app needs a tutorial. Maybe you explain it three times and still get polite nods. Maybe you keep adding because adding is easier than choosing. I have been there on all three projects.
SWIQ and Fupla are live. Ballin is still coming. I am not writing this as a success story. I am writing it as a logbook entry about a skill I am still learning: how to find the simple solution, which is usually the one you did not build first.
Simple products look obvious after the fact. Before that, they are rejected ideas, dead screens, and uncomfortable conversations with yourself. Building simple is complicated. That does not mean you are bad at it.
If you are in the middle of that process, I hope this helps you feel less alone. I will keep reporting how that goes. What I remove, what I keep, what works, what stalls again. Not as marketing. As notes to myself, and maybe as a mirror for someone else who is still holding the scissors.