Three people, 11 trade portals, one ledger behind $250 million funded. The stack we built, the problems that are still hard, and how a change ships.
Last edited 7 min read
Spring has funded more than $250 million to over 300 businesses, and three people built nearly all of the software that decides, moves and accounts for every dollar of it.
Most capital providers rent that software. On top of a bank sit a payments processor, a data vendor, a decisioning vendor and a servicing vendor, with a team in the middle holding them together. We build instead: the Spring stack is seven layers, from a bank partner and the payment networks at the bottom to the four products on top, and the five layers above the networks are our own code. This post shows the stack, the problems in it that are still hard, and how a change ships.
Our bank partner provides the capital we fund our customers with. Every layer above stands on it.
ACH, wire, RTP and FedNow move money out when we fund and back in when it is paid. Whichever rail a payment takes, it lands in the same ledger.
One ledger records every dollar, and every balance, chart and report is read from it. When two systems disagree about a balance, the ledger is the answer.
We read a business's bank, books, sales channels and 11 trade portals directly. That is the data every layer above decides on.
Funding decisions come from live data, not last quarter's statements. For Bridge Funding, an agent reads the file and a deterministic engine sets the grade.
Each payment is matched to the invoices it settles, which are ticked off as paid, and a short pay is traced to its cause. Both are among the hard problems below.
Invoice factoring, PO financing, Demand Plan and Bridge Funding all run on the same stack. A new product is a new set of rules on the same layers, not a new stack.
What does the engineering look like?
The stack
Python 3.14 and FastAPI on Postgres: 620 tables, and close to 1,000 schema migrations since we moved migrations to Atlas in June 2026. The apps are TypeScript and React: this site is Next.js, the customer app and the admin app are Vite.
Which invoices did this payment settle?
A retailer pays with one check that settles many invoices at once, net of the deductions it took along the way. The remittance that explains the check lives in the retailer's portal, in that retailer's format, and some portals turn the usual order around: each invoice line names the check, while the check names no invoice. The same invoice can also reach us from any of 17 sources: the retailer's portal, EDI, emailed or uploaded documents and the brand's own books. We resolve all of them into one graph per business. The portal wins on amount, because it already reflects price changes and short pays, and a higher figure from the books or an old EDI invoice never overrides it: a stale higher amount would mean advancing more than the retailer will pay.
Why did the retailer pay less?
When a retailer pays less than the invoice, the gap is usually a deduction: a promotion, a scan-down, a shortage, a compliance fine. Every retailer writes its own codes. We map them into 14 reason families, and only one of them, an invoice short pay, belongs to a single invoice; the rest land on the account, not on one invoice. The data does not make it easy. In September, KeHE's deduction feed named the purchase order on 2,106 of 7,139 deductions and the invoice on none, so the graph walks from each purchase order to the invoices shipped against it. When one order shipped on several invoices, which invoice a deduction belongs to is still an open problem, and one you could own.
How do you read a portal that has no API?
Retailers give their suppliers a portal, not an API. We connect 11 today: retailers such as Target, Walmart, Costco and H-E-B, distributors such as KeHE and UNFI, and a 3PL, plus EDI through SPS Commerce. The hard part is signing in: each portal has its own login, its own second factor and its own session rules. A connection runs one of three ways, chosen per portal: the brand signs in through a browser session inside our app, the brand gives us a login, or a seat Spring holds pulls the data with no customer login at all. Once signed in, we read the portal's own data endpoints with typed clients rather than scraping pages. Adding the next retailer, and keeping all 11 connected as their portals change, is work you could own.
What do the agents do?
Agents built on Claude do the reading a credit team used to do. The agent that decides Bridge Funding reads a business's bank feed, books and retailer data, asks a deterministic tier engine for the grade rather than inventing one, and has to end every run on one schema-checked decision. The credit policy it applies is a rule set our credit team edits, not text buried in a prompt. Customers talk to a finance agent that answers from the same data, and a change to its tools or prompts cannot merge without an eval run in the pull request. The next agents to build run money movement and repayment, and building them is much of what the role is for.
Who builds it, and how does a change ship?
The team is three engineers, with experience from Two Sigma, Airbnb, Meta and Wolverine Trading, in person in New York. Coding agents do much of the typing: in the 30 days to October 19 we merged about 2,700 pull requests into main, and most were opened by coding agents. The engineer's job is the part an agent cannot do alone: decide what to build, write the rules and checks that hold an agent to it, review what comes back, and own it in production. An agent's pull request clears the same type checks, tests and lint ratchets as ours, and a change to a screen has to carry screenshots or a film of it working before it can merge. Every change is a pull request: a pre-push check runs the lanes for the code you touched in seconds, CI runs the rest, and a merged backend change is live, migrations included, in about ten minutes.
One change, every layer
On September 1, 2026 we connected H-E-B in one pull request: a table for H-E-B's records, the portal sign-in with its emailed one-time code, the parser, the deduction rollup, the matching graph, the set of invoices we can fund, the inputs to the cash-flow forecast, and the screen where a brand connects it. 91 files, one deploy.
Why build the stack ourselves?
Changes that cross layers are easy. When a brand starts selling into a new retailer, we connect that retailer's portal, and the risk layer can use what it reads the same week, because both layers are our code. When we learn that a signal predicts late payments, we add it to the data we collect and to the model that decides, in one change, with no vendor roadmap to wait on.
We own the parts that matter. We use outside providers where they help, mostly to fetch and enrich data, but the systems that decide, move and account for money are our own code. When something breaks there, we fix it ourselves.
A small team scales with volume. A capital provider built on vendors and manual review needs people roughly in step with its volume. On a stack where agents do the reading, volume grows much faster than the team, and the lower cost per dollar funded is what lets us price lower. The business case is in Capital first.
Owning more also means there is more to build and maintain, and that is the work we are hiring for: founding engineers who want to own a layer of it.
Frequently asked questions
What stack does Spring use?
Python 3.14 and FastAPI on Postgres, with Atlas for migrations. The web apps are TypeScript and React: Next.js for spring.ai and Vite for the customer and admin apps. Agents built on Claude decide Bridge Funding applications and run the customer-facing finance agent.
How big is the Spring engineering team?
Three people built nearly the entire stack, with experience from Two Sigma, Airbnb, Meta and Wolverine Trading. Coding agents open most of the pull requests, and every one clears the same checks as a human's. We are hiring founding engineers to work in person in New York, with visa sponsorship available.
What would a new engineer work on?
The layers in this post: matching payments to invoices, tracing deductions, connecting new retailer portals, and the agents that make funding decisions and run money movement and repayment. You would work directly with the founders and own a change from design to production.
