AC/DC Cash Flow

Agribusinesses go bankrupt between harvests. We rectify them from alternating to direct current: investing against inflation to give them stable income all year round.

Comment

Inspiration

One of us spent years close to the agricultural sector, where the same conversation comes up every cycle: the harvest season brings in more revenue than the rest of the year combined, and then the off-season arrives. Nobody can say with confidence how much of that harvest money is actually profit, how much has to go straight back into seeds, fertilizers, and equipment for the next planting season, and how much is safe to spend. The numbers aren't missing — they just aren't regulated. Income comes in like an unpredictable wave dictated by crop cycles, but land leases, payroll, and next season's agricultural inputs need a steady, predictable signal.

That gap between a farm's real cash flow and the steady signal it needs to operate is where AC/DC Cash Flow started[cite: 1]. The name is literal: alternating current, the volatile up-and-down of a seasonal agribusiness's real income, rectified into direct current — a steady, regulated signal the farm can actually plan around[cite: 1].

What it does

AC/DC Cash Flow is a treasury platform tailored for seasonal agribusinesses and small farms[cite: 1]. An agricultural producer signs up, either uploads its own historical harvest-income and input-spend data or starts from a seasonality template matched to the agricultural industry[cite: 1], and the platform:

  • Classifies each month as high, regular, or low season from real statistical deviation against the farm's own history — not a guess[cite: 1].
  • Regulates income across three accounts: an operating account, a liquid "regulator fund" that tops up income during off-season months, and a term investment account that captures harvest surplus[cite: 1].
  • Prices real yield, anchored to Mexico's actual Cetes 28-day rate pulled live from Banxico[cite: 1], with a transparent commission model: we only charge on the alpha generated above the risk-free benchmark[cite: 1].
  • Projects 30–90 day liquidity with honest uncertainty bands, not a single flattering number[cite: 1].
  • Plans next season's reinvestment, scaling the agricultural input reserve (seeds, machinery upkeep) with the farm's real year-over-year growth instead of a fixed amount[cite: 1].

Every account is backed by real Capital One Nessie customers and accounts, not mocked data[cite: 1].

How we built it

The backend is Python 3.11 and FastAPI with MongoDB Atlas, JWT auth[cite: 1], and three real external integrations: the Nessie banking API[cite: 1], Banxico's SIE API for the reference rate[cite: 1], and a from-scratch forecasting engine. The frontend is React with Recharts, built as a proper multi-page dashboard rather than a single demo screen[cite: 1].

The core forecasting engine fits an autoregressive model by ordinary least squares via SVD[cite: 1]:

$$ \hat{y}{t+1} = \beta_0 + \sum{i=1}^{p} \beta_i \, y_{t-i+1}, \qquad \beta^{*} = \arg\min_{\beta} \lVert A\beta - b \rVert^2 $$

and then projects forward not as one deterministic line, but as hundreds of Monte Carlo trajectories built by bootstrapping the model's own historical residuals[cite: 1] — which is what actually surfaces realistic best-case/expected/worst-case liquidity bands[cite: 1]. The commission engine is just as explicit:

$$ \text{commission} = \gamma \cdot \max(r_{\text{product}} - r_{\text{benchmark}},\ 0), \qquad \gamma = 0.20 $$

so the platform only earns when it beats the risk-free rate, never on the base rate itself[cite: 1].

Our team of four split the work across the seasonal regulation engine, the Nessie/Mongo integration layer, the forecasting math, and the frontend[cite: 1] — and for a meaningful part of the build, we worked alongside Claude Code as a pair-programming partner: writing code together, and just as importantly, using it to verify every claim against the real, running APIs instead of trusting that the code "should" work[cite: 1].

Challenges we ran into

Almost every real challenge came from external systems not behaving the way their own documentation implied — and from insisting on verifying against the live APIs instead of trusting the code on paper:

  • Nessie's originally documented base URL no longer resolves at all, and the working one silently drops plain HTTP requests — it only responds over HTTPS[cite: 1].
  • Nessie's account-type enum doesn't actually include "Investment", only Checking, Savings, and Credit Card, despite that being the natural type for our third product[cite: 1].
  • Our first liquidity forecast looked great and was actually wrong: an iterated autoregressive point-forecast converges toward its own mean, so the projection came out nearly flat — its cumulative curve fit a straight line with $R^2 = 0.9993$[cite: 1]. It looked like a best-case scenario because it mathematically was one, with the uncertainty averaged away at every step[cite: 1].
  • Getting Docker networking right across environments — a nginx upstream that could crash the whole container if the backend wasn't ready yet, and a subtle double /api/api/ prefix bug that only showed up in the production build, not in local dev[cite: 1].

Accomplishments that we're proud of

We're proud that this isn't a dashboard sitting on top of fabricated numbers. Every account balance on screen is the output of an actual regulation engine running against real (or realistically templated) history[cite: 1], the reference rate is fetched live from Banxico[cite: 1], and the accounts themselves exist as real Nessie customer accounts we can look up independently of our own backend[cite: 1]. We caught the flat-line forecasting bug by actually measuring it, not by eyeballing a chart — and fixed it with a statistically honest Monte Carlo simulation instead of patching the symptom[cite: 1]. And it feels right that one of our core business templates is a seasonal agricultural producer[cite: 1], directly addressing the exact kind of high-volatility crop cycles that make this tool necessary.

What we learned

We learned that an autoregressive forecast that "looks stable" and one that's "actually right" can look identical until you check what happens to the variance — a lesson in never trusting a chart that looks too clean[cite: 1]. We learned that public sandbox banking APIs drift out of sync with their own docs, and that the only reliable way to find that out is to actually call them, live, with real credentials[cite: 1]. And on the product side, we learned that the hardest part of a farming business's cash flow isn't recording the numbers — it's deciding, before the harvest turns to winter, how much of today's income belongs to tomorrow's planting season.

What's next for AC/DC Cash Flow

  • Operate through a regulated partner: to legally offer the equities-based product, the platform should sit on top of a licensed fund manager rather than acting as an unlicensed broker[cite: 1].
  • Pilot with a real seasonal farm — starting with a local agricultural producer or cooperative — instead of relying only on templated and synthetic history[cite: 1].
  • Backtest the equities product's expected return against real historical index data, replacing our current placeholder multiplier with a defensible number[cite: 1].
  • Go to market through agricultural cooperatives and agritech software providers that already serve the farming sector, where the crop-yield and seasonality data we need is often already being collected.

Built With

Share this project:

Updates