Built something internally to reduce chaos at work — looking for early feedback
We built an internal tool to solve a problem we kept running into as a team — too many tools, too much context switching, and work getting fragmented.
It started as a simple internal fix, not a product.
Now it’s at a stage where we’d like a few thoughtful teams to try it and tell us what actually works and what doesn’t.
We’re not selling anything and not launching publicly yet — just looking for honest feedback from people who deal with this kind of chaos daily.
If that sounds relevant to you, happy to connect privately.
www.omnex.tech
admin@omnex.tech
This is a great problem area — context switching and state fragmentation are huge drainers of developer productivity.
One thing I’ve noticed in similar internal tools is that the signal of value isn’t just “does someone open it?” but whether it changes the pattern of developer actions — e.g., less time reopening multiple apps, fewer lost focus sessions, quicker re-entry into prior tasks.
From a feedback perspective, are you tracking specific behavior signals (like reduced time to resume coding, fewer window switches per interruption, or fewer context leaks) rather than just usage counts?
That kind of evidence often tells you whether a tool is actually reducing friction or just getting used occasionally.
This resonates a lot, and you’re spot on about the difference between “getting opened” and actually changing behavior.
Right now, we’re prioritizing time to meaningful re-entry after interruption as the strongest early signal. Specifically: when someone comes back after a context break, do they land in a state where the next action is obvious without hunting through Slack threads, tickets, or docs.
Secondarily, we’re watching for repeated context reconstruction patterns—how often users bounce between tools or re-open the same artifacts to remember “where things were left.” Early usage suggests that when conversations, decisions, and artifacts stay bound together, those lookups drop noticeably.
We’re intentionally not over-optimizing for usage counts yet. If OMNEX is doing its job, people should come back to it unprompted at moments of uncertainty—handoffs, async gaps, or mid-task re-entry. That’s the behavior we’re trying to earn.
Still very early, but this framing is exactly what we’re pressure-testing with current beta users. If you’re curious to try it yourself, we’re opening early access here: https://omnex.tech (no credit card), and the feedback loop is very open right now.
Appreciate you pushing on the measurement side—this helps sharpen what we double down on.
This is a really solid framing, especially the bias toward forward momentum over archival history — that’s where a lot of internal tools quietly fail.
One thing that might be interesting to pressure-test as you scale:
does “time to first purposeful action” stay low even when the original context owner is unavailable?
In teams I’ve seen, that’s the moment where tools either become a real coordination layer… or regress into passive notes.
Either way, appreciate how clearly you’re defining success signals early — refreshing to see measurement driving the product, not vanity usage.
This resonates. In my experience, tools like this often surface a deeper issue than the workflow itself — how many parallel threads people are juggling and how fragmented decision-making becomes over time.
Curious what surprised you most once others actually started using it.
That’s exactly the tension we’re exploring. What surprised us most wasn’t how much people were switching, but how quickly decisions became fragmented once context lived in different places — even with good tools.
We’re testing whether collapsing that fragmentation into one shared surface changes how people think and decide, not just how fast they move.
If you’re curious to experience it yourself, you can check it out here and request early access: omnex.tech
It’s still in beta, and real feedback is shaping the direction.
Happy to chat or answer anything at support@omnex.tech.
This really resonates — especially separating internal momentum from real pull.
I’m exploring this exact question while building a reflective decision tool, and I’d love to learn how you recognize signal in practice.