33 — Future Roadmap¶

This document outlines planned improvements, known technical debt, and the long-term vision for PyroRadius. Items are organized by time horizon and priority. All items below are aspirational unless explicitly marked as in-progress.

Last reviewed: 2026-07-13

Immediate Priorities¶

These block safe scaling and should be addressed before adding any significant new features.

1. Proper Test Coverage¶

Why urgent: PyroRadius has zero automated tests. Every production deploy is validated manually. A mistake in BillingService or RadiusService causes real financial loss or customer outages.

What to build first: - PHPUnit tests for BillingService (invoice generation, payment application, renewal) - PHPUnit tests for RadiusService (RADIUS table writes, sync correctness) - PHPUnit tests for all permission gates (4 roles × key endpoints) - Playwright E2E tests for customer recharge flow and login

Estimated effort: 2–3 weeks for meaningful coverage of critical paths.

See also: 30_Testing.md for detailed testing strategy and example code.

2. Staging Environment¶

Why urgent: There is no staging environment. All changes go directly to production. This makes it impossible to test database migrations, UI changes, or new features safely.

Proposed setup: - Separate VPS or AWS EC2 instance (smaller/cheaper tier) - Mirror of production database (anonymized customer data) - Separate .env with APP_ENV=staging - Domain: staging.pyroradius.pyronet.com.pk - Deployments to staging first, then production

Estimated effort: 1–2 days to set up the server; ongoing benefit is significant.

3. CI/CD Pipeline¶

Why urgent: Manual deployments are error-prone. A CI/CD pipeline enforces the feature branch workflow and automates the deploy steps.

Proposed stack: - GitHub Actions (already using GitHub for git hosting) - On PR open: run PHPUnit, run Playwright against staging - On merge to master: auto-deploy to staging, run smoke tests, require manual promotion to production

Minimum viable pipeline:

# .github/workflows/ci.yml
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run PHPUnit
        run: php artisan test
      - name: Build frontend
        run: npm run build

Estimated effort: 1 week to implement basic CI; staging environment must exist first.

Short-Term Improvements (1–3 Months)¶

TR-069 Completion¶

TR-069 (CWMP) integration with an ACS (Auto Configuration Server) is partially built but disabled in production (ACS_ENABLED=false). When enabled, this would allow:

Remote device configuration (router parameters, firmware updates)
Automated CPE provisioning (customer routers auto-configure on recharge)
Device diagnostics (signal levels, connection history) pulled from ACS

What remains: - TR-069 pages in the frontend need completion - ACS connectivity needs to be tested with real CPE devices - The ACS_ENABLED flag needs to be wired through all relevant UI components

Status: Backend partially ready; frontend pages marked as incomplete in Known Issues.

Mobile App (FCM Ready)¶

Firebase Cloud Messaging (FCM) is already integrated in the backend for push notifications. A companion mobile app for dealers and field technicians would use this.

Use cases: - Dealer receives push notification when a customer expires - Field technician can see customer ONT signal level on-site - Customer receives payment confirmation push notification - Admin receives alert when a NAS goes offline

Proposed stack: React Native (shares React knowledge from the web app) or Flutter.

Status: Backend FCM ready; no mobile app exists yet.

WhatsApp 2-Way Conversations¶

Currently, WhatsApp is outbound only (PyroRadius sends; customer cannot reply meaningfully). A 2-way chat system would allow:

Customer replies "PAID" → system logs the intent and flags for admin review
Customer replies "HELP" → system sends support contact details
Dealer can chat with customers through the PyroRadius interface

Proposed implementation: WhatsApp Business API webhook to receive incoming messages, store them in a whatsapp_messages table, surface them in a new "WhatsApp Inbox" page for dealers.

Advanced Billing Reports¶

Current reporting covers basic invoice and payment summaries. Finance needs:

Monthly revenue by dealer (with drill-down to sub_dealer)
Outstanding dues aging report (30/60/90 days overdue)
Customer churn rate by package
New activations vs. deactivations trend
Tax reports (if applicable to Pakistan FBR requirements)

Proposed implementation: New Reports section in the admin UI, export to Excel/PDF, scheduled email delivery of monthly reports.

Multi-NAS Load Balancing¶

Currently PyroRadius supports multiple NAS (Network Access Servers) but traffic routing between them is manual. Automated load balancing would:

Distribute new PPPoE connections across available NAS devices
Detect NAS failure and failover customers to a backup NAS
Show per-NAS utilization on the dashboard

Medium-Term Improvements (3–9 Months)¶

Customer Self-Service Portal Expansion¶

The current self-service portal (if it exists) allows basic account viewing. Expand to:

Customer pays their own invoice via payment gateway (see below)
Customer changes their own WiFi password
Customer views their own usage history and invoice history
Customer submits a support ticket

Automated Invoice Generation with WhatsApp¶

GenerateMonthlyInvoices is an Artisan command. Currently it must be run manually or via cron. Full automation:

Run on the 1st of each month automatically
Generate invoices for all active customers
Immediately send WhatsApp notification with invoice amount and due date
Send reminder on the 25th (5 days before month end) to customers with unpaid invoices
Auto-suspend on expiry date (currently requires manual action or existing cron)

