Investor + candidate briefing — May 2026 · v0.1

One platform
where 1
used to be.

Nodii is building software for distributed service businesses, starting with ISPs. Initial product built across Customer/Service, Finance, HR, My Tools, and Provisioning. First anchor ISP onboarding begins this week; commercial validation starts now.

Briefed by Abhi Sathya · founder
Document nodii / investor + candidate deck / v0.1 — 2026‑05‑04
\n Nodii 01 — Context
The problem

These businesses coordinate
too much work by hand.

Internet providers. Cable operators. Regional logistics. Equipment-as-a-service. Multi-brand distribution. Customers, partner networks, field teams, billing, provisioning, support, and infrastructure all affect each other. Most operators manage that with several disconnected tools and a lot of manual follow-up.

Nodii — Investor + Candidate Briefing02 / 15
\n Nodii 01 — Context
The useful observation

The same customer is represented
differently in every tool.

One customer action

CRM Customers
Billing tool Receivables
Provisioning script Service
Spreadsheets Distributor margins
Help-desk SaaS Tickets
HRMS People
→

What we are trying to build

\n
Shared state.
Regional operators do not need CRM, billing, HRMS, or provisioning as separate islands. They need one reliable source of state because a single customer change touches finance, network access, field responsibility, distributors, support, and audit history.
Nodii — Investor + Candidate Briefing03 / 15
Current state

Initial product built.
First real deployment starting.

05
Modules built
Customer/Service, Finance, HR, My Tools, and Provisioning.
01
Anchor ISP onboarding
First deployment cycle begins the week of May 4, 2026.
Pre
Revenue stage
Commercial validation starts with this deployment.
180
Days to learn
Prove one operational loop and repeatable onboarding.
Bengaluru — in-person hybrid · investor + candidate briefing
\n Nodii 02 — Product
First workflow to prove

Customer onboarding
to service activation.

01Customer created
02Area / distributor assigned
03Plan selected
04Service activated
05RADIUS / provisioning updated
06Billing and collection cycle begins
07Support and field actions use the same state

The first proof is one complete activation loop. A new customer, their service plan, network access, billing state, distributor ownership, and support context need to stay in sync without manual reconciliation.

Nodii — Investor + Candidate Briefing05 / 15
\n Nodii 02 — Product
Why the product touches several departments

The workflow crosses departments.

What operators see
Separate teams
Customer desk, billing desk, field team, distributor network, HR, and support each need a usable surface.
What Nodii is building
One shared state model
We are not trying to sell five separate products at once. The modules are views into the same operating data.
Why it matters
The handoffs break
Activation, suspension, collections, margin reconciliation, and support become painful when customer, service, and finance state are updated separately.
Nodii — Investor + Candidate Briefing06 / 15
\n Nodii 02 — Product
What is built now

Initial platform built.
Anchor onboarding begins now.

Built
Customer
& Service
Customer lifecycle, onboarding, service definitions, promotions, credits, support tickets, and distributor relationships.
Built
Finance
Receivables, payables, payment collection, and reconciliation. Syncs with Zoho Books today. Native GST computation is not claimed yet.
Built
Provisioning
ISP-specific module. Drives FreeRADIUS sync from service definitions to provision tenant plans and distribution channels. Most actively developed module.
Built
Human
Resources
Announcements and policies for the tenant. Syncs with GreytHR today for employee sync and onboarding. Native HR depth remains a later product area.
Built
My Tools
Employee switchboard. Tasks with metrics, plus self-service for attendance and leave.
Future
Inventory
Backend work exists, but tenant-facing release depends on tighter ecosystem integration and learning from the anchor workflow.
Future
Shipping
Adjacent surface for operators with equipment and fulfillment workflows. Not part of the first proof claim.
Cross-cuts
Distributor
& partner
Not a standalone module. Relationships live in Customer & Service; margin reconciliation lives in Finance.
Nodii — Investor + Candidate Briefing07 / 15
Why ISPs first

ISPs put the whole
problem in one place.

ISPs concentrate customer management, field operations, billing, provisioning, collections, and partner networks into one painful workflow. They are a useful first market because customer state and service state have to match for the business to work.

Section II — Where we're starting
\n Nodii 03 — Wedge
Why ISPs first

The ISP workflow gives us
specific things to test.

