About ZivoHR
Built for the 200th day,
not the demo.
We are early, and we would rather be specific about what exists than vague about how big we are. This page is the thesis and the engineering, because those are the two things you can actually check.
Why we built it
The demo is optimised. The Tuesday in March is not.
HR software is bought in a room where nobody will use it. So it gets built for that room: a dashboard that looks impressive for forty minutes, a feature list long enough to survive a comparison sheet, and a configuration screen deep enough to answer any objection with "yes, that is configurable".
Then it goes live. The org chart is out of date because updating it is four screens. Attendance does not quite match what payroll thinks. The leave policy in the product is not the leave policy in the handbook. Nobody is lying — the system simply made the correct thing harder than the workaround.
The result is the pattern everyone recognises: a system of record that nobody fully trusts, and a spreadsheet living next to it that holds the numbers people actually use. That spreadsheet is the product failing, and it is what we are trying to remove.
What we believe
Five positions, held on purpose.
These are opinions with consequences in the code, not values on a wall. Each one costs us something, which is how you know it is a position rather than a preference.
How we build
Boring architecture, so the interesting parts stay correct.
Almost every hard bug in an HR system is a rule that was written twice and then diverged. The structure below exists to make that specific mistake difficult.
Business logic lives in services, not in views
A view parses the request, checks authorization and hands off. The rule about how leave accrues lives in one place that a test can call directly, which is why it can be trusted after the fourth person has edited it.
The payroll engine is a pure function over dataclasses
It takes a structure describing an employee's month and returns a structure describing what they are paid. No database, no HTTP, no request context. A statutory edge case is a unit test that runs in milliseconds, so we write a lot of them.
One approvals engine, reused
Request → Approver → Decision → Action → Notification. Leave, expenses and onboarding are all the same chain configured differently, rather than three approval systems that behave subtly differently under pressure.
Security rules are applied while writing, not audited afterwards
The isolation and authorization rules on this codebase came out of an actual penetration exercise against it. They are now a checklist applied to every endpoint as it is written, and every fix ships with a test that was confirmed to fail before the fix.
Where we are
Mumbai, India-first, on three surfaces.
Built in Mumbai
That is where the work happens and where the calls come from. It also means the statutory questions you ask are ones we have had to answer for ourselves.
India-first on statutory payroll
PF, ESI, TDS, professional tax, gratuity and LWF are modelled as rules in the engine, not bolted on as a regional add-on. Depth in one jurisdiction before breadth across many.
Web, Slack and a phone
The same record reached three ways: the full product in a browser, Ziva answering in Slack where the question is actually asked, and a Flutter app for the people who never open a laptop.
We write up the decisions as we make them — payroll edge cases, isolation, the parts that went wrong.
Book a demo · 30 min
Come and check the claims.
Bring your hardest policy and your worst payroll month. We would rather show you where the edges are than describe the middle.