Who am I?
I started writing code at seventeen because broken things bothered me more than broken grades. This is where that took me — and what I want to build here with you.
I'm Meet. I started writing code at seventeen, in high school, in Jaipur. Nobody handed me a curriculum — I just couldn't stand things that were broken and left that way. Broken systems bothered me more than broken grades. That sentence was true then, and if you read this blog for a while, you'll see it's still the engine behind everything I do.
Since this is my first post, let me do the polite thing and introduce myself properly: where I've worked, what I actually built there, and why I've started writing.
Seventeen#
School gives you problems that are already solved and asks you to reproduce the answer. Code gave me problems that were genuinely open and asked me what I was going to do about them. For a teenager who found half-finished, badly built things almost physically irritating, that trade was irresistible.
What hooked me wasn't the syntax. It was the honesty of the feedback loop: you can see whether a system is right. It handles the edge case or it doesn't. It survives load or it falls over. No partial credit. I liked that there was no partial credit.
The path, drawn out#
I think careers make more sense as diagrams than as paragraphs — you'll notice that habit everywhere on this site — so here's mine.
Quranium was my first room: a DeFi engineering internship on next-generation quantum-secure distributed ledger infrastructure. I built an MVP decentralized exchange on Uniswap with multi-signature wallet controls — a 2-of-N multisig that went on to become the custody foundation the platform scaled to production — and landed four merged pull requests into the FairFund open-source platform along the way. That internship taught me my first real lesson about money software: "it works on my machine" is not a sentence you get to say about custody.
MetaKeep was where the stakes got real for me. As a full stack engineer on a wallet platform, I built payment infrastructure that shipped during MetaKeep's acquisition by Rezolve AI (Nasdaq: RZLV) in March 2026 — a sign-up-free transaction flow inside a chatbot UI for luxury retail, built on the Reown Wallet Mobile Kit and the MetaKeep SDK. I owned pre-production testing for Wallet Isolation, an enterprise security feature Solana asked for, enforcing per-app key segregation — that ownership cut pre-production bugs by 40%. I took the crypto onramp from zero to production in TypeScript: Coinbase API integration, a fiat-to-token rail chaining card purchases into MetaKeep wallets, and an on-chain USDC transfer system using SPL token delegation so you never approve the same thing twice. When production broke, I traced it across the codebase and shipped the fix end-to-end, no handoffs. Knowing that acquisition due diligence would read my code sharpened it more than any review ever has.
Ones Finance is my current room, and the deepest backend work I've done. As lead backend engineer I've designed and shipped around ninety REST API endpoints in Go across business and admin account systems — onboarding, payments, treasury, invoicing, cards, approval workflows — every one of them tested and documented. The part I'm proudest of is the transaction pipeline: idempotent and optimistic-accept, with request validation, risk assessment, and fund reservation up front, and settlement handled asynchronously so a payment answers you in under 600 milliseconds without ever blocking on an external confirmation.
What I want to draw for you#
That pipeline is a good example of why this blog exists, so let me show you what I mean instead of telling you.
You've probably read a hundred posts that say "the service scales horizontally" and left none the wiser. I've read them too. But every system I've ever managed to build well became buildable the moment I drew the right picture of it — and I don't think I'm special in that.
So that's why I write: I want to share what production has taught me so you can take these methods — idempotency, optimistic accepts, custody boundaries, rate limits, reconciliation — and apply them on your own engineering path. If a concept can't survive being drawn as boxes and arrows, I don't understand it well enough to publish it. That's the bar I'm holding myself to here.
I'm Meet Jain. I build payment systems for a living, and I'm glad you're here. Let's draw some systems together.