Validating an idea: can reducing context reconstruction beat adding more features?
I’m validating an idea that came from a repeated internal pain: work isn’t slow because tools are bad—it’s slow because context gets lost between them.
After interruptions (handoffs, weekends, async work), people spend time reconstructing:
• what this task is about
• what was decided
• what’s blocked
• what happens next
I built OMNEX as an early prototype to test a narrow hypothesis:
If conversations, tasks, files, meetings, and decisions stay tied to the same work unit, people can resume faster without re-reading or app-hopping.
What I’m testing right now
• Which moment creates pull: mid-stream task pickup, async handoffs, or next-day returns
• Whether users reopen the product unprompted after interruptions
• Where this helps vs. where it just centralizes noise
Current state
• Working beta (no pricing, no launch)
• Small number of early users testing real workflows
• Iterating based on usage + direct feedback
I’m looking for people who enjoy idea validation and aren’t afraid to say:
• “This is unclear”
• “This doesn’t solve my problem”
• “This is interesting, but only if…”
If you want to poke holes in the thesis or try it briefly to give honest feedback:
👉 https://omnex.tech
Happy to share what we learn—especially the parts that don’t work.
Had the same problem. Now I use tractionway before building anything - polls early adopters in 24hrs. Saved me from a few bad ideas already. Way better than asking friends who just say "sounds cool."
That makes a lot of sense — polling early adopters beats “sounds cool” feedback every time.
What we’ve noticed though is that even after validation, teams still struggle once real work starts — not with what to build, but with keeping context intact as work spreads across tools.
OMNEX is less about idea validation upfront and more about reducing context loss after a decision is made and execution begins. Curious if you’ve seen that gap show up post-validation too.