The Musaned Origin Story: When the Vendor Says Build It Yourself

This is part 1 of a 10-part series on building Musaned, the internal Business Support System I built at Zain.

Every large telecom runs on a Business Support System. Ours did too — a vendor-supplied platform that handled the core of the business. But core is the operative word. The day-to-day reality of business teams is full of needs the core never covers: a lookup the system doesn't expose, a workflow that exists only in email threads, a report that takes three departments to assemble.

The standard answer is a change request to the vendor. And that's where our story starts: the quotes that came back for the functionality we needed were, to put it politely, prohibitive. Not "let's negotiate" expensive — "let's rethink our entire approach" expensive.

The build-vs-buy moment

Build-vs-buy debates usually revolve around risk. Buying feels safe: a contract, an SLA, someone to blame. Building feels risky: what if it never ships? What if the one engineer who built it leaves?

But there's a third option hiding inside "build": build small, prove value, and grow only as fast as trust grows. We didn't decide to replace the BSS — that would have been a fantasy. We decided to build a companion system for everything the BSS didn't do. That reframing mattered. It shrank the risk from "replace a mission-critical platform" to "ship one useful feature to one business team."

That companion system needed a name. In Arabic, Musaned (مساند) means "supporter" — the one who backs you up. That's exactly what it was scoped to be: not the star of the show, but the system that makes everyone else's job possible.

Starting alone

In 2023, Musaned started with a team of exactly one: me. That sounds heroic in a blog post; in practice it forced discipline that served the project well. When you're alone, every architectural decision is a promise your future self has to keep. You choose boring, proven technology. You automate deployment on day one because there's nobody else to do releases. You write code the next engineer can pick up — because you're building for the team you hope to have, not the team you are.

Most of the functionality that exists in Musaned today was built in that solo phase, before a teammate joined and my role shifted toward technical leadership. The lessons from that arc — what to build first, how to win skeptical stakeholders, which corners you can and cannot cut — are what this series is about.

What's coming in this series

Over the next nine posts I'll walk through the journey in detail: choosing Laravel and Filament as the stack, syncing employees over LDAP and enforcing strict RBAC, the very real pain of integrating PHP with Oracle and MSSQL, the integration architecture that kept dozens of connections manageable, the Voucher Query feature that put 2M+ records at the business team's fingertips, a BPM tool built for the CEO's office in one week, and the road from bare Linux servers to Docker images headed for OpenShift.

If you've ever looked at a vendor quote and wondered "could we just build this?" — this series is my honest answer.