Zero to 32: How I Built a Full ERP in 12 Months with a Team of 6

The Starting Point: A Business Running on Chaos

When I joined Colive as Head of Product, one of India's largest co-living operators, the business was growing fast and the operational infrastructure was not keeping up. Excel sheets for billing, WhatsApp groups for maintenance, manual registers for move-ins, email threads for vendor management. Every team had built their own workaround. Nothing talked to anything else.

The mandate was clear: build the operating system for Colive. Not a feature. Not a module. A full enterprise resource planning platform that could become the single source of truth for every business function.

Buy vs. Build: The Decision That Defined Everything

We evaluated five enterprise solutions. The answer was consistent: co-living sits at the intersection of hospitality, real estate, fintech, and consumer tech — no off-the-shelf ERP understood that combination. Property management systems understood leases but not bed-level occupancy. Billing systems understood invoices but not the bundled pricing logic of co-living. Every vendor demo ended with “we can customise that.” The customisation cost exceeded building our own.

“Every vendor demo ended the same way: ‘We can customise that for you.’ After the fifth vendor, I calculated that the total customisation cost would exceed building our own system — and we would still end up with something that did not fit our business model.”

We made the call to build. It was not the easy decision. It was the right one.

Designing for a Business, Not a Feature List

We started with business workflows, not a feature list — mapping every process from lead enquiry to move-out deposit refund. After interviewing 40+ team members across six functions, a clear picture emerged of where the business was bleeding time, money, and trust. We grouped the ERP into six pillars:

The 32 modules we built

How We Shipped 32 Modules in 12 Months

The team was 6 engineers, 1 designer, and me. No dedicated QA or DevOps at the start. Five principles made it possible:

1. 01
   Ruthless sequencing by dependency, not by priority. We mapped the entire module dependency graph before writing a line of code. Billing depended on Contracts. Contracts depended on Move-in. Move-in depended on Room Config. We built from the foundation up, so each module could stand on a stable base. Teams that demanded their module first had to wait if the plumbing was not ready.
2. 02
   One shared data model from day one. The most common mistake in platform builds is letting teams design their own schemas. We spent the first four weeks exclusively on the data model — a single, canonical representation of a property, a bed, a resident, a contract, a payment, and a ticket. Every module was built on this shared foundation. This is what made cross-module reporting possible from launch.
3. 03
   Shadow mode before hard cutover. For the most critical modules — billing and collections — we ran the new ERP in parallel with the existing spreadsheet process for six weeks. Discrepancies were flagged and resolved. Finance teams built confidence. When we cut over, there were no surprises.
4. 04
   Embedded PMs in operations, not in meetings. I had one junior PM who spent 3 days a week sitting with operations teams, watching how they used each module in real time. The feedback loop was immediate. If a workflow was wrong, we knew within days, not months. This single practice saved us from at least four major rework cycles.
5. 05
   Progressive rollout by property cluster. We did not flip the switch company-wide. We piloted with 3 properties, then 10, then 30, then the full portfolio. Each cluster surfaced edge cases — property-specific billing rules, regional maintenance workflows, city-specific compliance requirements — that we handled before the next rollout wave.

The Hard Part: Adoption

Adoption required deliberate design, not just correct features. Three mechanisms made the difference:

1. 01
   Compliance visibility for managers. Every manager could see, in real time, which of their team members had completed workflows in the ERP vs. done them off-system. This created natural accountability without requiring enforcement from above.
2. 02
   Pain-first onboarding. We introduced each team to the ERP by showing them the single most painful thing it solved for them personally. Maintenance staff saw that tickets could no longer be lost or forgotten. Finance saw that billing errors would drop to near zero. We sold the system on personal pain points, not company-level benefits.
3. 03
   Zero-tolerance data entry policy with audit trails. We made it policy that any transaction not in the ERP did not happen. If maintenance was done but not logged, the vendor did not get paid. Harsh, but it worked. Within 8 weeks, ERP usage went from 40% to 94% across the portfolio.

What It Did to the Business

By month 18, the numbers were unambiguous:

The 550% revenue growth was not caused solely by the ERP — portfolio expansion was happening too. But without a scalable operational backbone, the business could not have absorbed that growth without breaking. The ERP was the multiplier.

What I Would Do Differently

The Outcomes

The Bigger Lesson

This is a story about sequencing, data model integrity, and building for the business — not for the engineers. We started with the question: what does this business need to be operationally excellent? Everything else followed. Internal products are not less important than consumer products. They are the infrastructure on which consumer experiences are built. Get the foundation right, and everything above it becomes possible.