I’m Sri. I build software that doesn’t fall over.
Five years inside TD Bank and DBS shipping Java that handles regulated money. Now independent, helping startups and scale-ups build AI products with the same discipline. One engineer, no agency layer, no offshore handoff. If you’ve been burned by consultants before, the difference is that I’m the one writing the code.
The short version
Banking-grade rigour, startup velocity
I started as a Java engineer at DBS in 2019. I learned what idempotency really means when a bug in your code can move someone’s salary into the wrong account. I learned that observability is a Phase 1 deliverable, not a Phase 4 nice-to-have. I learned that "boring" technology choices, Postgres, Spring Boot, AWS, scale absurdly when you architect them right.
I left the bank in 2024 because the cycle time was incompatible with how I wanted to think. Independent work compresses feedback loops, you architect on Tuesday, you ship on Friday. The rigour stays. The bureaucracy doesn’t.
Today I work mostly with fintech and B2B SaaS teams who need to ship AI features without breaking the parts of the system that already work. I bring deep Java and Spring Boot experience and 18 months of production AI work.
Sri Vardhan
Independent Java + AI engineer · SF Bay Area · PST
What I’ve built
A few systems I’ve been responsible for
The detailed write-ups live in /work, anonymised under NDA. Here’s the shape of the thing so you know whether my reps match your problem.
Real-time payments rails at TD Bank
Spring Boot 3 services moving 8-figure daily volume. Idempotent Kafka consumers, exactly-once semantics, full audit trails. The kind of code where a bug means a phone call from compliance.
Trade reconciliation engine at DBS
Replaced a 200k-line legacy batch system with a streaming pipeline. Cut nightly reconciliation from 4 hours to 11 minutes, and made it easier to extend.
AI customer-support stack for a Series A SaaS
RAG over 4 years of support tickets and product docs. Deflects ~38% of tier-1 queries. Built the eval harness first so the team knows when it regresses.
Fintech MVP, idea to first paying user in 6 weeks
Next.js, Postgres, Stripe, three Spring Boot services for the regulated parts. Shipped, then iterated. Now it does mid-7-figure GMV.
Why solo
No agency, no offshore, no surprises
The agency model breaks because the person who sells you the project is rarely the person who ships it. Communication degrades, decisions get made in meetings you’re not in, and accountability dilutes through three layers of project management.
The offshore-development-shop model breaks for the same reason with extra time-zone friction. You get cheaper hours, you spend the savings on Slack threads at midnight.
I picked solo because the work I’m best at, banking-grade architecture for teams that need to ship fast, doesn’t scale well with subcontractors. The conversations I have with founders are technical, sometimes uncomfortable, often opinionated. That only works when the engineer in the call is the engineer in the code.
When the work genuinely needs more hands, I bring in trusted collaborators on day rates with full transparency. You always know who’s touching your code.
I wrote a longer version of this on /insights, including the parts I got wrong in my first six months independent. Read what I actually learned leaving the bank.
How I work
Six principles I won’t compromise on
These aren’t aspirational values. They’re how every engagement actually runs. If any of them sound like a bad fit, we’re probably not a good match, and that’s fine.
Scope before code
I write the brief before I write the first line. If we can’t agree on the brief in a week, the project will fail and I’d rather find out cheaply.
Boring tech, sharp design
Postgres until it hurts. Spring Boot for the regulated parts. The novelty lives in the architecture, not the dependency tree.
Observability is a Phase 1 deliverable
Traces, dashboards, alerts on day one. I learned this the hard way at the bank, you don’t bolt it on later, you build the system around it.
Tests where they earn their keep
Heavy on integration tests for money flows, light on unit tests for plumbing. I don’t test the framework. I test the parts that’ll bite us.
Ship weekly, not at the end
Production deploys from week two. You see the thing running, you give feedback while it’s still cheap to change.
Documented handover, always
Runbooks, ADRs, a recorded walkthrough. The day I leave, your team can run it without me. That’s the deal.
The path
From bank cubicle to solo studio
I keep this short on purpose. The detailed version is on /insights.
Joined DBS, Singapore
Came in as a Java engineer. Spent two and a half years on trade systems, learning what regulated software actually means.
Moved to TD Bank, Toronto
Two years on payments. Spring Boot 3, Kafka, AWS, the works. Got comfortable with code that runs on people’s salaries.
Went independent
Wrote about it on /insights/what-i-actually-learned-leaving-the-bank. Short version, the work I wanted to do had a faster cycle time outside.
Solo studio, by design
14 case studies, 50+ posts, no employees, no agency layer. One engineer accountable for the outcome. That’s the model.
Honest limits
What I won’t take on
Pure mobile apps. I’ll architect the backend and the API, but I haven’t shipped a Swift or Kotlin app in production and I’m not going to pretend otherwise. I’ll happily refer you.
Greenfield rewrites of working monoliths. If your monolith works and the case for replacing it is "the team wants to learn a new framework," I’ll politely push back. The strangler fig pattern almost always wins on cost and risk.
Crypto, gambling, ad-tech tracking. Personal preference. Plenty of excellent engineers work in those spaces. I’m not one of them.
More than 2 projects at a time. I cap concurrency on purpose. The quality drops past two and I’d rather have a waitlist than a half-attentive engagement.
That’s the long version. Want the short one?
Book a 30-minute call. I’ll ask four questions and you’ll know if we should work together. No slide deck, no pitch.