All work
Multi-tenant platforms · Live in production · 2026

Community lending ledger

Built for Passaic Clifton Gemach

A $1.58M interest-free loan fund whose headline number was wrong by $47,383.

An interest-free community loan fund ran on spreadsheets, contracts in Google Drive, and a bookkeeping tool with no transaction export. We built the ledger, and in the process found that the number everyone quoted was measuring the wrong side of the balance sheet.

$1.58M fund reconciled to the bank
44 lenders tracked individually
$47K previously-unexplained gap, resolved
Interactive. Try it

One fund. Two definitions. A $47,383 gap.

Switch which side of the balance sheet the headline number is counted from.

Total fund size $1,633,917.56

Counting from money-in produces a figure that can only ever rise. Four years of bank fees, write-offs and running costs had never come off it, and could not be netted off, because the books hold zero recorded transactions. Counting what is held needs no expense record to be correct: money that left the bank is already absent from it.

The problem

  • A fund capitalised two ways: donated money, and money owed back to 44 lenders.
  • Loan contracts sat as PDFs in Drive, disconnected from any record of the loan.
  • The headline fund figure had drifted $47,383 from what the bank actually held.

What we built

  • A loan ledger with borrowers, guarantors, repayment schedules and per-lender balances.
  • Contract sync from Google Drive, with guarantor extraction backfilled from the documents themselves.
  • A dashboard that reports the fund from the side that can actually be verified.
  • Per-lender statements showing each lender's money at work as a share of what the fund holds.

Outcome

  • The headline figure reconciles to the bank balance with no unexplained remainder.
  • Lender statements now show a share of what the fund actually holds.
  • The growth chart was relabelled rather than redrawn. It charts money in, which is a real series, instead of being forced onto a basis the underlying data cannot support.
PHPMySQLGoogle Drive APIDockerCoolify

What something like this costs

It took 26 working days, counted out of the repository rather than estimated afterwards.

With us From $10,500to build, then $450/month
At a mid-market agency $31,200 to $41,600the same 26 days at $200/hr, billed at 6 to 8 hours a day

A rate comparison, not a bill. Our figure is the published ladder from the pricing page, for the closest match to this shape of work. Working days regenerate from the repository on every deploy.

The full write-up problem, constraints, and the whole debugging story. About a 4-minute read

01 The problem

The fund lends interest-free and is capitalised by two very different sources: money donated outright, and money lent to the fund by 44 individuals who expect it back. Tracking who is owed what, what is out on loan, and what is actually in the bank was a spreadsheet exercise nobody could fully verify.

Loan contracts lived as PDFs in Google Drive, disconnected from any record of the loan itself, and guarantor details existed only inside those documents.

02 Constraints

  • The books had zero journal entries and zero recorded transactions. Four years of bank fees, write-offs and running costs had simply never been entered anywhere.
  • The bookkeeping tool in use has no scheduled export and no per-transaction API, so expenses could not be pulled in and netted off.
  • The administrators are not technical. Anything requiring a reconciliation ritual would not get done.

03 What we built

  • A loan ledger with borrowers, guarantors, repayment schedules and per-lender balances.
  • Contract sync from Google Drive, with guarantor extraction backfilled from the documents themselves.
  • A dashboard that reports the fund from the side that can actually be verified.
  • Per-lender statements showing each lender's money at work as a share of what the fund holds.
The hard part, in full

The headline number was measuring the wrong side

Total Fund Size was computed from money that went in: donations plus what was still owed to lenders. That figure can only ever rise. Four years of bank fees, write-offs and running costs had left the fund without ever coming off the total.

So the dashboard read $1,633,917.56 while the gemach actually held $1,586,533.86, and the $47,383.70 between them sat on the page labelled "unexplained difference". Visible to everyone, explicable by no one.

The instinct is to find the missing expenses and subtract them. That was impossible: there is no expense record to find, and building one retroactively across four years would have been an invention, not a reconstruction.

The fix was to change which side the number is counted from. Fund size is now what is held: out on loan, plus cash in the bank, minus grants still to be distributed. That needs no expense record to be correct, because money that has left the bank is already absent from it. Money-in is kept as its own separate figure, since "who do we owe" is a genuinely different question from "what do we have", and the gap between them is now reported plainly as what has been spent.

Two consequences were accepted deliberately. A lender's share of the fund rose, because the denominator got smaller. And that is the more truthful number. And the fund is allowed to go negative rather than being clamped at zero: a fund over-committed to causes should say so on its own dashboard.

Got something shaped like this?

Tell us what it is and what has stopped working. We will tell you what we would build.