Can Hercules Build Accounting Software? We Tested It on a Real Farm — Here’s What It Got Right and Wrong.

---

Most “vibe coding is risky” writing leans on the same handful of headline breaches: a missing auth check here, an exposed database there. Useful, but it tells you almost nothing about the other kind of failure — the one where nothing looks broken. The app runs, the numbers show up, the PDF exports cleanly, and it’s simply wrong in a way nobody notices until it matters.

So instead of asking “can Hercules keep your data safe,” we asked a harder question: can Hercules build accounting software that’s actually correct on a real farm’s books — the kind of domain logic an accountant, not just a developer, would need to get right?

We built the app, then read every line of the generated source.

The Test: Can Hercules Build Accounting Software?

We gave Hercules one prompt, in plain language, describing a livestock farm accounting system:

Build a livestock farm management app for small pig farms. I need a proper accounting module, not just a simple income/expense list — here’s the logic: every transaction belongs to an account with a group: Asset, Liability, Income, or Expense. For the cash flow statement, classify transactions by that account’s group first, not by whether money went in or out: Liability-group accounts go under Financing activities, Asset-group accounts go under Investing activities, and Income or Expense-group accounts go under Operating activities. But if an account’s name contains “Repayment,” always treat it as an outflow under Financing regardless of its group. Pure liquidity accounts (cash, bank) should be excluded from the cash flow statement entirely — they’re the result, not an activity.

I also need a Balance Sheet with an opening balance for each fiscal year that carries forward automatically, and retained earnings calculated as opening balance plus net profit for the year minus any owner withdrawals. Let me pick which fiscal year I’m viewing, and let me manually edit the opening balance only for the very first fiscal year the farm was set up in — after that it should be locked and calculated automatically.

Add a working capital ratio calculated on a rolling 365-day basis. Let farmers export their financial statements as a PDF, formatted in Indian Rupees.

Nothing in that prompt is exotic. It’s an ordinary chart-of-accounts structure, the kind any bookkeeping-adjacent app needs. But it has real precedence rules (the Repayment override has to win before the group check runs), real state that has to persist correctly across time (opening balances carrying forward, year over year), and a formula with more than one term (retained earnings isn’t just “this year’s profit”).

Hercules built it. It ran. It looked right.

What It Got Right

Genuinely more than we expected — especially given the specific question we set out to answer: can Hercules build accounting software with correct domain logic, not just software that runs?

The classification precedence was implemented in the correct order. The generated code checks whether an account is a liquidity account first (excluding it), then checks whether its name contains “repayment” — before it ever looks at the account’s group — and only falls through to group-based Operating/Investing/Financing routing after that. That ordering is exactly what the prompt specified, and it’s the kind of detail that’s easy to get subtly wrong.

The same logic was implemented twice, consistently. The on-screen Cash Flow component and the PDF export are two separate pieces of code, written at different points in the build. Both implement the same three-step precedence in the same order. That’s a real consistency win — and it makes what happened on the Balance Sheet (below) more interesting, not less.

Opening-balance carry-forward was structurally correct for Asset and Liability accounts: the previous year’s closing balance becomes this year’s opening balance, computed rather than stored. That’s real accounting logic, not a stub.

Every backend function we read had correct, real, server-side authorization. Every query and mutation re-derived the current user from their authenticated session, and every one verified ownership before returning or modifying data. The mutation that creates a user account accepted zero client arguments, so there was no way to smuggle in an isAdmin: true through a side door. We went looking for the exact bug class behind most of this industry’s named 2025–26 breaches — missing authorization checks, client-trusted privilege fields, insecure direct object references — and in this app, across every file we read, didn’t find it.

That last point deserves emphasis, because it cuts against the easy narrative. On the security axis, this app was clean.

So, can Hercules build accounting software safely? On the security axis alone — yes, without qualification.

What It Got Wrong

Can Hercules build accounting software that’s correct, not just software that runs? Only partly — and the gap between those two things is the whole story. Three things went wrong. None of them is a security hole. All three are worse in a way that’s harder to explain: they produce confident, plausible, wrong numbers, silently, with no error and nothing in the UI to suggest anything is off.

1. The Balance Sheet Double-Counts Profit, and Gets Worse Every Year

The on-screen Balance Sheet applies opening-balance carry-forward to every account group — including Income and Expense.

In real accounting, Income and Expense are temporary accounts. They reset to zero at the start of each fiscal year; that’s the entire point of closing the books. Only Assets, Liabilities, and Equity carry forward. The generated code treats all four groups identically, so income accumulates across years as if it were a permanent balance.

Then it computes retained earnings from those already-inflated figures.

Here’s the arithmetic, with the simplest possible numbers. A farm with one Sales account, no expenses, no withdrawals:

	Year 1	Year 2
Actual sales that year	₹100	₹150
Correct retained earnings, cumulative	₹100	₹250
What the app shows	₹100	₹350

Year one is right — and that’s exactly why this is dangerous. The error is invisible until year two, when it overstates by ₹100 (year one’s profit, counted twice). Year three compounds it further. The longer the farm uses the app, the more wrong the number gets, and at no point does anything break.

It also silently drops prior years’ owner withdrawals from the carried-forward figure, which pushes the number in the same direction: too high.

