Coding a startup - Defining OMX nodes

Source: Dev.to

Background

I’ve been working on my project called Oxinion. Alongside it, I received some likes and stars on an open‑source library called supabase-markdown.

Challenges

• Lack of real users – Without actual users, everything feels hypothetical. I can build features, refactor systems, and plan architectures, but it’s hard to know if I’m truly moving forward or just circling the same ideas.
• Feedback gap – Progress exists in code, but not in feedback, and that gap slowly turns into doubt.
• Validation vs. vision – The small validation from open‑source stars is real and encouraging, yet it feels modest compared to the larger vision I have, making the ambition feel heavier than motivating.
• Motivation – I keep telling myself I’m lazy, but it might be inconsistency or the absence of pressure that real users naturally create. When no one depends on the work, it’s easy to slow down, overthink, or postpone decisions.

Current Plans

The original plan was never small. The ecosystem includes:

B2C side

• A location‑based social media product with rewards.
• Oxinion Finance.

B2B side

• Oxinion for Business – Allows business owners to use geo‑first workflows to create campaigns (ads, rewards, location‑triggered actions).
• OMX (Oxinion Marketing eXchange) – Designed as an AWS‑style model with SDKs and modular services for developers.

The platform is available at .

Next Steps

For now, the goal is simple: keep going, even when the feedback loop is silent. Build, write, and trust that consistency will eventually create its own momentum.