Activation touches the network
A customer record is not complete until service state drives FreeRADIUS and NAS behavior reliably.
Collections can change access
Payment status, suspension, reactivation, and plan changes have to move through the same operating data.
Distributor ownership matters
Margins, field responsibility, support context, and collections all depend on who owns the customer relationship.
Regulated onboarding is real
KYC, identity isolation, permissions, and audit trails are required from the start, not later enterprise polish.
Repeatability has to survive real infrastructure
Mikrotik, Cisco, Huawei, Juniper, Cambium, TPLink, Motorola, regional policies, and different distributor models test whether this is a product or a one-off deployment.
Nodii — Investor + Candidate Briefing09 / 15
\n Nodii 04 — Proof plan
What we are proving in the next 180 days

Commercial validation has not started yet.
These are the tests.

Hypothesis
Proof target
ISPs need one shared system, not separate CRM, billing, and provisioning tools.
Anchor operator uses Nodii for onboarding, service activation, billing, and collection workflows.
Provisioning can be the first valuable workflow.
Service state in Nodii reliably drives FreeRADIUS and NAS workflows.
Operators expand from one loop into adjacent modules.
Anchor starts with core workflows and adopts Finance, HR, Support, or Inventory surfaces where they create immediate value.
The product can generalize beyond one custom deployment.
Second ISP or adjacent distributed operator can onboard without heavy rebuild.
The architecture can support repeatable SaaS deployments.
Tenant isolation, identity, permissions, templates, and audit trails work across modules.
Nodii — Investor + Candidate Briefing10 / 15
\n Nodii 04 — Proof plan
Seed-readiness milestones

Before a seed round,
we need these outcomes.

01Anchor ISP live on core customer and service workflows.
02At least one provisioning loop running reliably.
03Billing and collection workflow validated against real operations.
04Repeatable onboarding playbook created from the anchor deployment.
05Second operator, adjacent customer, or signed LOI validates repeatability.
06Pricing model tested against real buyer expectations.
Nodii — Investor + Candidate Briefing11 / 15
\n Nodii 04 — Proof plan
What could make this hard to copy

The hard part is encoding
how the operator actually works.

Customer identity
Service state
Finance state
Field responsibility
Partner hierarchy
Provisioning systems
Permissions and audit trails

Nodii becomes useful only if these states can change together without turning each deployment into a custom project.

Later
Once the operating data is connected, automation becomes more practical. That is not the current proof. The current proof is whether the business can run from one shared state model.
Nodii — Investor + Candidate Briefing12 / 15
\n Nodii 05 — Team
What joining now means

The product is real.
The system is still being shaped.

We are early. If you want a clean spec and a narrow ticket queue, this is not the right place. If you want to build the operating software for real businesses while the architecture is still being shaped, it might be.
Buildcustomer identity, service activation, provisioning, billing state, permissions, and auditability.
Ownarchitecture while the important decisions are still open.
Learnclose to customer problems instead of abstract dashboard work.
Workin Bengaluru, in-person hybrid, with visible impact on real operators.
Nodii — Investor + Candidate Briefing13 / 15
\n Nodii 05 — Posture
Risks / disconfirming signals

The main ways
this could fail.

R/01
Repeatability may not appear
If the anchor becomes a custom services project, the product idea is weaker.
R/02
Provisioning reliability is required
If service state cannot reliably drive access control, the first workflow does not hold.
R/03
Breadth can hide lack of focus
The product is broad because the workflow is broad, but the next proof has to stay narrow and measurable.
R/04
Second-customer validation matters
One anchor proves the problem is real enough to start. A second operator tests whether the playbook travels.
R/05
Hiring density is part of the bet
This needs engineers who can handle infrastructure, product judgment, and customer ambiguity.
R/06
Funding posture
We are starting validation, not asking to be evaluated like a revenue-stage company.
Nodii — Investor + Candidate Briefing14 / 15
The ask

We are starting
the first real deployment.

Investors
We are not running a formal fundraise today. We want investors who understand this category to follow the anchor onboarding and repeatability test.
Candidates
Join early if you want ownership over product and infrastructure that real operators will use every day.
Email abhisathya4@gmail.com
Question we are testing Can one shared system replace the fragmented stack?
First call 30 minutes — investor or candidate track.
In one word Early.