OmaxTelecom

Challenge

Telecom products look simple in a slide deck and complicated in production: multiple upstream providers, unlike billing models, regulatory constraints on numbering, and partner expectations set by consumer-grade UX elsewhere.

Role

As CEO I set product direction and stay hands-on in architecture and delivery. That includes API design, portal workflows, provider onboarding, and the operational discipline required to keep services dependable.

Approach

Separate what is live for partners from what is still architectural exploration. Ship narrow, well-observed integrations first, then expand coverage. Keep white-label and partner portals aligned with the same usage and state models exposed over APIs.

Public service areas

• eSIM and data connectivity workflows partners can resell or embed.
• Wholesale SMS and messaging integrations with operational tooling.
• Phone number and VoIP-related services where documented publicly.
• Developer APIs and portals for partner self-service.

Architecture and roadmap (not all public modules)

Broader multi-provider telecom-as-a-service thinking (including OMAX TaaS direction) informs how we structure adapters and tenancy, even when every module is not yet a marketed product. I label those pieces as design and exploration until they ship with public documentation.

Technologies

Laravel and PHP for core platforms, Go for services and integrations, React for partner and admin experiences, PostgreSQL and Redis where they fit transactional and caching profiles, queue-backed jobs for provider calls, and infrastructure I host and monitor on Linux with Nginx and modern edge protection.

Status

Operating product with ongoing engineering. I do not publish traffic volumes, country counts, or revenue figures on this personal site.

Next steps

Continue tightening API clarity, provider adapter coverage, and observability for partner-visible incidents. Expand documented integrations only when they are stable for external use.