CURIOUS WHERE THIS LEADS?
support@atraxia.org
Most companies begin with a plan: a product, a market, a timeline. We have plans too, but they come second. First comes a question we can’t stop asking.
It usually starts somewhere unglamorous: a workflow that takes four extra steps for no good reason, a tool that almost works, a problem everyone’s quietly adapted to instead of solving. We notice it, and then we can’t stop noticing it. That’s the part that doesn’t show up in a pitch deck, the itch that comes before the business case.
Centium started this way. Not from a market-sizing spreadsheet, but from watching how disconnected the pieces of someone’s health actually are. The data lives in one app. The professional guidance lives somewhere else entirely. There’s no real link between the two. The plan came after we understood that gap, not before.
We think that order matters. A plan built on a real question tends to survive contact with reality better than one built to justify an opportunity. It’s slower at the start. It’s usually worth it by the end.
This is the thinking we’ll keep sharing here. Not polished conclusions, but the questions behind what we’re building, as we’re still working through them.
It’s easy to say the client comes first. Almost every company says it. It’s harder to say no to a feature a client is actively asking for, paying for, maybe even frustrated about not having, because it doesn’t actually serve what they need.
That’s the distinction we try to hold onto: what a client wants in the moment and what actually moves them forward aren’t always the same thing. Giving someone exactly what they ask for feels responsive. It isn’t always right.
This shows up constantly in healthcare-adjacent products. Someone wants a feature that makes a number look better on a dashboard. What they need is to understand why the number is what it is, and what to do about it. The first is easier to build and easier to sell. The second is the harder, slower work of actually being useful.
Being client-centric, to us, doesn’t mean saying yes to every request. It means taking the request seriously enough to ask what’s underneath it. Sometimes that means building something different from what was asked for, because it’s what the person actually needs.
That costs trust in the short term. A client who doesn’t get the feature they asked for can feel unheard. But we’d rather earn that trust back by being right than keep it by being agreeable.
The first solution to a problem is rarely the right one. It’s just the first one you thought of. There’s a real difference between those two things, and it’s easy to lose sight of it when a deadline is close and the obvious answer is sitting right there.
The obvious answer usually looks like whatever the last product you used did. It’s familiar, it’s defensible in a meeting, and it ships fast. None of that makes it correct for the problem in front of you.
We’ve learned to treat the first idea as a starting point, not a destination. The real question isn’t “does this work?” Almost anything works well enough to demo. The question is whether it’s actually the right shape for the problem, or just the shape we reached for because it was closest.
That usually means sitting with a problem longer than feels comfortable, sketching out two or three alternatives even when the first one seems fine, and being willing to throw away work that technically functions but doesn’t actually solve the thing.
It’s slower. It also means what we ship tends to still make sense six months later, instead of becoming the thing we quietly patch around.
Working in health and wellness means running into a particular kind of temptation often. Not the temptation to cut corners, but the opposite: the temptation to add. A feature that would work. A data point that’s technically available. A capability that’s genuinely possible to build.
“Yes, we could” is a dangerous sentence in this industry. Just because something is technically possible doesn’t mean it belongs in a product that handles someone’s health information. Every additional piece of data collected is something that has to be protected, explained, and justified. Every added capability is something a user now has to understand, even if they never asked for it.
We’ve turned down features that would have been easy to build and easy to market, because the honest answer to “should we build this” was no, even when the answer to “can we build this” was yes. That’s not a popular stance in a culture that rewards shipping fast and shipping often.
But health products carry a different weight than most. Someone trusts us with information about their body, sometimes their most sensitive information. That trust doesn’t get earned by how much we build. It gets earned by how carefully we decide what not to.
So we keep asking the harder question first. Not “can we,” but “should we,” and we’re comfortable with the answer sometimes being no.
“Simple” gets used as a compliment so often that it’s started to mean almost nothing. Everyone says their product is simple. Most of them aren’t. What they usually mean is that it looks clean, which is a different thing entirely.
Real simplicity isn’t about how something looks. It’s about how much a person has to think to use it correctly. A screen can look minimal and still be confusing, if the thing it’s asking you to do doesn’t match how you actually think about the problem. A screen can look busy and still be simple, if every piece of information on it is exactly where you’d expect to find it.
We’ve rebuilt the same screen more times than we’d like to admit, not because it looked wrong, but because using it required remembering something, or guessing at something, or backtracking to fix something. Those are the real signs that a design has failed at simplicity, even if it passed every visual review.
The harder version of our job isn’t adding capability. It’s absorbing complexity somewhere the user never has to see it, so the interaction in front of them stays obvious. That usually means more work on our end, not less. Simple, done properly, is rarely the easy option for the people building it.
That’s the standard we hold ourselves to: not whether something looks clean, but whether someone can use it correctly without having to think about it. If it fails that test, it isn’t simple yet, no matter how it looks.