This bug alone answers the question we opened with — can Hercules build accounting software you’d hand to a bank loan officer? Not on this evidence, not without a human checking the math first.

2. The Screen and the PDF Disagree With Each Other

This is the finding we did not expect.

The PDF export has a different bug: it hardcodes opening retained earnings to zero every single year, instead of carrying anything forward.

So for the same farm, in the same fiscal year, on the same data:

• The on-screen Balance Sheet says ₹350
• The exported PDF Balance Sheet says ₹250

Neither is right, and they’re wrong in opposite directions. If you’d checked the app against its own PDF as a sanity test — which is a perfectly reasonable thing for a careful non-technical founder to do — you’d have caught it. If you’d only ever looked at one, you’d have had no signal at all.

It’s the clearest reminder that “can Hercules build accounting software” isn’t a yes/no you answer once — it has to hold true on every screen, every export, every time.

3. The Working Capital Ratio Isn’t a Working Capital Ratio

This one is definitional rather than arithmetic, and it’s arguably the most fundamental error of the three.

Working capital ratio = Current Assets ÷ Current Liabilities. Both terms are balances at a point in time — what you hold and what you owe, right now.

The generated component instead sums the transactions that occurred inside the rolling 365-day window and treats those sums as the assets and liabilities. That’s transaction volume, not balance.

The practical consequence: a farm holding ₹50,000 in a current asset account that simply had no transactions this year contributes ₹0 to “Current Assets.” The app then renders a confident Healthy / Adequate / Warning badge based on a ratio computed from a quantity that isn’t the one the label describes.

The rolling-365-day window itself — the part the prompt explicitly asked for — was implemented correctly. The AI got the unusual, hard-to-specify requirement right and the standard textbook definition wrong. Get a ratio’s definition wrong and every dashboard built on top of it inherits the error — which is exactly why “can Hercules build accounting software” is a definitional question as much as an arithmetic one.

4. (Bonus) The Lock That Wasn’t a Lock

The UI says “First year — opening balances are editable,” implying they’re locked afterwards. The backend mutation that writes opening balances accepts any fiscal year, first or fifth, with no check. The promise exists only in the interface text. Nothing enforces it on the server.

Nobody’s data leaks through this. But it means the “locked and calculated automatically” guarantee from the prompt was never actually built — and if any future feature, bug, or curious user reaches that mutation for a later year, every carried-forward balance after it changes silently.

Why This Pattern Matters More Than a Breach Story

Everything in this post comes back to one question: can Hercules build accounting software that survives contact with a real business, not just a demo?

If you were a farm owner taking this Balance Sheet to a bank for a loan application in year three, you’d be handing over an overstated number with complete confidence — and if the loan officer asked for the PDF instead of a screenshot, they’d get a different overstated number.

That’s not a security incident. Nobody attacked anything. The system did precisely what it was built to do, and what it was built to do was wrong.

This is exactly the risk you take when you skip the real question — can Hercules build accounting software that’s actually correct? — and just assume software that runs is software that’s right. This is the category of failure the vibe-coding conversation mostly ignores, because it doesn’t generate headlines. There’s no CVE for “your retained earnings compound incorrectly.” There’s just a founder who trusted a number.

What We’d Tell You to Do About It

The honest answer to “can Hercules build accounting software you can trust?” is this: it got the security-critical parts right and the correctness-critical parts wrong. That’s a meaningfully different risk profile than most of the platforms we’ve researched, and it changes what you should actually be checking.

If you’re running an app with real business logic built on any AI app builder, the questions worth asking aren’t mainly about hackers:

1. Does any number in your app depend on more than one time period? Test it across a year boundary with numbers you can verify by hand.
2. Do two different views of the same figure agree? Screen vs. PDF vs. export vs. email.
3. Does every rule the UI promises actually exist on the server, or only in the interface copy?
4. Are your temporary accounts (income, expense, anything period-scoped) actually resetting?

This is precisely the work SuperApps does. We build and run production apps ourselves — Nodik, BlogPilot, Sociophile, Videophile, PigPal — and the accounting logic in this test is logic we’ve had to get right in our own products, against real users and real money. When we review a vibe-coded app, we’re not running an automated scanner over it; we’re reading the generated code against the spec you actually asked for, the same way we read the four files in this post, and finding the places where confident output and correct output diverge.

If you’ve got an app in production and you’ve never had the numbers checked by someone who reads the code, that’s the review we do.

The Honest Caveat

This is one test app, one prompt, read by hand. Treat it as exactly that much evidence — not a platform-wide audit, and not a claim that every Hercules app has these bugs. What it does establish is that the failure mode exists, that it is subtle, and that “it built without errors” and “it built correctly” are not the same sentence. Can Hercules build accounting software you can rely on the first time, every time? Not yet on this evidence — but the gap is fixable, and that’s the entire point of testing before you ship.

We ran a second, completely different test on the same platform — a real Stripe billing integration — to see whether the same pattern held. It did.

---

Series note: this post contains no affiliate links. We keep our testing and code-review posts free of referral relationships, because a review that pays us when you sign up isn’t a review. Our neutral platform comparisons are labelled where they do carry them.