Payment Gateway Integration¶

Accept online payments from customers directly:

JazzCash, Easypaisa (Pakistan's dominant mobile payment wallets)
Bank card payments (via PayFast or similar Pakistan-supported gateway)
Payment received webhook → auto-applies to outstanding invoice → extends expiry → sends WhatsApp confirmation

Technical consideration: PCI-DSS compliance if storing card data. Prefer redirect-based payment (customer enters card on gateway, not on PyroRadius).

Franchise Module¶

The current dealer hierarchy (super_admin → admin → dealer → sub_dealer) covers resellers but not a full franchise model. A franchise module would add:

Franchise fee tracking (PyroNet charges a franchise fee to large dealers)
Separate franchise billing from customer billing
Franchise performance dashboard (revenue share, customer growth)
Multi-admin per franchise (each franchise manages their own admin users)

SLA Monitoring¶

Track service uptime per customer and per NAS:

Record downtime events (NAS offline, OLT offline, customer circuit down)
Calculate SLA compliance percentage per month
Generate SLA reports for corporate/CIR customers who have uptime guarantees
Alert admin when SLA breach threshold is approaching

Long-Term Vision (9+ Months)¶

Multi-City / Multi-Province ISP Management¶

PyroRadius is currently single-city (Lahore). As PyroNet expands:

Multiple cities/regions, each with their own NAS, OLT, and dealers
City-level admin role (can only manage their city's resources)
Cross-city reporting at the super_admin level
Geographic dashboard showing city-level health

White-Label for Other ISPs¶

Package PyroRadius as a product that other ISPs in Pakistan can license:

Tenant-based multi-tenancy (each ISP is a separate tenant)
Customizable branding (logo, company name, WhatsApp sender)
SaaS pricing model (per-customer or per-feature)
Separate database per tenant for data isolation

API-First Architecture¶

The current system is a monolith with Inertia.js (server-rendered React). An API-first architecture would:

Expose a fully documented REST/JSON API for all operations
Allow the mobile app to use the same API as the web app
Enable third-party integrations (accounting software, CRM, etc.)
Separate frontend completely (can use the API from any client)

Real-Time Dashboard with WebSockets¶

Current dashboard data is polled or cached. Real-time updates via WebSockets (Laravel Reverb or Pusher):

Online count updates in real-time without page refresh
NAS status changes push instantly to admin dashboard
New payment notification appears instantly for the relevant dealer
OLT alarm appears on screen immediately

AI-Powered Churn Prediction¶

Use customer behavioral data to predict which customers are likely to churn (stop paying):

Feature signals: payment delays, expiry approaching, support tickets, signal quality
Simple ML model (logistic regression or gradient boosting) trained on historical churn data
Weekly report: "These 15 customers are at high churn risk this month"
Automated WhatsApp outreach to high-risk customers with a special retention offer

Technical Debt to Clear¶

These are cleanup tasks that do not add features but improve maintainability and safety.

Remove .bak Files¶

Leftover backup files from past edits. These should be deleted and the filenames committed to git history:

app/Http/Controllers/CustomerController.php.bak_perf
app/Models/Setting.php.bak
app/Models/User.php.bak

cd /var/www/pyroradius
rm app/Http/Controllers/CustomerController.php.bak_perf
rm app/Models/Setting.php.bak
rm app/Models/User.php.bak
git add -u
git commit -m "chore: remove stale .bak files"

Add Missing Permission Gates¶

CustomerLedgerTab.jsx — the internal permission gate for viewing the customer ledger tab is missing. A dealer without billing permissions can currently view the ledger. Low priority (view-only, no mutation), but should be fixed for consistency.

Billing/Dashboard.jsx — minor permission gaps exist; some billing stats are visible to users who should not see them.

TR-069 pages — when ACS_ENABLED is turned on, these pages need proper role and permission gates added before going live.

Full Test Coverage¶

Zero tests written as of 2026-07-13. See 30_Testing.md for the full testing strategy. Target: 80% coverage on critical paths (BillingService, RadiusService, permission gates).

Staging Environment¶

No staging environment exists. Any database migration or significant code change goes directly to production. See Immediate Priorities above.

Known Bugs Backlog¶

Bug	Status	Priority	Notes
CustomerLedgerTab.jsx missing permission gate	Open	Low	View-only, no mutation risk
TR-069 pages incomplete when ACS enabled	Open	Medium	ACS is off; becomes P1 when ACS is enabled
Billing/Dashboard.jsx minor permission gaps	Open	Low	Stats visible to unauthorized users
`.bak` files in production code directory	Open	Low	Cosmetic; no runtime impact
No automated tests	Open	Critical	Risk: regressions ship undetected
No staging environment	Open	Critical	Risk: migrations tested on production

Recently Fixed Issues (Historical Reference)¶

Date	Issue	Fix Summary
2026-07-13	Expiry date edit bug — SyncOntAssignments lock contention	IS DISTINCT FROM guard + functional indexes + retry loop
2026-07-13	CIR dealer classification — was incorrectly sub_dealer role	Role changed to dealer
2026-07-13	Batch 4 permission gates — Archive/Billing and Notifications pages ungated	Permission gates added for non-admin users