Every app I've ever used has asked the same thing of me, quietly, without saying it out loud: adapt.
Learn the system. Work within the structure. Figure out where you fit inside the logic someone else designed. And if it doesn't quite work for you — that's a you problem.
I'm neurodivergent. I've been paying that tax my entire life. The cognitive cost of bridging the gap between how a tool works and how my brain actually works is real, and it accumulates in ways most builders never think about because they never had to.
That's what I'm building against. Not a better productivity app. A different premise entirely — software that conforms to you, not the other way around.
Personalization Is Not a Feature. It's the Premise.
Most product teams treat personalization as a layer — a settings page, a preference center, a few toggles. That's not personalization. That's the illusion of it.
Real personalization means the software makes decisions based on who you are, so you don't have to keep making them yourself. You shouldn't have to configure your way into a good experience. The experience should already be shaped around you before you touch a single setting.
I learned this firsthand with my own newsletter — and honestly, I learned it the hard way.
A few years ago, I built a segmentation system that let subscribers choose what they wanted to receive. Business content only. Personal writing only. Everything. Each section had a tag, each tag had a segment. What I was actually testing was a thesis: that the same content, delivered to the wrong person, becomes noise.
What I didn't tell anyone: I was running the entire segmentation manually before the automation existed. Every week, by hand, quietly, in the background — because I needed to prove the thesis before I built anything real around it. It was tedious. It was worth it.
The proof came from who left.
I lost subscribers — people who had been on my list for years — not because my writing got worse, but because an edition about my personal life landed in an inbox that only wanted business strategy. They told me directly: "This is the third time you've written about your personal life. I'm here for your business thinking. If I want to know how you're personally doing, I'll reach out to you directly."
And those same people had been on my list for years. They weren't strangers. They just knew exactly what they came for — and I had stopped giving it to them, at least in the editions they were receiving.
At the same time, other readers wrote back to say the personal writing was the only reason they stayed. That it made them feel less alone. That they needed to hear it.
Same newsletter. Same words. Completely opposite needs. Both completely valid.
The content wasn't the problem. The routing was. The same signal becomes noise when it lands in the wrong context. Personalization isn't about tone — it's about architecture. And delivery architecture is part of product design.
I've Watched This Problem From the Inside
This isn't just something I experienced with my own work. I've seen it up close working for other people too.
I once worked for someone who had built a newsletter with three very distinct audiences — students, hiring managers, and senior professionals who had been in their fields for years. Three completely different people with three completely different needs, all on the same list. All receiving the same emails.
The way she was managing it was through Airtable. Manually segmenting the data, separating the audiences, trying to keep track of who should get what. It was an enormous amount of work just to do something that should have been automatic. The content was good. The infrastructure around it was exhausting her.
That experience stuck with me. Because the problem wasn't her newsletter. The problem was that the tools assumed one audience. She had three. And nothing in the existing ecosystem was built for that reality.
That's the gap I keep coming back to. Not a gap in content quality. A gap in how software thinks about the people using it.
2026 Is Going to Split in Two
This year is going to produce two very different kinds of builders, and from the outside they'll look almost identical at first.
The first kind is architecturally literate. They understand what they're building beneath the surface — the data structures, the security model, the failure modes. AI accelerates them, but they know what they're shipping.
The second kind is interface literate but not systems literate. They can prompt their way to a working product without understanding what's holding it up. The tools let them ship. The gaps in their understanding will catch up with them — and with their users.
I say this with a security background, not to be alarmist. But I know exactly what happens when people build without understanding their attack surface. Data leaks are coming. So are the people who'll position themselves as the solution afterward.
And look — I'm building a lot right now too. Some of it probably won't matter. But I'm doing it to understand. Different data structures, different architectures, different ways of modeling the same problem. You don't get that from reading about it. You get it from building, breaking, and building again. I'm in the middle of that process and I'm not going to pretend otherwise.
What will separate the builders who matter isn't output volume. It's whether they're oriented toward an experience or just toward a product. Whether the question driving them is what does this feel like for the person using it — not just does this technically work.
What I'm Actually Building
The architecture: one unified database. Python scripts and cron jobs segmenting and routing data in the background. AI sitting on top, making structural decisions about what surfaces to each user — not generating a bespoke experience from scratch for every individual (that doesn't scale), but shaping what each person sees based on who they are and what they've actually told you they need.
The piece I'm most focused on right now is rethinking how feature requests work — because the current model has a flaw nobody talks about enough.
The standard flow: user submits a request → voting board → team reviews what got upvoted → decides whether to build → user waits, usually indefinitely. The flaw is structural. Vocal users dominate the queue. The majority of your audience — people who feel the same friction but never say anything — stay invisible and stay underserved. Only five people asked, but eighty of them wanted the same thing.
Here's what I'm building instead.
A user asks for a focus mode that hides analytics after 6pm. An AI agent researches it, tests an implementation, and builds it. Then — instead of asking whether anyone else wants it built — it's already built. We send an email:
"Hey, someone asked for focus mode this week. We built it. Click here to add it to your experience. Don't click anything if you don't want it."
One click. It exists only in your interface. Nobody else's experience changes.
This is the model I keep coming back to: semi-closed, semi-open. You subscribe to a product that grows in the directions its users actually need — but you get to choose which of those directions become part of your experience. You're not waiting for a committee to decide your request was worth building. You're not forced to use something just because someone else asked for it. You opt in. Or you don't. Your experience stays yours either way.
Why This Is Personal
I'm neurodivergent. Most software assumes I am not.
The way my brain works — how I process information, how I move through tasks, how my energy shifts across a day — doesn't map onto the defaults baked into most tools. And so I've spent years doing what a lot of people in this situation do: quietly working around systems that almost fit. Adapting myself to the tool instead of the tool adapting to me. Spending cognitive energy on the friction between how the software works and how I actually think, before I've even started the actual work.
That's the invisible tax. And it accumulates.
I think about this a lot when I think about what I'm building. Because the goal isn't just a smarter product. It's to eliminate that tax for people who've been paying it their whole lives without anyone acknowledging it existed.
The bar I'm holding Namos Labs to: when you open it, it should feel like it was already expecting you. Not something you configure into shape. Not something you teach yourself before it becomes useful. Something that already knows a little bit about how you work — and gets better at knowing the more you use it.
The Premise, Restated
The future of software is not smarter apps. It's adaptive ones.
We've spent decades building for the fictional consistent user — asking real, inconsistent, beautifully complicated people to adapt to systems designed for someone they've never been.
We have the tools now to actually flip that. To build software that listens, learns, and meets you where you are — without asking you to shrink yourself to fit its logic.
That's the work. Imperfect, ongoing, not fully shipped yet. But the direction is clear.
Software should feel like it was expecting you.
