Skip to main content
Work

Case 001 / Work

Spliz

Founder, product engineer · 2026 →

7 min read

Years
2026 →
Scope
Solo, from product thesis to production
Stack
React Native 0.83 · Expo 55 · NestJS 11 · PostgreSQL · Solidity 0.8.24 · Foundry · Base · USDC · Privy · Next.js 16
Live site
spliz.app
Download
App Store · Google Play
Spliz — hero

New Year’s Eve 2025, Montréal. I owe my host 47 Canadian dollars. The expense tracker did its job, the math is right, everyone agrees. Then comes the payment. “Do you take Wero?” “What’s that?” “Pix maybe?” “I use Interac.” Twenty minutes later we give up and say we’ll settle it later. We never settled it.

The math was never the problem. The problem arrives right after: someone fronts the money, two pay back straight away, one promises tomorrow, one disappears. A week later you chase, a month later you let it go. Multiply that by ten trips and two years of flat-sharing, and you have the real cost of “we’ll settle it later.”

Payment rails are fragmented by border. Wero in Europe, Pix in Brazil, Interac in Canada, Zelle in the US. None of them speak to each other. I started coding Spliz on 15 January 2026.

The brief

There wasn’t one. It is my product, my thesis, my budget. I held all of it alone for seven months: product, mobile app, API, smart contract, production infrastructure, compliance, landing page.

The bet fits in one sentence: don’t build another tracker, fix the part that breaks, which is settlement. With a stablecoin as a neutral rail, behaving the same in São Paulo, Toronto and Paris.

  • React Native 0.83
  • Expo 55
  • NestJS 11
  • PostgreSQL
  • Solidity 0.8.24
  • Foundry
  • Base
  • USDC
  • Privy
  • Next.js 16

The constraint

I wanted the experience to come down to one button: Settle. Behind that button, a multi-party cryptographic consensus had to hold, batch into a single transaction, stay secure, and never make me custodian of anyone’s money.

Spliz settlement screen, Settle button before signing
Frame 01 The Settle button, before signing.

One gesture

Settle

Off-chain

  1. 01EIP-712Each member approves their own balance with a typed signature. Nothing has touched the chain yet.
  2. 02EIP-2612Debtors pre-authorize USDC with a permit, which removes the separate approval transaction.

On-chain

  1. 03RelayerSubmits the settlement and pays the gas, so nobody has to hold ETH to be paid back.
  2. 04VerifyThe contract re-checks every signature itself before moving a cent. Trusting the API here would make the API the vault.
  3. 05AtomicEvery transfer executes, or none does. There is no state where half a group has settled.
One word for the user, five steps and two standards underneath. None of it is optional, and none of it is visible. Point at any step.

Five steps, two signature standards, one transaction. Users never hold ETH, never see an approval screen, and cannot end up in a half-settled group.Seven distinct signature types coexist in the product, from on-chain settlement to authentication.

The decision

A group is alive. While two members are signing, a third edits an expense. The question to settle: what invalidates the signatures already collected?

I drew the line. Any change to a member’s net balance, their “I owe” or “I get back”, is non-cosmetic. It invalidates the signatures, and the affected members are notified. Everything else goes through without friction.

That is what lets the people from that New Year’s Eve, back home in Canada, France and Brazil, edit the same group at the same time without anyone signing an amount that no longer exists.

The detail that hurts

USDC has six decimals. Fiat currencies have two. Every multi-currency display lives in that gap, and one misplaced rounding inside a signing path produces a signed amount that does not match the displayed one.

Group balances in multiple currencies, approximate euro amount above the exact USDC amount
Frame 02 The wallet. The local value says it is approximate; the exact one, the one that gets signed, stays readable.

The answer is a single invariant: the display is never the source of truth. One canonical representation, an integer in micro-units, from the database through to the signature and the contract. Displayed shares may drift by one cent; the sum of micro-units is strictly equal to the total.

I did not stop at fixing the cases I found. I wrote guard tests that fail CI if anyone reintroduces the pattern: any float multiplication by a million inside a signing path, any lossy round-trip conversion, any display reading the wrong source. The class of bug is closed, not just its instances.

The design

The design is mine. I wanted something sober, black and white, without being neutral: a combination of liquid glass, nacre, obsidian and caustics. The main button is rendered with React Skia.

The same invariant that governs the code surfaces in the typography. On the wallet screen, the euro balance is set large, preceded by an approximation sign. The exact USDC amount sits just below it, small. The local value depends on a daily exchange rate, so it says that it is approximate. The exact value, the one that will be signed and transferred, stays readable.The approximation marker is reserved for wallet surfaces. It never appears on an exact USDC amount.

A financial interface has to state what it knows and what it estimates.

What was hard in another way

Touching people’s real money scared me at first. That fear produced the rest: signatures verified twice, in the API and on-chain; CI guards on every amount; permit credentials wiped as soon as settlement confirms; non-custodial held end to end. I spent a lot of time on compliance, and I went to see a lawyer rather than guess.

That meeting produced two things. It confirmed that staying non-custodial end to end holds up: as long as the user keeps their keys and Spliz can never move funds on its own, the perimeter stays workable for one person. The red line has a name, and it is custody.

And it made me postpone a feature. I wanted idle balances to earn, and to pass 4% back to users through lending. Technically it is within reach. From a regulatory standpoint, paying a yield changes what the product is. I postponed the decision rather than take it on instinct.

What the field changed

The v1 works, so I go and show it. EthCC, where I put the product in front of the people it is for, not the people who find the idea nice. Paris Blockchain Week, a markedly more institutional room, with side events worth more than the talks. VivaTech. And École 42, where I pitch Spliz to more than a hundred and fifty people.

Reda Hamouche pitching Spliz on stage at École 42, facing a full room, with six screens of the settlement flow projected behind the stage
Frame 03 École 42, during the pitch.

Nobody talks about settlement. It works. What comes back is everything around it. A trip, a flatshare and a team do not have the same needs. People belong to ten or so groups. And in each one, the money is still managed individually.

There are more groups than there are people, and no bank treats the group as an object. Every person has an account; a group has a conversation and a spreadsheet.

Settlement covered the after. The before and the during are still open: a shared pot with its own rules, and a card that splits at the moment the group pays.A thesis nobody has contradicted in a room is not a tested thesis. You need the room.

Status

The Spliz product page on the App Store
Frame 04 The listing. Free, iPhone only, and the five screens the store shows first.

The contract runs on Base mainnet. The app is live on the App Store and on Google Play. The infrastructure is in production: hosting, edge, secret and key management, observability, analytics. 750 tests on the API, 810 on mobile.

Spliz launched in August 2026, and the first real settlements have gone through, among a small circle. It is a finished product before it is a working business: the work left in front of me is distribution work. The roadmap is public and the project is built in public.

What it proves

A complete financial product, from thesis to production, held by one person: product, mobile app, API, smart contract, infrastructure, compliance.

Nobody decided any of it for me, which is why the hard calls are the ones I can show you — where a signature stops being valid, where a rounding is allowed to drift, and which feature I postponed rather than take on instinct.

Next projectCase 002 / Work

Louvre.fr

Front-end developer, then lead · 2020 — 2025

louvre.fr5 min read