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 resonates. Internal tools turning into products is a very real path.
One thing I’ve seen help at this stage is validating where the pain is strongest:
– Is context switching the core pain, or the lack of a single “source of truth”?
– Which role feels this most daily (ICs, managers, founders)?
If you can narrow it to one job-to-be-done and one persona, feedback gets much clearer fast.
Curious what surprised you most when the team started using it daily.
Completely agree — narrowing to a single job and persona has been essential, otherwise everything turns into a vague “all-in-one” problem.
What surprised us most internally was that context switching wasn’t the pain by itself. The sharper pain was losing decision context — why something was decided, what state a task was in, or what mattered next — once work moved between conversations, tasks, and docs.
The role that felt this most day-to-day was individual contributors in cross-functional work. Managers and founders feel the overview pain, but ICs felt the constant need to reconstruct intent just to keep moving.
That’s pushed us to focus less on becoming a single “source of truth” and more on preserving intent as work flows — keeping the why, the discussion, and the next action connected.
Still early, but that shift in framing was one of the biggest learnings once we started using it daily.
if Curious, check https://omnex.tech and fill the early access form to receive the link of omnex app (no credit), for any questions feel free to mail us at support@omnex.tech .
That distinction between context switching and losing decision context is sharp — most teams misdiagnose that.
One thing I’d watch closely as you validate this:
whether users naturally anchor decisions forward (“what happens next?”) or backward (“why was this decided?”).
In my experience, tools that try to preserve both often win adoption only if they bias toward one direction early — otherwise the product risks becoming a passive archive instead of an active guide.
Curious which moment creates the strongest pull right now:
• picking up a task mid-stream
• joining a decision late
• or handing work off across teams?
That’s a great distinction, and I agree with the risk you’re pointing out.
Right now, the strongest pull we’re seeing is picking up a task mid-stream. People come back asking “what was I doing and what’s blocking me?” more often than “why was this decided?” — especially after a gap or interruption. That’s pushing us to bias forward first, not backward.
We’re intentionally treating decision history as supporting context, not the primary surface. The goal is to help someone act immediately, with just enough “why” visible when needed — otherwise it does drift toward becoming a passive archive.
Joining a decision late and cross-team handoffs are very real problems, but early on they’re noisier and harder to isolate. Mid-stream task re-entry is showing up more consistently and feels like the cleanest wedge to earn trust and daily pull.
If we get that moment right, the backward-looking and handoff cases can layer on naturally. If we don’t, none of the others matter.
This framing has been useful — it’s helped us be more opinionated about what not to solve yet.
This is a really clean wedge.
One thing you might consider as you measure this:
not just whether people return after interruptions, but whether they stop reopening Slack/Jira first.
If OMNEX becomes the default “re-orientation surface” before other tools, that’s a strong displacement signal — even without replacing anything yet.
Curious to see how that metric evolves as usage deepens.
This resonates a lot, and you’re articulating exactly the line we’re trying not to cross.
Right now, the strongest signal we’re watching isn’t raw usage or “returns after interruption” alone, but what users don’t open first anymore. In early testing, the clearest pull so far is when people re-enter work and go to OMNEX before Slack/Jira/docs to understand “where am I and what happens next.”
The moments that seem to create the most value today are:
• joining a decision late (new reviewer / new executor needing the “why + next step” fast)
• handoffs across async gaps (overnight, weekend, timezone)
• and picking up work mid-stream when ownership shifts
We’re intentionally biasing toward the forward anchor (“what’s next and why”) rather than trying to perfectly preserve everything backward. If we don’t do that, as you said, it risks becoming a passive archive instead of an active guide.
Still very early, but the working hypothesis is:
If OMNEX becomes the default re-orientation surface before other tools, even without replacing them, that’s the wedge worth doubling down on.
Appreciate you pushing on this — it’s shaping how we’re deciding what not to build as much as what to build next.
This makes a lot of sense — “mid-stream task re-entry” is a very clean wedge.
One thing that might be worth watching as a validation signal (if you aren’t already):
not how often people return after an interruption, but how fast they regain clarity once they do.
If users can answer “what should I do next?” in seconds instead of minutes without scanning other tools, that’s a strong behavioral pull — and hard for alternatives to compete with.
Sounds like you’re doing the right thing by biasing forward first and letting the other cases layer on only if this earns daily trust.
We’ve been deliberately biasing toward mid-stream task re-entry as the first wedge, exactly for the reason you mentioned: clarity beats completeness early. Right now, the primary signal we’re watching is time-to-clarity after re-entry — how quickly someone can answer “what should I do next?” without opening Slack, Jira, or digging through docs.
In early usage, the strongest pull so far shows up after async gaps (overnight / handoffs). When people return, OMNEX becomes the first surface they open to re-orient, even if they still execute elsewhere. That “default re-orientation surface” behavior is what we’re treating as the leading indicator before we worry about deeper displacement.
We’re intentionally not trying to preserve every state upfront — forward momentum first, history later if (and only if) this earns daily trust. Still very early, but this feedback is directly shaping how we measure and what we build next.
Thanks again — this kind of perspective is gold at this stage.