Industries · Telecommunications
Telecom buyers judge you on the account portal, the coverage checker and the outage page long before they meet a technician. We build the software that carries that weight, from self serve billing to field apps, and we ship a working demo every week.
You own the code and IP Weekly demos Reply within one business day
$oldevs deploy --env production
✓Build passed · 212 tests · 0 warnings
✓Migrations applied · postgres 16
✓API v2 healthy · 142ms p95
→Rolling out to 3 regions…
OlDevs is a full-stack technology studio in Vancouver, British Columbia that builds software for regional carriers, internet service providers and managed service providers.We work on the systems subscribers actually touch: self serve account and billing portals, coverage and availability checkers, provisioning and support workflows, network status and outage communication, and field technician apps. Every project runs with one accountable team, produces a working demo each week, and is built to WCAG 2.2 AA accessibility, with clients owning all code, designs, accounts and IP. To start a telecom build, request a quote.
Key facts
Telecommunications
The problems we are asked to solve most often — and how.
Bundles, prorated changes, promotional periods, equipment instalments and taxes all land on one invoice. When the portal cannot explain a charge in plain language, the call centre absorbs the cost and the trust goes with it.
Serviceability depends on the specific address, the technology at that node and what capacity is left. A checker that guesses generates failed installs, refunds and complaints, so the lookup has to be honest about what it does not know.
Orders touch CRM, inventory, OSS and BSS platforms of different ages, some with modern APIs and some with nightly files. Every manual handoff between them is a place where an activation stalls and nobody owns the ticket.
The one page everybody loads is the one hosted on the network that just failed. Status and outage communication need separate hosting, cached delivery, plain language updates and a path for staff to publish in minutes, not hours.
Technicians work in basements, riser rooms and rural routes with no bars. Job details, test results, photos and signatures have to be captured offline and reconciled cleanly when the device finds a connection again.
Half your advertising reaches addresses you cannot serve, and the other half competes with incumbents on the same street. Campaigns, landing pages and the availability check have to work as one funnel or the spend leaks.
Process
Discovery
We sit with support, provisioning and field leads, read the tickets and walk the current portal. The output is a written picture of where subscribers get stuck and where staff are doing work software should do.
Architecture and plan
We agree the integration approach for billing, CRM and OSS, decide what runs independently of the network, and sequence the build so the highest value screens land first. You get the plan before anyone writes code.
Weekly build
Development runs in visible increments with a working demo every week. Accessibility, bilingual content and performance are checked as we go rather than saved for a pass at the end.
Launch
We rehearse the cutover, run the new portal alongside the old one where that reduces risk, load test the status path, and put monitoring and alerting in place before traffic moves.
Measure and improve
After launch we watch call deflection, failed installs, completed self serve actions and drop off points, then work through a prioritised list of fixes and additions with you.
How we work
We trace what a subscriber does, from checking availability to disputing a charge, and mark which system holds the answer at each step. That map shows where the friction is and which integration actually pays for itself.
Anyone can lay out a simple monthly bill. We start with the mid cycle plan change, the partial month, the equipment instalment and the failed payment, because those are the screens that create calls.
Billing and OSS platforms are rarely worth ripping out. We build an integration layer that reads and writes to your systems of record and keeps the customer facing experience modern without a risky migration.
Status pages, outage notices and their notification paths are built to run on infrastructure separate from the network they report on, with cached delivery and a publishing flow staff can use under pressure.
Technician apps store the job locally, capture photos, tests and signatures without a connection, and sync with clear conflict handling. Dispatch sees progress as soon as the device reaches coverage.
One accountable team, a working demo every week, WCAG 2.2 AA accessibility and bilingual EN and FR interfaces where you need them. You own all code, designs, accounts and IP from day one.
Recommended
Since 2014
Building software for infrastructure heavy sectors
Every week
A working demo during the build
WCAG 2.2 AA
Accessibility standard for portals and status pages
FAQ
Yes. The studio is in Vancouver and we serve carriers, ISPs and managed service providers across Canada remotely, with video calls in your time zone and on site visits when the work calls for it, such as field app testing with technicians or a launch weekend. Distance has not been the constraint on the work.
Usually yes. We start by cataloguing what each system owns, what it exposes and how fresh the data is, then build against APIs where they exist and controlled batch or middleware paths where they do not. The goal is a portal that reads and writes to your systems of record rather than a second source of truth that drifts.
We design to the requirements your counsel sets. In practice that means subscriber data handled with Canadian privacy law such as PIPEDA in mind, card details kept out of scope wherever a compliant payment provider can hold them, and clear audit trails throughout. We build to those rules, we do not give legal advice, and requirements should be confirmed as current at the time of writing.
Both are possible and the choice usually follows the fleet. If technicians already carry one platform, we build native for it. If the fleet is mixed, we look at a shared codebase with native modules for the parts that matter most, such as offline storage, camera, barcode capture and background sync.
Yes. It is a common first project because it is contained and visible. We build the status page on hosting separate from your network, wire it to the alerting you already use, give staff a simple way to publish updates, and connect email or SMS notices so subscribers hear from you before they post about it.
You see a working demo every week from the first week of the build. Early demos are narrow on purpose, for example an address lookup returning real serviceability answers, and the scope widens from there. One accountable team runs the project, so feedback given in a demo turns into a change without passing through account layers.
You do. Clients own all code, designs, accounts and IP from the start, including repositories, hosting, analytics and advertising accounts. We document the build, hand over every credential, and can train your team or stay on for support, but nothing is held back to keep you on a contract.
Let’s connect
We’ll reply within one business day with next steps and a tailored quote — no obligation.