Five Things I'd Build Differently If I Started XenneX Today
Eighteen months in, the decisions that seemed right at the start look different from the other side. Here's what I'd change — not to relitigate the past, but because these are the things I'd tell anyone starting something new right now.
Eighteen months in, you see the decisions differently. Not with regret exactly — most of what we built is still standing and most of it still makes sense. But there's a shorter path from where we started to where we are, and it's visible now in a way it wasn't at the beginning.
Here are the five things I'd do differently.
1. Start with a design system, not a feature list
The first month of XenneX was feature planning. We had a list of things the product needed to do, and we started building them. The result: a codebase full of components that were built for their specific screen and nothing else.
Six months in we started a design system. The refactor took three weeks. Those three weeks would have been three days if we'd done it before any features existed.
The counterargument is that you don't know what the design system needs until you've built some things. That's true. The answer isn't to skip it — it's to build a rough version fast, deliberately, knowing it'll evolve. Even a basic token structure and a handful of reusable primitives would have saved us more time than it cost to create them.
2. Pick boring infrastructure
We made an interesting choice on the data layer early on. Interesting infrastructure has a tax: every time you onboard someone new, every time you debug something at 2am, every time you write a Stack Overflow question that returns zero results, you pay it.
Boring infrastructure is boring because everyone has solved its problems already. The solutions are documented. The error messages are googleable. The mental model is shared with every developer you'll ever work with.
We're not in the business of infrastructure novelty. We're in the business of shipping product. Interesting infrastructure is a distraction from that in ways that compound over time.
3. Ship an embarrassingly small v1
The features in XenneX v1 that survived to v1.5 are the features that would have been in a much smaller v1. The features that didn't survive were features we thought users would want that they didn't use, or features we built because they seemed like they should exist, or features we added because someone asked for them once.
The cost of those features wasn't just the build time. It was the design time, the QA time, the maintenance overhead, and the delay to shipping the things that actually mattered.
If I started over: whatever I thought the v1 scope was, I'd cut it in half. Then I'd cut it in half again. Ship that. The feedback from real users in the first two weeks is worth more than any amount of internal speculation about what people want.
4. Talk to 20 users before writing a line of code
The way users use XenneX is not the way we expected them to use it. The features they reach for first aren't the ones we built first. The friction points we've spent the most time fixing aren't the ones we anticipated.
We know all of this now because we have users and we watch them and we talk to them. We could have known most of it in week 2 if we'd done structured conversations before any code existed.
The objection is always "we don't know who our users are yet." You know enough. Find 20 people who look like your target user, ask them about the problem you're solving, watch what they do today to solve it. The product you design after those conversations is better than the product you design in a vacuum. Every time.
5. Write the docs before building the feature
This one sounds bureaucratic. It isn't.
If you can't write a clear, simple explanation of what a feature does and why a user would want it, you don't understand the feature well enough to build it. The documentation exercise forces the confrontation with that gap before you've already spent two weeks building something confused.
The other benefit: once you've written the docs, you've also scoped the feature. You know what it is and what it isn't. That scope is the feature. Scope creep during development is partly a documentation problem — nobody wrote down what the thing was, so the definition drifts as it gets built.
We do this now. We didn't do it in year one. The features we've shipped since we started doing it are cleaner, smaller, and more used than the ones from before.
None of these are original insights. They're the things every retrospective says, from every team, after every first product. The reason we keep saying them is that they keep being true, and they keep being ignored, and they keep mattering.
If you're starting something now: start with the design system, pick the boring stack, ship half of what you think v1 is, talk to users first, and write the docs before the code.
You'll still make other mistakes. But these five won't be on your list.