ips-software: A Next.js ISP Management Stack Built Around M-Pesa and MikroTik

What This Project Actually Solves

ips-software addresses a narrow but real pain point: small internet service providers in Kenya that need to manage prepaid Wi-Fi customers without building custom software. The README describes a system that automates billing, sends SMS reminders before disconnection, and integrates M-Pesa for payments. It also handles hotspot user accounts and PPPoE connections through MikroTik routers. The target user is an ISP operator who currently juggles spreadsheets, manual router configuration, and cash payments. The project aims to replace that with a web interface that both admins and end-users can access. The focus on M-Pesa is a strong signal that the developer had a specific market in mind, not a generic billing tool.

Architecture and Data Flow as Shown in the README

The stack is entirely TypeScript and React based: Next.js 14 with the App Router, Tailwind CSS for styling, and Shadcn UI for components. The database is Neon DB, a serverless Postgres provider, which fits the Vercel deployment model mentioned in the tech stack. The data flow is not fully documented, but the feature list implies a sequence: a customer pays via M-Pesa, the system confirms the payment, updates the user's account in the database, and then communicates with MikroTik to adjust the PPPoE or hotspot session. SMS reminders are sent at three intervals: two days before disconnection, one day before, and on the day itself. That is a concrete automation cycle. The project structure shows src/app for routes, src/components for UI, and src/lib for shared logic, which is a standard Next.js layout. However, the README gives no details on how the MikroTik API is called or how M-Pesa webhooks are handled, so the actual mechanism remains opaque until you inspect the code.

Getting It Running: Commands and Gaps

The installation steps are minimal: clone the repository, install dependencies with npm, yarn, or pnpm, and run the development server. The README says to set up environment variables but does not list a single variable name. That is a significant gap. For a project that depends on M-Pesa credentials, a Neon DB connection string, and MikroTik router IPs, missing env documentation is a blocker for anyone who is not the original developer. The command to start is npm run dev, which opens localhost:3000. The prerequisites are Node.js 18.17 or later and a package manager. There is no mention of a production build step, database migrations, or seeding scripts. If you try to deploy this to Vercel, you will need to guess the required environment variables from the source code. That is a real friction point.

The M-Pesa Integration Is Both a Feature and a Constraint

M-Pesa is a mobile money service dominant in Kenya, and the README mentions it as the payment integration. The cost of SMS is quoted at Ksh 0.4 per message, which is a specific detail that suggests the developer has negotiated rates with a gateway. This integration is the project's main differentiator. But it also locks the software into a single payment provider. If you operate outside Kenya, or if you need to accept credit cards or bank transfers, you will have to modify the code. The README does not mention any abstraction layer for payment providers, so the M-Pesa logic is likely hardcoded into the billing flow. That is a maintenance risk. The project's value proposition is tied to the Kenyan market, and that is fine, but it is a limitation you must accept from the start.

Phase 1 vs Phase 2: What Is Actually Implemented

The README splits features into Phase 1 and Phase 2. Phase 1 includes payment automation, hotspot management, PPPoE management, SMS gateway integration, and an analytics dashboard. Phase 2 adds two-factor authentication, a package management system, a self-service portal, lead tracking, and real-time router status notifications. The README does not state which phase is complete. The repository has no release notes and no recent release information retrieved, so you cannot tell from the material whether Phase 2 features are stubs or fully built. That ambiguity is a red flag for adoption. You would need to browse the source tree to see if routes like /login/2fa or /packages exist. The marketing-style description may overstate the current state of the code.

Limitations and Failure Modes

The most obvious limitation is the missing license. The README has an empty License section, which means you have no legal clarity on how you can use, modify, or distribute the software. That alone should stop most enterprises from adopting it. Another failure mode is the lack of documentation for environment variables and API endpoints. If the M-Pesa callback fails or the MikroTik connection drops, there is no documented troubleshooting path. The project also depends on Neon DB, which is a hosted service; if you want to self-host, you will need to change the database adapter. The README does not mention any offline capability or queueing for SMS or payments, so a network outage could disrupt billing reminders. Finally, the project is not archived, but the last push is unknown, so you cannot assess its maintenance activity from the supplied material.

Alternatives and How They Differ

A common alternative to this project is a full-featured ISP billing platform like Splynx or Powercode, which are commercial products with built-in router integrations, payment gateways, and customer portals. The key difference is that those are closed-source and require licensing fees, whereas ips-software is open source (assuming you resolve the license issue). Another alternative is building a custom solution on top of MikroTik's API and a payment gateway like Daraja (M-Pesa's API), but that requires significant development time. There is also the open-source project Mikrotik-API, which provides a low-level library for router management, but it does not include billing or SMS. The difference in approach: ips-software tries to bundle everything into a single Next.js app, while alternatives like Splynx are modular and let you choose components. For a small ISP, the bundled approach might be simpler, but it is less flexible.

Maintenance, Upgrade Cost, and License Implications

The README gives no information about versioning, changelogs, or upgrade paths. The project uses Next.js 14, which is a specific version; upgrading to Next.js 15 would require testing all App Router pages and any server actions. The dependency on Neon DB is a hosted service, so your data is stored off-site, and you must trust that provider's uptime. The license is unknown, which is a serious legal concern. Without a license, you do not have permission to use the code beyond what the copyright law allows, even though it is publicly visible. The README lists a support email, which is a positive sign, but it is a single point of contact. The project structure is standard, so a developer familiar with Next.js could navigate it, but the lack of documentation for the M-Pesa and MikroTik integrations means that any modification will require reading the source code carefully. In short, the maintenance cost is high for the first adopter, but the codebase size is likely small enough to manage.

Editorial conclusion

Adopt ips-software if you are a small ISP serving Kenyan customers and you already rely on M-Pesa for payments and MikroTik routers for connectivity. The project is not ready for production without significant work: the README lacks a license, environment variable documentation, and any deployment specifics, so you must verify those before committing. Avoid it if you need multi-currency support, alternative payment gateways, or a mature community. Start by cloning the repository and checking the src/lib directory for configuration files and the actual API routes, then test the M-Pesa integration in a sandbox environment.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases