Skip to content

Software development

Software written by the people who then have to operate it

Internal tooling, billing and provisioning, customer portals and integrations — for the places where an off-the-shelf product either does not exist or cannot follow your process.

The problem

Either you buy a product that does not fit your process, or you keep fighting a spreadsheet

Part of an operator's daily work does not fit a packaged product: the chain that connects a subscriber, the state of cache servers, one customer's circuit history. What appears instead is spreadsheets, scripts run by hand, and knowledge that lives in one person's head. We turn those gaps into software — and because we operate the same kind of infrastructure ourselves, we know what it has to do.

  • The process lives in a spreadsheet, not a system
  • Scripts are run by hand and undocumented
  • The systems do not talk to each other
  • The customer cannot see their own data

What we deliver

Software written by the people who then have to operate it

Operational tooling

The NOC's daily tasks in an interface: state, incidents, diagnostics.

Billing and provisioning

Subscribers, tariffs, balances and service activation — integrated with the network.

Customer portals

Self-service: usage, invoices, requests and the customer's own graphs.

Integrations

APIs between billing, monitoring, IPAM and ticketing — instead of copying by hand.

Dashboards on real data

One view assembled from several systems that answers an actual question.

Handover and support

The code, the documentation and the deployment procedure stay on your side.

Architecture

Architecture

  1. 01Map the processHow it is done today, and where the time goes
  2. 02Working versionA small usable slice, not a full specification
    • TypeScript
    • Next.js
    • PHP
  3. 03IntegrateWith the existing systems, on real data
    • REST API
    • webhooks
    • PostgreSQL
  4. 04ShipDeploy, logging and monitoring from day one
    • Docker
    • nginx
    • CI/CD
  5. 05OperateFixes and improvements against real use
    • Logging
    • Metrics
  6. 06HandoverCode, documentation and deployment on your side
From a spreadsheet to a system — starting with a small working version

Operator consoles

Operator consoles

These exact systems run on the group's own infrastructure — the screenshots are processed before publication.

Blurred OpenPath NOC console showing service status, latency sparklines and an incident feed.

OpenPath — our own NOC console

Live path monitoring on a 15-second refresh: latency and packet loss to each service, including cache servers hosted inside individual operators. A path change is recorded as its own incident, with filters by ASN, ISP and customer. We wrote this tool ourselves because no off-the-shelf product answered the question.

in-houselatency / losspath changeper-ASN
Blurred ros-backup dashboard showing device coverage, backup success rate and a fleet table broken down by company.

ros-backup — the configuration archive, collected on its own

A device's configuration is the one file whose loss is measured in hours of downtime. ros-backup collects it every day over SSH — MikroTik RouterOS, Juniper JunOS, Cisco IOS and Arista EOS — and keeps it in a git repository, versioned, with a line-by-line diff between any two. No engineer signs in to each device to copy a config by hand: any router's configuration from any day is two clicks away — including when the device itself will no longer power on. We wrote this one ourselves too.

in-houseRouterOS / JunOS / IOS / EOSgit-versioneddaily over SSH
The Semaphore Schedule page: four enabled jobs with their names, cron expressions and the playbook each one runs.

Ansible on a schedule — the Semaphore scheduler

Ansible playbooks here are not scripts someone ran once — they are jobs on a schedule: latency checks against cloud VPS instances, a DNS server check, a reporter run from TVG, a weekly VPS job. Each has its own cron expression and its own playbook, and each produces the same result every time, because a playbook describes the state it wants rather than the steps to get there.

AnsibleSemaphorecronplaybooks
Heavily blurred billing system screen with a subscriber list — no personal data is legible.

ISP billing and subscriber management

The whole subscriber lifecycle in one system: tariffs, balances, services (internet, Wi-Fi, IPTV), statuses, SMS notifications, logs and financial reports — wired into provisioning. We built it, and it runs a real ISP.

in-housebillingprovisioningIPTV

Capabilities

Capabilities

Every item is marked: verified production experience, or engineering capability.

Our own NOC console (OpenPath)

Proven

Live path monitoring, an incident feed and per-ASN filters — written because no off-the-shelf product answered the question. In daily production use.

  • in-house
  • probes
  • per-ASN

An ISP billing system

Proven

Subscriber lifecycle, tariffs, balances, SMS and reporting — serving a live operator.

  • billing
  • provisioning
  • SMS

Web platforms and portals

Proven

TypeScript/Next.js and PHP — server rendering, bilingual content, a CMS and access control.

  • Next.js
  • TypeScript
  • PHP
  • PostgreSQL

API integrations

Proven

Moving data between systems: monitoring, IPAM, billing, ticketing, payments.

  • REST
  • webhooks
  • cron

Automation and scripting

Proven

Repeating operations turned into a script, then into a service — with nobody running it by hand.

  • Python
  • Bash
  • Ansible

Mobile and desktop clients

Capability

Where a web interface is not enough.

Process

Process

  1. 01

    Map the process

    How it is done today and where the time goes.

  2. 02

    Working version

    A small usable slice, not a full specification.

  3. 03

    Integrate

    Connect it to the existing systems and test it on real data.

  4. 04

    Ship

    Deploy, logging and monitoring from day one.

  5. 05

    Operate

    Fixes, improvements and handover to your team.

Technology stack

Technology stack

Frontend
TypeScriptNext.jsReactTailwind
Backend
Node.jsPHPPythonREST API
Data
PostgreSQLMySQLRedisClickHouse
Infrastructure
DockernginxCI/CDAnsible

Engagement model

Engagement model

Project

A one-off scope: audit, migration or implementation with a fixed outcome.

Retainer

Monthly engineering hours — specialist access on demand.

Co-managed

NetWizard and your in-house team together, with split responsibility.

Use cases

Use cases

The product does not fit

The process is specific, and the system has to follow it — not the other way round.

Two systems do not talk

Data is carried across by hand. An integration removes that work entirely.

The customer needs visibility

A self-service portal cuts calls and disputes — both sides look at the same number.

FAQ

FAQ

Do we own the code?

Yes. The code, the documentation and the deployment procedure go to your side — lock-in is not part of the model.

How is this different from a normal dev shop?

We operate networks, billing and monitoring ourselves. There is no requirements-translation step — we already understand the problem.

Tell us about your infrastructure