How to Build a Platform Like Keka: Modules, Compliance & Cost (2026)

Ask an HR manager at a 300-person Indian company about their worst week. You will hear about a mid-quarter statutory change, a broken spreadsheet, and 300 wrong salary slips.

Payroll in India is not data entry. It is a compliance exam with a monthly deadline.

Keka built a business on exactly that pain. So did greytHR, Darwinbox, and Zoho People. The SME end of the market is still wide open, where companies export biometric logs and compute salaries in Excel.

If you want to build a platform like Keka, the opportunity is real. The hard part is almost never the interface. This guide covers the modules, architecture, compliance load, cost, and build order that decide whether your product survives its second payroll run.

TL;DR

• Keka’s real moat is not features. It is payroll, attendance, and compliance running off a single employee record.
• To build a platform like Keka, ship core HR, payroll, and attendance first. Performance, surveys, and hiring come later.
• EPF, ESI, TDS, professional tax, and gratuity rules change often, so your payroll engine needs rule versioning from day one.
• EngineerBabu builds multi-tenant HR and payroll products for Indian SaaS founders, from first MVP to multi-city rollout.

Why founders want to build a platform like Keka right now

India’s HRMS market reached USD 1.3 billion in 2025 and is projected to hit USD 4.6 billion by 2034, growing at 14.45% a year, according to IMARC Group. That growth is not coming from enterprises. Most of them already bought something.

It is coming from 50 to 500 employee companies in Pune, Jaipur, Coimbatore, and Indore that have outgrown spreadsheets but cannot absorb enterprise pricing.

Those buyers want three things: salaries that are correct, filings that are on time, and an app employees stop complaining about. Founders who decide to build a platform like Keka usually win on that third point, because incumbents built payroll first and experience much later.

What it actually takes to build a platform like Keka

To build a platform like Keka, you need five working systems: an employee master record, a rules-driven payroll engine, attendance and leave capture, a self-serve mobile app, and a statutory filing layer for EPF, ESI, TDS, and professional tax.

Everything else, including performance reviews, surveys, and analytics, is built on top of that data. Get the first five wrong and no amount of dashboard polish saves the product.

The modules you need before anything else

Resist the module checklist. Four things carry the entire product.

• Core HR and the employee master

One record per employee, versioned over time. Joining date, designation, department, reporting line, location, salary structure, and every change with an effective date.

Payroll reads from it. Attendance writes to it. Reports depend on it. If your employee record cannot answer “what was this person’s CTC in August,” your arrears calculation will be wrong forever.

• The payroll engine

This is the product. Salary structures vary wildly across Indian companies, so hardcoding components is a trap.

Build a rules engine where basic, HRA, special allowance, LTA, and variable pay are configurable formulas, not fixed fields. Add proration, arrears, loss of pay, full and final settlement, and reimbursement workflows.

Then make every rule date-effective, because when the PF ceiling or a tax slab changes, you re-run history without touching code.

• Attendance, leave, and shifts

Indian companies run biometric devices, geo-fenced mobile punch-ins, and manual regularization in the same month. Support all three.

Leave policy configuration matters more than people expect: accrual cycles, carry-forward caps, encashment, sandwich rules, and comp-offs. These rules feed loss of pay, which feeds payroll, which means an attendance bug is a salary bug.

• Hiring and onboarding

Most HR buyers eventually want sourcing inside the same tool. You do not need this in version one, but design the data model so candidate records can convert into employee records cleanly.

Teams that later decide to build an applicant tracking system inside the suite save months when offer letters, documents, and onboarding tasks already share one schema.

Architecture decisions that decide your margins

Multi-tenancy comes first. One codebase serving many companies, with tenant-level isolation on data and configuration. Separate databases per client looks safe and destroys your support economics by client fifty.

Keep payroll as its own service. It is compute-heavy, runs in bursts, and must be auditable line by line. Isolating it means a payroll run cannot slow down the attendance app for everyone else.

Log everything. Who changed a salary, when, and from what value. Indian audits ask, and your enterprise deals will too.

Expose a clean API development layer early, since finance teams will want Tally, Zoho Books, and bank file integrations. Billing is its own build, so plan it the way any SaaS subscription management platform handles per-employee pricing, proration, and upgrades.

How to build a platform like Keka, step by step

Step 1: Pick one segment and one painful month

Do not build for “Indian companies.” Build for 100 to 300 employee IT services firms, or for multi-location retail with shift staff. Their payroll looks nothing alike.

Then pick the single month that hurts most for that segment, usually payroll processing or year-end tax proof collection. Your first release should make that month boring. Founders who try to build a platform like Keka across all segments at once ship a shallow product that loses every demo on specifics.

