You can launch an MVNO in under 30 days but only if three things are already sorted before you touch the BSS: your MNO/MVNE agreement is signed, your SIM vendor is confirmed, and your brand and plan pricing are locked. If those inputs are in place, the BSS itself provisioning, billing config, OCS, self-care can be stood up in weeks, not quarters. SaaS deployment removes infrastructure setup from the critical path entirely. What actually kills timelines is MNO testing queues, SIM batch errors, and billing config gaps none of which are BSS problems. This post walks through what happens in each week and what you need to prevent the predictable delays.
Yes, You Can Launch an MVNO in Under 30 Days
If you want to launch an MVNO quickly, the 30-day timeline is real but it depends almost entirely on what you have ready before the BSS is involved. Operators who hit that timeline arrive with their MNO agreement signed, their SIM vendor locked, and their product catalog decisions already made. The BSS stands up the stack; it does not wait for you to make commercial decisions.
The 6-to-12-month estimate you may have been quoted is usually accurate for legacy BSS procurement hardware sourcing, custom integration work, lengthy vendor professional services engagements. A SaaS BSS changes the math because infrastructure setup disappears from the critical path. What remains is provisioning, configuration, integration testing, and UAT all of which move fast when the platform is pre-built and your inputs are ready.
This post breaks down the 30-day launch week by week, explains what the actual delay causes are, and gives you a checklist to verify you are genuinely ready before committing to a go-live date.
What Actually Takes So Long in a Traditional MVNO Launch?
Most MVNO launches that stretch past six months share the same failure pattern: the BSS is not the bottleneck, but the BSS evaluation process is. Legacy platforms require an RFP cycle, vendor shortlisting, proof-of-concept negotiation, procurement sign-off, hardware provisioning, and then a professional services engagement before a single subscriber profile is configured. That sequence alone can consume a quarter.
After procurement, traditional BSS integrations require custom development work to connect the provisioning gateway to the MNO, to wire up the OCS for real-time charging, and to build the self-care layer. Every integration point is a potential three-to-four-week queue and queues stack.
Then there are the delays that sit entirely outside the BSS. MNO testing queues the window your host network allocates for end-to-end testing are often the single longest fixed delay in an MVNO launch. Regulatory filings for number range allocation move on government schedules. SIM batch procurement has manufacturer lead times. None of these speed up because you chose a faster BSS. What a modern BSS does is ensure it is not adding its own delays on top of the unavoidable ones.
The 30-Day MVNO Launch: What Has to Be in Place Before Day 1
The 30-day clock does not start when you sign the BSS contract. It starts when all of the following inputs are confirmed and handed to the BSS team. If any of these are missing, be honest with yourself the timeline extends accordingly.
| Pre-condition | What it means in practice |
| MNO/MVNE agreement signed | Roaming, interconnect, and wholesale rate terms confirmed in writing. Without this, no provisioning gateway can be configured. |
| SIM vendor confirmed | Blank SIM inventory ordered and in transit. SIM batch import into the BSS cannot happen without physical inventory — and SIM manufacturers have lead times. |
| Number range allocated | Regulatory filing complete and number block formally assigned by your national regulator. This runs on government schedules, not yours. |
| Brand and product catalog decided | Plan names, pricing tiers, data allowances, roaming policy, and add-ons locked. The BSS team cannot configure billing rules against a moving product catalog. |
| Legal entity and payment processing ready | Merchant account live, invoicing tax configuration available, and consumer protection compliance confirmed for your market. |
One thing experienced operators learn quickly: the MNO testing window is the fixed point everything else orbits. If your MNO has confirmed a test slot for week two, your SIM batch needs to be in-hand before that window opens and your provisioning gateway needs to be integration-ready before it starts. Work backwards from the MNO testing date to set your actual go-live target, not forwards from your BSS contract date.
Step-by-Step: How to Launch an MVNO in 30 Days
The following assumes SaaS BSS deployment, which removes infrastructure provisioning from your timeline entirely. Private cloud and on-premises timelines will vary based on your infrastructure readiness see the deployment model comparison below for details.
Week 1: Platform Setup and Configuration
Week one is BSS configuration, not BSS installation. On a SaaS platform, the environment is already running. Your team or the vendor’s implementation team if you are on a managed service handles the following in parallel:
- Subscriber profile configuration: Data fields, identity attributes, account structure, and plan associations for your subscriber type (prepaid, postpaid, or both).
- Product catalog build: Every plan, bundle, add-on, and promotional offer entered into the catalog. This is where your pre-Day-1 business decisions translate into BSS configuration. Incomplete pricing decisions at this stage are the most common source of week-one delays.
- Billing rules and rating configuration: Voice, data, and SMS rating tables. The convergent billing engine needs to know exactly how to rate every chargeable event before network testing can begin.
- SIM batch import: Your SIM inventory imported as an encrypted batch from the SIM manufacturer. ICCID, IMSI, and authentication key data loaded into the subscriber management layer. This is why having your SIM batch in-hand before week one matters — import failures discovered here push the MNO test window.
- OCS (Online Charging System) configuration: Real-time charging policies for prepaid balance management, quota enforcement, and session control. If you are launching prepaid-only, this is critical path.
By end of week one, a test subscriber should be provisionable in the BSS and an internal test SIM should be able to authenticate against the platform.
Week 2: Network Integration and End-to-End Testing
Week two is where the BSS connects to your host MNO’s network. This is the highest-risk week in the schedule because the MNO’s testing queue is the one variable entirely outside your control.
- Provisioning gateway integration: The BSS provisioning gateway connects to your MNO or MVNE’s network element. Subscriber activations, plan changes, and suspensions need to flow in both directions — from BSS to network, and network events back to BSS.
- OCS / real-time charging validation: Data sessions triggered from test SIMs must hit the OCS correctly. Balance deductions, quota enforcement, and session teardown on exhaustion verified against live network traffic — not a staging environment.
- Call and data session testing: Voice call records, SMS delivery, and data session records all need to flow through to the billing system and produce correct CDRs. A single misconfigured rating rule creates billing errors at scale once you go live.
- MNO signoff testing: Your host network runs its own acceptance tests. Book this window as early as possible — rescheduling an MNO test slot can cost you one to two weeks depending on their queue.
Practical note on MNO testing queues
The MNO testing window is a fixed slot, not a continuous resource. If your provisioning gateway is not production-ready when the window opens, you go to the back of the queue. The practical rule: have integration work 90% complete before you book the MNO test slot, not after. Never book the slot as the forcing function to finish the integration.
Week 3: Self-Care App, Customer Onboarding, and UAT
Week three shifts from network to subscriber-facing systems. Your subscriber needs a way to activate their SIM, check their balance, and manage their account without calling a support agent.
- White-label self-care app and web portal: The BSS self-care layer configured with your brand (colors, logo, domain), linked to your live product catalog, and tested against real test accounts. Plan change flows, top-up, usage display, and account activation all need UAT sign-off.
- Customer onboarding flow: SIM activation journey tested end-to-end: subscriber enters SIM detail → identity verification → plan selection → provisioning trigger to MNO → first successful data session confirmed.
- Support team training: If you are running a contact centre or agent channel, your CRM view of subscriber accounts, ticket logging, and plan change workflows need to be demonstrated and practiced before go-live. Support team confidence is a go-live gate.
- UAT sign-off: A structured user acceptance test covering all plan types, top-up methods, self-care flows, and billing edge cases. Do not compress or skip UAT to recover time lost in week two UAT failures post-launch are significantly more expensive than UAT failures in week three.
Week 4: Soft Launch, Monitoring, and Go-Live
Week four is a controlled soft launch followed by full commercial go-live. Do not go straight to a public launch. A soft launch with a limited subscriber set internal staff, friends, family surfaces the remaining edge cases without the risk of billing errors at commercial scale.
- Soft launch (Days 22–25): 50–200 real subscribers on the live network. Monitor billing accuracy, provisioning success rates, self-care usage, and support ticket volume for at least 48 hours before widening. Any critical billing bug found here triggers a hold, not a workaround.
- Monitoring dashboards live: Revenue, session counts, OCS balance movements, provisioning success rates, and self-care login volume should all be visible in real time before the public launch. If you cannot see what is happening in the network, you cannot catch problems before they compound.
- Go-live decision gate: A pre-agreed, written criteria list: zero critical billing bugs, provisioning success rate above an agreed threshold, self-care accessible and tested, support team confirmed ready. Commercial launch does not happen on a calendar date it happens when the gate is passed.
- Public launch (Days 26–30): Marketing channels go live. Acquisition campaigns start. On-call escalation path is in place and the team knows who gets paged for what severity of issue.
MVNO Launch Checklist: The 15 Things You Need Before Going Live
Use this as your pre-launch gate. Gate items are hard stops if any Gate item is open, your go-live date is not confirmed. Pre-launch items must be completed before public launch but can run in parallel with soft launch preparation.
| Sr. Number | Checklist Item | Type |
| 1 | MNO/MVNE wholesale agreement signed — roaming, interconnect, and wholesale rate terms confirmed | Gate |
| 2 | Number range allocated — regulatory filing complete, number block assigned by national regulator | Gate |
| 3 | SIM inventory in hand — encrypted SIM batch from manufacturer, imported into BSS subscriber management | Gate |
| 4 | Product catalog configured and signed off — every plan, bundle, add-on, and promo offer entered and tested | Gate |
| 5 | Billing and rating configuration validated — all chargeable events produce correct CDRs in test environment | Gate |
| 6 | OCS / real-time charging tested — balance deductions, quota enforcement, session teardown verified on live network | Gate |
| 7 | Provisioning gateway integration complete — activations, plan changes, and suspensions flow correctly to MNO network | Gate |
| 8 | MNO acceptance test passed and signed off — do not proceed without this | Gate |
| 9 | Self-care app or web portal live and tested — activation journey, plan change, top-up, and usage display all verified | Gate |
| 10 | Fraud controls active — velocity limits on top-up, SIM clone detection, and dunning rules configured | Pre-launch |
| 11 | Regulatory filings complete beyond number range — consumer protection and data privacy compliance confirmed for your market | Pre-launch |
| 12 | Support flows operational — ticket logging, escalation paths, and refund process documented and tested | Pre-launch |
| 13 | Payment processing live — merchant account active, invoicing configured, payment failure handling tested | Gate |
| 14 | Go-live monitoring dashboard active — revenue, provisioning, OCS, self-care all visible in real time | Pre-launch |
| 15 | Go-live decision criteria agreed in writing — specific pass/fail thresholds for billing errors, provisioning rate, and self-care uptime | Gate |
Which BSS Model Is Right for a Fast MVNO Launch?
The deployment model you choose determines how much of the 30-day window gets consumed by infrastructure setup before a single subscriber profile is configured. Here is an honest comparison of the four options Alepo supports.
| Deployment Model | Time-to-Launch | Infrastructure Overhead | Best Fit |
| SaaS BSS (e.g. BSSNow) | Fastest — weeks from provisioning to go-live | None. Vendor runs the infrastructure. | New MVNOs, lean ventures, ISPs entering mobile. |
| Private Cloud (AWS / Azure / GCP) | Weeks to months — depends on your cloud readiness | Moderate — you own the cloud account and ops | Regulated markets with data-residency requirements. |
| On-premises | Months — hardware procurement alone adds weeks | High — datacenter, networking, ops team required | Operators with existing datacenter commitments or strict sovereignty rules. |
| Managed Service | Fastest (equivalent to SaaS) — vendor runs everything | None — people, process, and platform included | Operators launching fast who want zero internal ops burden. |
For MVNOs launching a new brand or entering a new market segment, SaaS deployment such as the Alepo BSSNow SaaS platform removes infrastructure procurement from the critical path entirely. The environment is pre-provisioned; the implementation team starts on configuration, not servers. BSSNow is positioned for launch ventures, MVNOs, and ISPs entering mobile where fastest time-to-value and lowest operational overhead are the priority.
Private cloud is the right choice when your regulator requires data residency within a specific jurisdiction and SaaS hosting does not satisfy that requirement. Expect to add two to four weeks for cloud environment setup if you are starting from scratch.
On-premises is the slowest option for a new launch. Hardware lead times, datacenter provisioning, and network configuration consistently push weeks onto the timeline before the BSS team can begin configuration work. This model makes sense for operators with existing datacenter commitments or strict data sovereignty mandates not for a new venture trying to reach market in 30 days.
For context: when SaskTel launched Lüm Mobile, Canada’s all-digital MVNO brand, they used Alepo’s zero-touch MVNO operations approach, which allowed subscriber onboarding and service management to run without manual intervention at each step. That architecture where provisioning, self-care, and billing all operate without agent involvement for standard subscriber journeys is what a fast-launch, digital-first MVNO actually looks like in production.
The Alepo Digital BSS platform runs the same convergent billing, OCS, self-care, and provisioning stack across all four deployment models. The core BSS capabilities are consistent; only the infrastructure arrangement changes.
What Can Go Wrong and How to Avoid It
The four delays below appear in almost every MVNO launch that misses its target date. None of them are surprises they are predictable, and they are preventable.
1. MNO Testing Queue Delays
Your host network allocates test windows based on their internal schedule, not yours. If your provisioning gateway is not production-ready when the window opens, you are rescheduled. The fix is not to work faster it is to treat the MNO test window as your launch date and work backwards from it. Everything in weeks one and two should be sequenced to have integration work ready before the test window, not during it.
2. SIM Batch Errors
SIM batches imported with incorrect encryption keys, missing ICCID ranges, or mismatched authentication data cause provisioning failures that take significant time to diagnose. By the time you discover the problem in week-two testing, your SIM manufacturer is the critical path. The fix: order a test batch of 50–100 SIMs before your production batch ships and validate them end-to-end SIM import, BSS provisioning, and network authentication before the production order is placed.
3. Billing Configuration Gaps
The BSS rates what it has been told to rate. Undefined edge cases roaming data sessions, failed top-up retries, plan change mid-cycle proration, add-on expiry handling appear in UAT as unbilled events or incorrect charges. Each gap requires a billing rule change, retesting, and re-UAT. The fix is a structured configuration review against your complete product catalog before the MNO test window opens, not after. Any plan you cannot describe precisely in billing terms is a plan that will create UAT failures.
4. Self-Care UAT Failures
Self-care is consistently tested last and fixed under time pressure. Activation journey failures, broken top-up flows, or app crashes on specific Android devices discovered in week three require development cycles that slip the go-live by a week. The fix is to allocate UAT time proportional to your product catalog complexity more plan types means more activation paths to test and to include device diversity in your test matrix from the start.
ACS Myanmar demonstrated what happens when these inputs are handled before the BSS engagement begins. They signed tens of thousands of subscribers within the first month of launch a result that is only possible when provisioning, billing configuration, and self-care are all validated before the commercial launch date, not patched after it.
FAQs
Can a startup really launch an MVNO in 30 days?
Yes, with two conditions met. First, the commercial inputs MNO agreement, number range, SIM inventory, product catalog are finalized before the BSS engagement begins. Second, you choose a deployment model that does not add infrastructure setup to the BSS timeline. A startup that signs a BSS contract and simultaneously starts its MNO agreement negotiation is not on a 30-day schedule, regardless of how fast the BSS team works. The 30 days cover BSS configuration, integration, testing, and go-live they do not cover the commercial groundwork.
What is the minimum viable BSS for an MVNO launch?
At minimum: convergent billing (prepaid or postpaid depending on your model), an OCS for real-time charging, a provisioning gateway that connects to your MNO, and a subscriber self-care layer. A product catalog is not optional without it, the billing engine has nothing to rate against. The Alepo Digital BSS includes all of these in a single convergent stack. If your MVNO is digital-only and prepaid, you can defer physical point-of-sale, dealer management, and voucher modules to post-go-live and add them without a platform migration.
What is the difference between an MVNO and an MVNE?
An MVNO (Mobile Virtual Network Operator) is the brand that sells mobile services to end subscribers. It holds a commercial relationship with the subscriber and is responsible for billing, CRM, and customer experience. An MVNE (Mobile Virtual Network Enabler) is the wholesale enabler sitting between the MNO and the MVNO it provides the technical and operational infrastructure (network connectivity, BSS, sometimes regulatory licenses) that an MVNO needs to operate without building its own network stack. Launching via an MVNE agreement typically reduces MNO agreement complexity and can shorten the pre-Day-1 timeline, since the MVNE has existing interconnects with the host network.
How much does it cost to launch an MVNO using a SaaS BSS?
BSS cost depends on subscriber scale, deployment model, support tier, and the modules you need at launch versus those you add later. The Alepo BSSNow SaaS platform uses subscription-based pricing — OPEX, not CAPEX — which removes the large upfront infrastructure investment that makes traditional BSS procurement expensive for new launch ventures. The right starting point is a scoped discussion with the Alepo sales team based on your specific configuration: subscriber projections, services in scope, geography, and go-live timeline.
Ready to Plan Your MVNO Launch?
If your MNO agreement is close to signing and you want to understand what a sub-30-day BSS deployment looks like for your specific configuration. The session is scoped to your launch requirements not a generic platform walkthrough.
Book a Demo to Explore BSSNow
