A compliance product, built end to end.
AgeWallet verifies a visitor’s age without the site owner ever handling their identity documents. We built the platform, the website, the mobile app, and the rules engine that decides what the law requires wherever the visitor happens to be. It has since run checks for more than two million people.
AgeWallet is our own product. We are not describing work done for a client here — we built and run it. It is on this page because building a verification platform, a mobile app and a multi-jurisdiction rules engine is a fair demonstration of what the team can do.
Four pieces, one product.
Each one is a different discipline, and all four had to agree with each other.
The website
The marketing site, the developer documentation and the whole public face of the product. The documentation is a structured multi-page system rather than a single long page, because integration docs are read in pieces by people solving one problem at a time.
The verification platform
The product itself: age estimation and ID verification, tokenized so an operator never handles the underlying identity data. Built on standard OpenID Connect, so it drops into the stack a site already runs.
The mobile app
A companion app so a person verifies once rather than repeating the process at every site they visit. Native app work, published on the Apple App Store and Google Play.
The legal matrix
A rules engine that works out which regulation applies to a given visitor and what that regulation requires, then adjusts what the platform asks of them. This is the part that makes the product work outside one country.
- JavaScript drop-in
- JavaScript SDK
- WordPress & WooCommerce plugin
- Telegram bot
- PHP (single file)
- PHP SDK
- iOS SDK
- Android SDK
- Flutter SDK
- React Native SDK
- Ionic SDK
The rule is different everywhere.
Age verification looks like one problem until you sell across borders. What counts as a minor, what proof is acceptable, what an operator is allowed to store and for how long: all of it changes by country, by regulation, and by the kind of content behind the gate.
Hard-coding any of that guarantees the product is wrong somewhere, and wrong again the next time a rule changes. So the requirements live in a matrix rather than in the code. The platform resolves the visitor’s location, looks up what applies there, and adjusts what it asks for.
When a regulation changes, the matrix changes. Nobody ships a release to keep an operator compliant in one market.
- 1Where is this visitor?Location resolved at the point of the check
- 2What applies there?Matrix returns the governing rules for that market and vertical
- 3What does it require?Acceptable method, threshold and retention for that rule
- 4Ask for exactly thatNothing more is collected than the rule calls for
Rules live in the matrix, not the code, so a change is data rather than a release.
- COPPA
- GDPR
- CCPA
- KJM
The platform is designed for SOC 2 and ISO 27001 as well. Those are standards the product is built toward, not certificates held today.
What visitors and operators see.
The visitor sees a gate that matches the site they are on. The operator sees what happened. Neither sees the visitor’s identity documents. And the developer wiring it up has documentation for every route in.
Verify once, on iPhone or Android.
Without the app, a person verifies separately on every site that asks. With it, they verify once and scan the QR code a participating site shows them. The site gets its answer without ever seeing who they are.
Shipping it meant two native builds, two store review processes, and keeping both in step with the platform behind them.
Most of this was not a website.
A marketing site is a fraction of this project. The rest is a verification platform, a native mobile app, 11 integration methods across web, server and mobile, a plugin written against someone else’s ecosystem, and a rules engine that has to be right in markets nobody on the team lives in.
That is the reason it sits in this portfolio. If your project is closer to software than to a brochure — an application flow, a system that has to connect to something you already run, a product rather than a page — this is the kind of work it looks like.
- Product and platform development
- Native mobile apps for iOS and Android
- Multi-jurisdiction rules engine
- Developer documentation
- 11 SDKs and integration methods
- WordPress and WooCommerce plugin
- Client dashboard and usage billing
- Marketing site and brand
Building something closer to software?
Tell us what it has to do, what it has to connect to, and who has to sign off on it. We will tell you plainly whether we are the right team.