Step 2: Model the data before you design a screen

Spend three to four weeks on the employee record, salary structure, leave policy, and attendance schema. Write the edge cases down: mid-month joiners, mid-month increments, employees moving between locations, and loss of pay reversals.

Every one of these is a data model question, not a UI question. Teams that skip this step rebuild payroll at month nine, usually after a client’s arrears calculation goes public internally.

Step 3: Build the payroll engine as a rules engine

Implement components as configurable formulas with effective dates. Run the same month through your engine and through a client’s existing payroll, then reconcile to the rupee.

Do this for three companies with different structures before you ship. This reconciliation phase is unglamorous and it is the difference between a product and a liability. A realistic MVP development scope stops here, with core HR, attendance, and payroll working end to end.

Step 4: Ship the employee app early

Employees judge the platform, and they only touch four things: payslips, leave requests, attendance regularization, and tax declarations.

Make those four fast on a mid-range Android phone with weak network. Offline punch capture with later sync matters for field and retail teams. HR renews the contract, but adoption is what HR is measured on, so your app decides renewals more than your admin console does.

Step 5: Add intelligence once you have data

After two or three payroll cycles across clients, you have attrition signals, attendance anomalies, and approval bottlenecks worth surfacing.

This is the right moment for anomaly flags on attendance, predicted attrition, and automated query handling. Most of the useful work in AI in HR tech and recruiting software development depends on clean historical records, which is exactly what steps one through four produce.

Compliance is the part you cannot template

This is where most new entrants underestimate the effort. A credible Indian HR platform handles EPF and ECR file generation, ESI contributions and thresholds, monthly TDS with Form 16 at year end, state-wise professional tax slabs, gratuity, and bonus calculations.

Professional tax alone differs across states, so a Karnataka client and a West Bengal client need different logic in the same run.

Add the Digital Personal Data Protection Act. You are storing Aadhaar-linked identifiers, bank details, and salary data, which demands consent records, retention rules, and deletion workflows. Treating this as compliance automation software development rather than a checklist keeps you from retrofitting it under a client’s security review.

Cost and timeline to build a platform like Keka

Numbers depend on scope, but here is a realistic frame for an India-first product.

In rupee terms, a launch-ready product usually lands between ₹55 lakh and ₹95 lakh before marketing. Two factors move the number most: how many salary structure variations you support, and how many statutory filings you automate instead of exporting.

For a broader view of what drives these numbers, the custom software development cost breakdown is a useful reference, and planning around how long it takes to build custom software keeps the roadmap honest.

Mistakes that sink Indian HR platforms

• Hardcoding salary components. The first client with a different structure forces a rewrite.
• Treating attendance as a minor module. It feeds loss of pay, so errors surface as wrong salaries.
• Skipping effective-dated rules. Retroactive changes then require manual correction across every client.
• Selling to enterprises before support is ready. One escalation during payroll week consumes an entire team.
• Launching without reconciliation. You need rupee-level parity against a real payroll before any client goes live.

Where EngineerBabu fits

Founders who set out to build a platform like Keka usually need two things at once: product engineering that understands multi-tenant SaaS, and people who have handled Indian statutory logic before.

EngineerBabu builds both sides, from the payroll rules engine to the employee app, with CMMI Level 5 delivery and senior engineers staying on the project. Teams that want to extend their own bench can also hire a dedicated development team in India instead of outsourcing the entire build.

FAQs

• How much does it cost to build a platform like Keka?

A functional MVP with core HR, attendance, and payroll typically costs $35,000 to $60,000. A commercially ready product with statutory filings, reporting, and billing usually lands between $90,000 and $150,000 depending on how much compliance you automate.

• How long does an India-focused HRMS take to build?

Expect four to six months for an MVP and nine to fourteen months for a launch-ready product. Payroll reconciliation and statutory filing work consume more time than any interface build.

• Do I need to support biometric devices?

Yes, for most Indian segments. Manufacturing, retail, and healthcare clients still run biometric and RFID readers. Supporting device imports plus mobile geo-punch covers nearly every attendance scenario you will meet.

• Can I start with payroll only and add modules later?

Payroll alone is a crowded, price-sensitive space. A stronger entry point is payroll plus attendance plus a good employee app, because the combination is what SMEs actually struggle to buy affordably.

• What is the hardest part of building an HR platform for India?

Effective-dated statutory logic. Rules change mid-year, apply retroactively, and vary by state. Building for that from the start is the main thing separating products that scale from products that need yearly rewrites.