Last year I asked my payroll vendor about an ERP for my business. He quoted ₹30L as a one-time fee. Then ₹3.5L yearly for maintenance. Then ₹25K per month for cloud hosting. I remember sitting with that number and thinking: I don’t even know who is able to afford this.
The honest answer is that a much larger business probably can. Building software for a niche service operation is expensive. A developer has to learn the business before writing a line of code. That learning takes months and costs real money.
The vendor’s price was not irrational. My reference point was. I manage invoicing through Zoho Books, which costs ₹25K a year. Zoho was not built for me. Zoho serves product businesses and simple subscription models.
My customers do not pay a fixed monthly fee. They pay a monthly rate multiplied by the number of days a worker was deployed. They want to see exactly that on the invoice. Not the daily rate that actually drives the calculation.
Zoho Books does not work that way. I spent a month adapting it. Separate pricing lists for 30-day and 31-day months. A restructured invoice format. Workarounds built around features designed for someone else’s business. It works.
The same vendor who quoted ₹30L for the ERP has an invoicing tool priced at ₹5L one-time and ₹30K a year. Built precisely for businesses like mine. I cannot justify that price when Zoho Books does the job for ₹25K after a month of my own effort.
Cheaper tool, operator’s time, imperfect fit. That is the market every small operator lives in. What changed is that I found a way out of it. That gap used to be unbridgeable. It is not anymore. Not because software got cheaper. Because the person who knows the business can now also be the person who builds for it.
So I looked at ERPNext. Thousands of businesses use it. They built it with Indian business needs in mind.
I hired a developer in May 2025 to customise it for my operations. By October, I had spent six months of fees and had no working product. The developer was doing his job correctly. The problem was different. Explaining my business to someone who had never run it cost more than building the thing itself.
I stopped. I studied the ERPNext codebase myself.
What I found was not software. The code cost nothing. The decisions inside it had taken years to make.
The ERPNext developers had worked out how Indian compliance logic fits into a payroll system. How statutory deductions map to employee categories. How attendance feeds into salary calculations.
They had made thousands of small architectural choices, each one encoding something learned from real businesses. I was not looking for features to copy. I was looking for how experienced developers had organised the same raw material: attendance records, compliance obligations, payroll calculations. I wanted to understand those foundational decisions before making mine.
Before opening their codebase, I had spent weeks with my team and with AI building a detailed product requirements document. I knew what O9X needed to do. That process is in the build logs.
What I did not know was how to organise the data underneath it. I read ERPNext’s HR module in a specific sequence: database schema first, then how data moved between tables, then the logic sitting on top. ERPNext’s schema gave me the instinct I needed. The foundation I poured was different. But I understood why it needed to be laid a certain way before I started.
ERPNext did not solve my problem. They built it for manufacturing companies and product businesses. I run a service business with a pricing structure no standard ERP has tried to handle.
In Delhi alone I have more than ten different rates for the same job, depending on the customer contract. An employee can work at any of those sites on any given day, across hundreds of workers.
Traditional payroll software processes a fixed salary against a fixed role. Mine has to process a variable deployment against a variable rate, every single day.
I started building O9X in December 2025. The infrastructure ceiling was hard: ₹4,000 per month. I built entirely on open-source tools:
- Tanstack Start
- Supabase,
- Libraries available free on npm. No proprietary lock-in. No vendor with a ₹25K monthly cloud bill.
Since March 2025, I had been building small tools for my business using Claude Code. A change would take four or five iterations before the errors cleared. The hallucinations were frequent enough to slow everything down.
Then that changed in Dec 2025. Iterations dropped to one or two. The planning got sharper. What shifted was not the model’s knowledge of my industry. It had none. What shifted was its ability to ask the right clarifying questions. And to hold the logic of a session long enough to make decisions that connected.
One of those questions changed how I understood what I was doing.
I was explaining compliance logic to the AI. Some of my customers pay 100% of statutory compliance for their deployed workers. Others pay only the basic requirement.
ERPNext assumes all customers pay in full. That is a reasonable assumption for most businesses. It is wrong for mine.
I had explained this same thing to my developer months earlier. No briefing process surfaces every decision a build requires. You explain the business as clearly as you can. Then the developer starts building, and hundreds of small choices appear that were never in the brief.
He fills those gaps with generic technical judgment. I would have filled them with business judgment. Those are different things and they produce different systems. By the time the difference is visible, it has already become what developers call technical debt.
The knowledge transfer problem is structural. A better hire would not have solved it. He got the compliance logic wrong three or four times. Not because he was careless. Because the correct answer lived only in my head and no question ever pulled it out.
The developer’s failure was not wasted. It taught me which questions mattered. The AI just made it possible to answer them in the right order.
When I explained it to the AI, it asked me to describe a specific contract. Then it asked what happened when a worker moved between a full-compliance client and a basic client mid-month. Then it asked how I handled disputes at month-end.
By the time we finished, the compliance logic came out correct by the second iteration. Not because the AI knew more than the developer. Because the AI made it possible for me to make the decision myself. In the language of the system being built.
That is the gap that collapsed. Not the gap between operators and developers. The gap between knowing your business and being able to build for it. Those used to require two different people. Now, for a V1, they do not.
There is something else worth naming, because most people writing about AI will not say it. The ERPNext developers built something useful for Indian businesses and gave it away.
They encoded years of compliance research, workflow logic, and architectural decisions into a public repository that anyone can read. I inherited their thinking for free. I could not have grounded my build in Indian business logic without their work as the reference layer. That debt is real. No one will ever send me the invoice.
My working assumption is that most AI training data skews toward Western open-source repositories. That would explain why Indian compliance logic required grounding before AI could handle it correctly. When I asked without context, the output assumed 100% statutory compliance across all workers. That is the standard assumption. It is not the Indian service business reality. ERPNext gave me the context to correct it. A human-built Indian system became the grounding layer for an AI that lacked it.
O9X is a V1. It is sufficient for internal operations at current scale. It also encodes my current mental model, including the blind spots I cannot see yet. Every product does.
Only real-world usage will surface them over time. If I need to make it more robust, I will need a developer or better models. That is a risk I am willing to carry. The alternative was a ₹30L quote from someone who would have built for a generic manpower business, not mine.
What changed is that I can now read them, understand them, and build on top of what they figured out.
The only thing stopping me from building anything new is me. Provided I can explain it to a tool that knows nothing about it.