End user first, always
Every feature starts with: "what does this change for the person with an entry-level Android and 2GB of data?" If the answer is "nothing good", we don't ship it.
Engineering · quality & open source
Squadmint is built with the end user at the centre of every decision. That shows up in two places you can actually verify: tests that run on every commit, and source code we publish for anyone to read. This page is the engineering promise, and where to check we're keeping it.
Our goal is to be as transparent as possible. The smart contracts that hold pocket money already are, they're on GitHub, anyone can read them, audit them, or fork/copy them. The mobile app is next: we're preparing it to be published under the same terms. If you're moving money through Squadmint, you should be allowed to see exactly how.
The on-chain smart contract that governs Squadmint pockets, who can propose a withdrawal, how votes are tallied, how funds are released, lives in a public repository. No hidden logic, no private builds. What you see on-chain is what's in the repo.
The mobile app will follow. We're finishing the cleanup work you'd expect before a public release: removing internal keys, documenting the build, writing a contributor guide. Watch the org.
Every line of code that touches your money runs through an automated test suite before it reaches your phone. If a test fails, the build stops. If a build stops, the release waits. That's the only way we know how to move real money safely.
The services that mint, move and reconcile balances are covered by unit tests. New behaviour doesn't land without a corresponding test. Pull requests that touch money code get two sets of eyes before they're merged.
The mobile app has its own suite, reducers, payment validation, form flows. Anything that can silently corrupt state has a test to prove it can't. Snapshot tests lock the visual contract so a surprise style change flags itself at code review.
The multisig contract is exercised end-to-end in a local validator before any deployment. Thresholds, vote counting, membership changes, and replay protection are each covered. The repo's green check on GitHub Actions isn't decorative.
The app is engineered for the devices most of our users actually carry, mid-range Android, older iPhones, uneven data. We budget for 60fps on the home screen, sub-second render on lists, and skeleton states everywhere loading might be visible. Beauty is a function of respect for the user's time.
Six commitments we argue in favour of during code review. They're not marketing slogans, they're the arguments that win or lose a pull request.
Every feature starts with: "what does this change for the person with an entry-level Android and 2GB of data?" If the answer is "nothing good", we don't ship it.
We ship the smallest thing that solves the problem. Features earn their place; code earns its lines. Removing code is a success, not a loss.
Gang of Four design patterns, clean architecture, separation of concerns. We use the boring, proven ideas, because boring doesn't wake you up at 3am.
Every code path that touches a balance is covered by automated tests. A failing test blocks a release. That rule has no exceptions.
An app that looks sharp isn't a designer's vanity, it's a signal the team cares about details. Pixel alignment, loading states, empty states, error copy. All of it.
Where we can publish, we publish. Where we can't yet, we say why. When we fix a bug in production, we tell you what it was and when it shipped.
For the curious. Specific choices change over time; the shape doesn't.