Twelve Years of XenneX. What I'd Actually Tell the Version of Me Who Started This.

XenneX started in 2014. I was building software before that, but 2014 is when it became a studio with a name and an intention. Twelve years later, I'm still at it — 6+ apps live, more in various states of existence, and more hard lessons than I could fit in a single post.

I'm going to try anyway.

What Was Actually Hard

The hardest thing wasn't the technical work. I knew how to build software. The hardest thing was learning to make decisions with incomplete information on a timeline that didn't give me the luxury of being sure.

Every product decision a one-person studio makes is a bet. You're betting that the problem is real, that your solution is good enough, that the timing is right, that you can maintain it alone. You're making all those bets at once, with imperfect information, and the feedback loop is slow. It takes months to find out if you were right.

For the first few years, I was bad at this in a specific way: I was too careful. I would wait until I was sure before shipping, which meant I was almost never shipping. I confused thoroughness with quality. The version of me who started XenneX needed to understand that shipping something imperfect is not the same as doing bad work — it's actually the only way to find out what good work looks like.

What I Got Wrong Early

I built features nobody asked for. The canonical founder mistake, but knowing it's a cliché doesn't make it easier to avoid when you're deep in a product and convinced you know what users need. I spent months on features that went unused and skipped conversations that would have told me what actually mattered. The fix — more user conversations, less speculative building — sounds simple and was not easy to actually implement.

I underpriced everything. The first instinct when you're a solo developer is to price for adoption. You want users, so you price low. What I learned, slowly: the users you get by pricing low are often not the users who will tell you what to build. Paying customers are more honest. They have a stake in it. The decision to raise prices was always scary and always correct.

I tried to do too many things at once. This is the trap of the multi-app studio — at any given point, there are 6 products that could each use attention, and the temptation is to spread effort across all of them rather than concentrating it. The apps that improved fastest were the ones I gave my full attention to for a defined period. The ones that stagnated were the ones that got 20% of my attention for years.

What I'd Do Differently

I'd ship smaller initial versions. The first version of almost every XenneX app was more complete than it needed to be. I was trying to build something I was proud of before anyone had told me it was worth building. In most cases, a version with half the features would have gotten to the same answer in half the time.

I'd build more in public. The indie dev community has gotten significantly better at this since 2014 — people share more, document more, build more transparently. I was fairly private early on. The posts I've written in the last few years about what I'm building and why have generated more useful feedback than anything I did in the first five years.

I'd accept co-founder conversations earlier. I've run XenneX mostly solo, with collaboration on specific products (Nion Lights being the clearest example). The collaborations have consistently been the most productive periods. I spent longer than I should have treating "solo studio" as an identity to protect.

What I'd Do Exactly the Same

I'd still have started it. 2014 was the right moment — I had enough experience to build real products and enough naivety to not be paralyzed by how much I didn't know.

I'd still build multiple products. The instinct to run a portfolio rather than go all-in on one app has been validated over 12 years. Individual apps have failed, flopped, gotten acquired, and changed direction. The studio is more durable than any single product in it.

I'd still be the one writing the code. Delegating the core technical work has never felt right for how I want to work. The ability to go from idea to shipped in a week — sometimes a few days — is only possible because I'm not waiting for anyone. That speed is worth a lot.

The Version of Me Who Started This

He was confident in the wrong things and uncertain about the right things. He was good at building and bad at shipping. He was better at solving technical problems than product problems, and he didn't know that yet.

I'd tell him: the technical skill is the easy part. The hard part is learning to make decisions under uncertainty, to ship before you're ready, to have the conversations you're avoiding, and to be honest about what's working and what isn't.

He wouldn't have listened. I didn't listen when people told me these things. You have to figure it out the long way.

Twelve years. Still figuring it out.

---

XenneX is a one-person studio shipping iOS apps since 2014. See what's in the lineup →