Comparison

Capstan and Zimyo

Zimyo is a serious product, and this page is not a scorecard. It sets out how each of the two is built, taking each side from how it is publicly positioned, and then gives you the questions worth putting to any vendor in this market, us included. Where Zimyo is the better buy, it says so, and it says where Capstan is the wrong choice outright.

What each one is built to be

Start here rather than with a feature list. Most of the difference between two HR products is decided before either one ships a feature, by what business the company is in.

Zimyo, as publicly positioned, October 2026

Zimyo presents itself as a full-suite HR and payroll platform built for Indian businesses, aimed at small and mid-sized organisations, covering payroll, attendance, leave, performance, recruitment and employee engagement in one system. The centre of the published offer is payroll with Indian statutory content inside the product, provident fund, employee state insurance, professional tax, tax deducted at source and gratuity, with the rest of the HR lifecycle built around that core.

Capstan, published on this site

Capstan is an HR system of record for companies that employ their own people. It holds the roster, the employment, leave, attendance, documents and the workflows around them, with the module suite included on every plan for the rest. It is not an employer of record, it computes no payroll, and it runs as a self-contained stack in one EU region live today, data in Frankfurt and compute in Amsterdam.

Set out in full on the product page, with the residency model on security and every figure on pricing.

Three structural differences

One axis at a time, two published models, each stated as what it is. Nothing here says what Zimyo does not do: their model is theirs to describe, and if it moves, the line about ours still holds.

  1. Who computes payroll, and who produces what follows it

    Zimyo, as publicly positioned, October 2026

    Payroll computation with Indian statutory content is the published core. Deductions are computed in the product, the statutory outputs that follow a pay run are generated there, and the content behind them is maintained by the vendor as the rules change.

    Capstan, published on this site

    Capstan is the system of inputs and the system of record; the computation belongs to your payroll partner. It compiles attendance, leave, overtime, compensation changes and adjustments into a documented export, files the computed results back onto the employee record, and holds no statutory rate, slab or formula anywhere.

  2. What the plan you start on contains

    Zimyo, as publicly positioned, October 2026

    The suite is published as a ladder of plans, with capability taken up as the organisation needs it and further modules arriving as you move up it, priced per employee.

    Capstan, published on this site

    The complete product is on every plan, including the free one, which is capped at twenty active employees, all fourteen modules included at no extra charge. One thing changes when you pay: the cap lifts. Nothing else moves between plans, and every figure is on one public page.

  3. How the product travels between countries

    Zimyo, as publicly positioned, October 2026

    The product is published for the Indian market, carrying that market's statutory content as a first-class part of the payroll core.

    Capstan, published on this site

    Capstan carries no statutory computation in any country, which is what lets it be the same product wherever it runs. Your data sits in one isolated EU region, data in Frankfurt and compute in Amsterdam, a self-contained stack with no global control plane and no cross-region keys. The EU is the region live today, and the footer list on every page is the whole of it.

The six questions to ask any vendor, including us

