Home / How we built CAHireX
Most software companies ask you to trust a portfolio. We would rather you open a product we built, use it for ten minutes, and decide for yourself. CAHireX is live, free, and needs no card.
Why this page exists
Anyone can put screenshots on a page. It is much harder to build something, fund it, ship it, and keep it running while real people depend on it being correct — especially when the subject is Indian tax, where being approximately right is the same as being wrong.
CAHireX is our own product. We pay for it, we maintain it, and we are the ones who get it wrong in public if we get it wrong. Everything below describes a decision we actually had to make. You can check every one of them in the product itself.
At a Glance
01 — The deceptively simple bit
One dropdown. A surprising amount of logic behind it.
Ask most people what makes GST invoicing hard and they will say the maths. The maths is trivial. What is hard is place of supply — whether a sale is taxed as CGST plus SGST, or as IGST, depending on where your client is registered relative to you.
Get it wrong and the invoice is legally wrong, the client cannot claim input credit cleanly, and someone finds out months later during reconciliation. This is one of the most common errors in Indian small-business invoicing, and it is entirely avoidable in software.
In CAHireX you pick the client. The split is decided for you, from the client's state, every time. There is no checkbox to get wrong.
Why it matters to you
If your business has a rule that everyone on the team is expected to remember, that rule belongs in the software. Every time a human has to remember it, you are running a small daily lottery.
02 — The decision we are proudest of
The harder architecture, chosen on purpose.
Importing a bank statement is the fastest way to make accounting software useful. It is also the fastest way to end up holding the most sensitive document a business owns.
The easy build is to upload the file to a server, parse it there, and store the result. It is simpler, cheaper, and it means every customer's bank statement now lives on our infrastructure. We did not want that responsibility, and more to the point, our users should not have to grant it.
So the parsing happens entirely in your browser. The file is read, matched and turned into transactions on your own machine. It is not uploaded anywhere. That is a harder thing to build and a slower thing to debug — and it is the right trade.
Why it matters to you
Ask any vendor where your data goes and what happens when you leave. If the answer is vague, the architecture is the reason. We would rather build the version that makes the answer easy.
03 — Building on ground that moves
Software for rules that are rewritten every year.
Most software is built against requirements that hold still. Tax software is not. Slabs move, thresholds move, deductions appear and disappear, and the answer to "which regime is better for me" changes for the same person from one year to the next.
That means the rules cannot be scattered through the code as numbers typed inline. They have to sit in one place, be replaceable, and be testable — otherwise every Budget becomes a frantic hunt through the codebase for constants someone hardcoded eighteen months ago.
CAHireX compares both regimes side by side, computes advance tax against the liability threshold, and calculates TDS by payment type and PAN availability. When the numbers change, the numbers change — not the logic around them.
Why it matters to you
Every business has rules that will change — pricing, commission, eligibility, approval limits. If changing one costs a developer a week, the software was built wrong. We design for the second version, not just the first.
04 — The unglamorous engine
Where most business software quietly goes wrong.
Plenty of tools will show you a profit and loss statement. Fewer can tell you exactly which transactions produced each line, and fewer still keep the balance sheet, the ledgers and the stock position honest with each other as entries change.
In CAHireX the reports are computed from the underlying transactions rather than maintained as separate records. Ledgers come from actual entries. Stock adjusts when a sale is recorded. Depreciation is calculated on the assets you entered, by written-down value or straight line, rather than being a number someone remembered to update.
This is the least visible work in the product and the part that takes the longest. It is also the part that decides whether the numbers can be trusted at the end of the year.
Why it matters to you
If two screens in your business show different numbers, you do not have a reporting problem. You have a data model problem, and no dashboard will fix it. This is usually the real reason a system "needs replacing".
05 — Two users, one product
Designing for the person who logs in fifty times, not once.
A business owner opens the software to raise an invoice or check what they owe. A Chartered Accountant opens it to move between many clients' books in a single afternoon. Same product, completely different job.
Build only for the owner and the CA finds it unusable at volume. Build only for the CA and the owner is faced with something that assumes accounting knowledge they do not have. CAHireX has a separate onboarding path for CAs and a practice view for working across multiple client books.
Recognising that you have two distinct users — and being honest that they need different surfaces — is a product decision, not a technical one. It is usually the decision that gets skipped.
Why it matters to you
"Our staff will use it" is not a user. The person who uses a screen forty times a day and the person who sees it twice a month need different software, even when it is the same screen.
What this says about how we build
You probably do not need GST software. But the decisions above are the ones that come up on every serious build, and they are the ones we would be making on yours.
We are a small, founder-led team, which means the person who writes the code is the person you talk to. It also means we take a limited number of client builds at a time, so each one gets that attention.
The part most companies leave out
Every project teaches you something by costing you something first. Three things CAHireX cost us:
We tested on the wrong machine. Parts of our test suite passed reliably in one environment and nowhere else, which is the same as having no tests at all — worse, in fact, because it feels like coverage. We fixed it, but we should have caught it far earlier.
We treated accessibility as polish. Contrast failures shipped and had to be corrected afterwards — dark text on a dark panel, a primary button below the accepted contrast standard. Retrofitting that is more expensive than getting it right at design time, and it is not a cosmetic issue for someone who cannot read the screen.
We let dead code accumulate through a redesign. A large amount of superseded markup stayed in the codebase after a rebuild, shipping to every visitor until we removed it. Cleanup is not optional work you get to later; it is part of finishing.
We would rather tell you this now than have you discover we are the kind of company that pretends none of it happens.
CAHireX is free and needs no card. Open it, break it, form your own view — then tell us what you are trying to build. We will tell you honestly whether we are the right people for it.