The week of July 6–12

Context

What we're actually building

Capxul is a money app, but under the hood it's really a platform. The blockchain side — holding value in smart wallets, moving it on-chain — is already built and working. The frontier now is the opposite direction: getting money out of the system and into someone's bank account, mobile-money wallet, or card in the real world.

That turns out to be the hard, valuable part, and it's why we split the product into two codebases this week. Everything below serves that split: one repo is the app people click on; the other is the infrastructure — the reusable kit that other developers can build on too. The bet is that lowering the barrier for everyone else is where the real value sits.

01 · The centre of the whole thing

The cash-out router

Foundations complete · not yet live

To pay someone out into the real world, you go through a third-party "neobank" provider — Paycrest, HoneyCoin, Lightspark, and others. Here's the catch: none of them is great. Each one covers only certain countries and certain kinds of customer, each has a different way of working, and some won't even sign up a small company until it proves real volume.

So we didn't wire ourselves to any single provider. We built a router — the same idea as a "DEX aggregator" that finds the best venue for a crypto trade. The app calls one clean instruction ("pay this out"), and behind it a registry picks which provider to use for that specific payout. That's not a metaphor bolted on afterwards; it's literally how the code works — there's a select() step that filters providers by what a given payout needs and routes to the match.

The design already earned its keep this week: our first live provider target quietly shifted from Lightspark to Paycrest and HoneyCoin based on a fresh market scan. Because everything sits behind the router, that change costs us almost nothing — which is the entire point of building it this way.

How money leaves Capxul

The router tracks a payout across four hand-offs of authority. Money only ever rests in two of them, but naming all four is how the system stays honest about who is allowed to move what:

1. The user's smart wallet. Value sits on-chain; only the user's own approval can move it. on-chain — already built
2. The provider's account. Funds land with the neobank provider, released only by a signature from the customer's device. the on/off-chain boundary
3. Provider settlement. The provider routes the value over bank, mobile-money, or card rails. off-chain — the new work
4. The destination. The actual bank account or wallet on the other end. off-chain

What shipped

The full spine landed this week — ten connected pieces. In plain terms: the shared shape every provider must fit; the router that picks between them; the on-chain payout leg (which reuses our existing wallet machinery rather than rebuilding it); fail-closed rules for which countries and rails are allowed; a crash-safe ledger that tracks a payout through its whole life; and a vault that encrypts full bank and phone numbers at rest with proper, production-grade cryptography, keeping only a masked ••••7890 anywhere it could leak. Bank numbers and signatures are barred from ever reaching the app — or an AI agent — by design.

All of it is proven end to end, but against a stand-in "fake" provider. No real provider is connected yet — production deliberately refuses to move money until one is wired.

It's a fully-built chassis with no engine plugged in yet — and that's on purpose.

The next step is wiring the first real provider through the seam we locked. When that lands, the router stops being a well-tested skeleton and starts moving actual money.

Why this lives in the SDK, separately

This is the moat. Those providers gate on scale and compliance — one needs business verification that takes days, another needs fixed-IP whitelisting and national ID checks before it'll touch Nigeria. An app built on Capxul inherits our provider relationships and compliance posture instead of negotiating each one from scratch. That's the barrier we're removing: normally you'd need serious monthly volume and your own direct KYC and neobank deals before you could build anything like this. Pool that once, in shared infrastructure, and everyone after us skips the hardest, slowest part.

02 · The anchor task

The cutover: splitting the app from the infrastructure

In progress · critical path

Historically the app reached straight into the backend's internals — the database, the login system, the wallet provider. This week we cut those wires. From now on the app is only allowed to talk to a published kit (@capxul/sdk), the same public way an outside developer would. Think of it as forcing our own app to order from the public menu instead of walking into the kitchen. It makes the backend a clean, versioned product the frontend can't accidentally break — and that other teams can actually use.

On the infrastructure side we published those clean contracts, locked the shared "money" and "account" types so the two sides can't drift apart, and fixed a real bug where signing out still left the previous user visible. On the app side we moved onto the published packages, ripped out about 1,900 lines of leftover backend code, replaced fake dashboard data with real published hooks, and rebuilt the login flow — the auth widget, its loading states, and the logic that decides where a signed-in person actually lands.

Why this is the hard part — and why that's the plan

To be clear about status: login through the new kit doesn't work end to end yet. Locally it's still blocked, and the team is working through a mix of deployment problems, a few real bugs, and a pile of rough edges. None of it is a dead end — it's the friction of doing something genuinely hard for the first time.

And it is genuinely hard. Getting a single user signed in here means wiring together a stack that, as far as we can tell, nobody has combined before: embedded wallets (Openfort), authentication (BetterAuth), a live backend (Convex), and raw on-chain signing (EVM) — all at once. On top of that, we deliberately split the product into two separate codebases, and forcing the app to reach its backend only through a published kit is itself a real step up in difficulty over one bundled application. This is the most complicated thing in the entire project, and it's what we chose to build first.

We started with the hardest part on purpose — so the rest gets easier, not harder.

That's the payoff to hold onto. Once login works and the first transaction goes through, the path to a demo that matches our old app should be comparatively quick: the difficult, novel patterns will be solved, and most of what's left simply repeats them. There's still real work ahead on the SDK — but from that point on it's the straightforward kind.

03 · Now live

Seeing failures the moment they happen

Live & verified

Until now, when our SDK broke inside a partner's app, we were blind to it. Not anymore. The kit now quietly reports its own failures home to our monitoring — sending only three tiny, scrubbed facts (which operation, what kind of error, which version), never anyone's private data or wallet details. A partner can optionally point a second copy at their own dashboard too.

From there it's automatic: a failure becomes a tracked, owned ticket on its own, and the team gets pinged with a link straight to it — no human has to notice and file it. We proved the whole chain live by firing four identical errors and confirming they collapsed into exactly one ticket, not four. Along the way we found we'd been hand-building automation that the monitoring tool does natively, so we switched to the native version and deleted around 11,000 lines of our own glue — glue that had quietly been filing every issue twice.

04 · Shipped

Zero to running in one command

Shipped

A brand-new developer can now go from nothing to a working Capxul app by typing a single command — npx @capxul/sandbox — with no login, no secrets, and no account setup. It hands back a working sandbox key on the spot. We also made Next.js the one official "golden path" tutorial, and made test-money smarter: you can send funds to a Capxul email or @org-handle instead of copy-pasting a raw wallet address. Time-to-first-success is the single biggest driver of whether developers stick around, and we cut it to under a minute.

05 · Shipped

A safety net you can actually trust

Shipped

Every change above needs an automated check to catch bad code before it reaches customers. Ours had drifted: the main check was quietly broken — a real error was hiding under expected noise — tests timed out at random, and the whole suite ran twice. A lot of the bulk was early scaffolding: tests we wrote to stand the project up in the first place, so our agents had something concrete to build against. They did their job — we'd just kept far more than we still needed, on infrastructure that hadn't kept up. We rebuilt that foundation: the check is now reliable (ten clean passes in a row), starts about 85% faster (from twelve minutes down to under two), runs once instead of twice, and only re-tests the code you actually touched — and we retired roughly 3,400 lines of that outgrown scaffolding without losing any real coverage. In plain terms: fewer bad releases reaching customers, and faster shipping for everything else.