Our answers are here in public with nothing rounded off. The slot beside each one is left open on purpose: Zimyo’s answers are theirs to give, and a comparison page that fills them in has stopped being a comparison. Ask them the same six, and set what you are told beside ours.

  1. Who employs our people, and who carries the liability?

    It decides who is on the contract of employment, who answers a labour authority, and what you are actually buying: a service that takes the employment on, or a system that records it.

    Capstan’s answer, in public

    You do. Capstan is not an employer of record, never becomes the legal employer of anyone on your roster, and moves no payroll money. If you need a legal employer in a country where you have no entity, that is a different kind of vendor.

    Zimyo’s answer

    Ask them, and get it in writing.

  2. Who computes payroll, and whose name is on the filing?

    Computation and filing are where liability sits. A vendor that calculates and files is taking that on. A vendor that prepares inputs is not, and you need the second half of the arrangement in place before you rely on either.

    Capstan’s answer, in public

    Not Capstan, by design. It compiles joiners and leavers, pay structures, leave, attendance and adjustments into a documented export for your payroll partner, and files the computed results back onto the employee record. It holds no statutory rate, slab or formula, and files nothing with any authority.

    Zimyo’s answer

    Ask them, and get it in writing.

  3. Where does our data live, and who inside the vendor can reach it?

    Residency is a property of where the database is, not of a promise in a policy. Support access is the same question from the other end: not whether staff would look, but whether the system lets them without you switching it on.

    Capstan’s answer, in public

    One isolated region, the EU today: data in Frankfurt, compute in Amsterdam. It is a self-contained stack with no global control plane and no cross-region keys, so there is no runtime path out of the region. Staff hold no tenant of their own, and access exists only while you have granted a time-boxed consent, masked by default and audited on both sides.

    Zimyo’s answer

    Ask them, and get it in writing.

  4. What do we get on the plan we start on, and what changes as we grow?

    This is what growing costs you. If capability moves between tiers, the upgrade you eventually buy is largely software you were already being shown.

    Capstan’s answer, in public

    The complete core is on every plan, including the free one, which is capped at twenty active employees. Paying lifts the cap and includes all fourteen modules at no extra charge, billed month to month with no annual contract and no lock-in. Every figure is on one public page, so you can total your own number without a call.

    Zimyo’s answer

    Ask them, and get it in writing.

  5. What happens to our data the day we leave, or the day a payment fails?

    Export is the price of leaving. Either it is written down before you join, or it gets decided at the moment you have the least leverage you will ever have.

    Capstan’s answer, in public

    An owner can take a full export at any time: one archive of JSON and CSV, in open formats, with a documented manifest. Export deliberately sits outside the suspension check, so a workspace held for non-payment can still be exported. The export is not a dead archive either: it imports straight back into a fresh Capstan workspace, the people master proven to round-trip, which is the plainest proof there is no lock-in. Deletion is cryptographic erasure followed by hard deletion, with a residue scan.

    Zimyo’s answer

    Ask them, and get it in writing.

  6. Does any software judge our people, and can the person see why?

    Whether software scores, ranks or screens people decides who is accountable for the judgement, and whether the person it was made about can be shown the reason.

    Capstan’s answer, in public

    No AI scores, ranks or screens your people, and that is architectural rather than a promise: the agent capability registry is pinned in the database so it cannot hold a capability that evaluates a person, nothing of the kind is built, and the analytics engine can only ever narrow who sees what, with small groups suppressed. The useful AI is off until a workspace turns it on and is bounded by construction: an assistant answers from what the caller may already see, and an agent needs a named accountable human and an explicit human confirmation before it changes any record, can move no money, and can evaluate nobody. The one aggregate assistant that reaches out sends only non-personal figures, such as headcount by department, to our single AI sub-processor, OpenAI, which does not train on the data. No per-person or sensitive record is ever sent to an outside model or used to train one.

    Zimyo’s answer

    Ask them, and get it in writing.

If an answer of ours turns out to be wrong, it is a bug and we will fix the page. The same standard applies to anything here about Zimyo: tell us and we correct it or take it down.

Choose Zimyo if

This is the part of the page that makes the rest of it worth reading. If one of these describes you, the honest answer is that Zimyo is the better buy, and we would rather you knew it here than three months into an implementation.

  • You want one vendor to compute Indian statutory payroll and produce the outputs that follow it. Zimyo publishes that inside its suite, and Capstan hands computation to a payroll partner permanently, so if you want one company to do both, that is the shorter path.
  • You want Indian payroll and the HR lifecycle around it from a suite built for that market, with the statutory content maintained by the vendor, and that India-market fit is the centre of what you want.
  • Your workforce and your data are in India and you want both held in that market. Zimyo is built for India, and Capstan runs one region in the EU today.

The part that costs us the sale

Where Capstan is the wrong choice

Not a softened version of the section above. These are requirements Capstan does not meet and is not going to meet, written down so you can rule us out in a minute rather than in a quarter. If one of them is true of you, nothing else on this page matters.

  1. You want your HR software to compute pay and produce your statutory filings. Capstan does neither, in any country, by design and permanently.

  2. You need your data held in India specifically. Capstan runs one self-contained region in the EU today, data in Frankfurt and compute in Amsterdam, so an India-residency requirement is not one it meets right now.

  3. Your statutory content has to come from your software vendor. Capstan holds no rate, slab or formula anywhere, so when a rule changes the authority is your payroll partner and your own advisers, not us.

That is the list as we understand it today. If you hit a limit that is not on it, tell us: a disqualifier we did not know about belongs here more than anything else on the page.

If nothing on this page ruled us out, run it yourself.