I build software end-to-end — from blank page to live product.
I'm Mahesh — a Vancouver-based engineer. I work on release infrastructure for FortiClient at Fortinet, endpoint security trusted on millions of machines worldwide. I also founded TapNGame — a sports booking platform live on the App Store, Google Play, and the web.
Who I am, plainly put.
The version I'd give if you asked over coffee — what I do, what I've built, and what I'm looking to do next.
I'm a software engineer based in Vancouver. At Fortinet, I work on release infrastructure for FortiClient — the endpoint security product running on millions of macOS, Windows, and Linux machines worldwide. I also founded TapNGame, a sports booking platform live on iOS, Android, and the web — designed, shipped, and operated independently.
The throughline is the same in both: I take software all the way. I don't stop at the diff. I write the spec, build the system, ship the binary, watch the metric, read the support email, and write the patch. The hard part of software was never the code — it's the thousand small decisions between an idea and a user actually getting what they came for. That's the part I like most.
I move across mobile, web, backend, infrastructure, and ML — not because I'm chasing breadth, but because real problems don't respect stack boundaries. The bugs that take down production live at the seams nobody owns. I learn both sides so I can fix them, instead of throwing them over the wall.
How I got here, told over coffee.
The honest version. Six chapters, in order, each one teaching me the part the next one needed. Resumes lose this. I'd rather you have it.
I was the kid taking the family computer apart.
Before I knew the word "engineer," I knew the feeling — wanting to know how the thing in front of me worked, then making it do something it wasn't built to do. School computers, the family PC, the neighbour's modem. Nobody asked me to fix it. I just wanted to.
I learned to actually build things.
The classes I cared about most weren't the most popular ones — networking, simulation, basic ML, and computer vision. I wanted to build the kinds of systems that already ran the world: how packets actually got from A to B, how a model learned to tell things apart, how databases held everything together. That curiosity is still the thing.
Running SAP for 150 enterprises.
My first production job. I supported global clients — GM, IKEA, Philips, Apple, HP, Microsoft, Dell. Transport Management System administration, kernel upgrades, RFC connections, client administration, Rev-trac, Oracle tablespace management. I learned, fast, that a backend decision I made at 11 p.m. could ruin someone's payroll the next morning. That stuck. I take production work seriously because someone is on the other side of it.
Master's at Lakehead — networking, security, ML.
My thesis was ML-based detection of client-side MITM attacks using anomaly methods. Around it: 802.11n/ac Wi-Fi monitoring with Kismet, vehicle detection comparing HOG+SVM against YOLO, and a team-led project on black-hole attack detection in MANETs using ns-3. Two years of getting comfortable at the seam between networks and learning systems — and getting comfortable with the idea that I might know more than the textbook.
Fortinet — where I learned to ship at scale.
Test automation and release infrastructure for FortiClient — endpoint security on millions of macOS, Windows, and Linux machines. Python and Selenium automation, Jenkins CI/CD, RabbitMQ test orchestration, code coverage and static analysis. I work across VPN SSL, IPsec, ZTNA, SAML, antivirus, web filter, and application firewall — partnering with FortiClient, FortiGate, EMS, and FortiAuthenticator teams. A bad release here breaks security on someone's laptop. So we don't do bad releases. That discipline is the thing I take home with me every night.
TapNGame — the thing I wished existed, so I built it.
Booking a court in Vancouver was always the same friction — phone calls, screenshots of spreadsheets, dead WhatsApp threads. The systems that did exist were built for the venue, not for the player. So I built the one I wanted to use. A consumer app for finding courts and pickup games. A venue operations product for owners to manage their bookings, staff, and pricing. An admin console for the platform side. A marketing site that brings new players in. Payments, notifications, customer support, growth instrumentation — every layer a real product needs. Designed it, shipped it to the App Store and Google Play, and operate it today, with paying customers.
LIVEI built the booking and pickup-game platform I wanted to use.
TapNGame isn't a side project. It's a four-app product I designed, shipped, and run. Live across Metro Vancouver on iOS and Android: badminton, tennis, basketball, pickleball, volleyball, indoor soccer. Below: the actual problems it solves, and the engineering that makes the solutions hold up.
One product. Four surfaces. One backend keeping them in sync.
Players use a Flutter app on iOS and Android. Venue staff use a Next.js Venue Manager OS in the browser. The platform team uses an internal admin console. The marketing site at tapngame.com brings new users in. All four surfaces share one Supabase / PostgreSQL backend — same data, same auth, same rules, no sync hell.
I designed and built every layer of it. The schema, the RPCs, the realtime subscriptions, the booking engine, the payments architecture, the notification engine, the operator analytics, the Flutter UI, the App Store and Play Store listings, the support workflow. Solo. While working full-time.
What it actually does — in plain language.
Booking a court used to mean phone calls, screenshots of spreadsheets, or dead group chats.
A 30-second flow on your phone, with live slot data straight from the venue. Lock-on-tap holds your slot while you check out. Apple Pay and Google Pay just work.
Two players tap the same slot at the same time. Most booking systems double-book.
Row-level FOR UPDATE locks, capacity-aware decrements for drop-ins, and idempotent restore-on-cancel triggers. One tap wins. The other gets a clear "taken" state — and a heads-up on the next available time.
Payments either succeed quietly or orphan — and refund fights ruin a venue's week.
PaymentIntent-first Stripe architecture with idempotent webhook handling and server-side price validation. Money in matches money out, every time. Refunds, disputes, memberships, orphan-payment recovery, all covered.
Pickup games live inside private WhatsApp threads. You either know someone, or you don't play.
Find a 7 p.m. badminton game near you, see who's already in, join. Waitlists auto-promote when someone drops. Host SLA timers keep games moving instead of ghosting.
Sports apps either spam your phone or miss the only message that mattered.
Outbox-driven engine with per-user-timezone quiet hours, multi-device dedup, and APNs collapse-ID idempotency. The right nudge, in the right hour, exactly once.
Most venues run on a clipboard, a spreadsheet, and three group chats. Nothing reconciles.
A full Venue Manager OS — calendar, bookings, courts, pricing, memberships, leagues, tournaments, coupons, financials, staff, ticket scanning, customer support. Everything an operator needs in one place.
Operators couldn't see what was actually happening with their business.
Operator-grade analytics — revenue trends, day-of-week mixes, new-vs-returning cohorts, court revenue, booking heatmaps, coupon analytics. Numbers an owner can act on, not vanity charts.
In a marketplace with money in it, one bad release can break trust permanently.
End-to-end test coverage across unit, integration, security, and contract tests, on GitHub Actions, Docker, Vercel, and Edge Functions. A custom pre-commit DB lint catches CHECK/ENUM contract violations before they reach production.
What it's actually like to build with me.
Eight things I'd want a hiring manager to know up front — about how I work, how I debug, how I treat users, and where I think the bar should be. Written in my voice. Not optimized for keywords.
I don't stop at the diff.
Writing the code is the easy part. The job is everything after — does the user get what they came for? does the metric move? did the support ticket stop coming in? I stay until that's true. Most engineers stop at the PR. I stay through deploy, watch, and follow-up.
I just show up — every day.
A lot of days don't feel productive. That's fine. What matters is that I was at the keyboard, and I moved one specific problem forward. A year of that beats a month of heroics. The compounding is the whole point.
I want to see the bug with my own eyes first.
Half of bad fixes change the wrong thing because nobody actually reproduced the bug. I reproduce it, find the exact seam where it broke, change only what the evidence demands — and then I write the test that should have caught it. So it can't happen again.
I get the data right before the screen gets pretty.
Data model. Concurrency. Failure modes. Contracts. I work those out first. Surfaces are easy to change. The system underneath isn't. Most teams discover this in production — usually around the time their first refund fight goes public.
Most production bugs live where two systems meet.
Mobile-to-backend. Web-to-payments. Infra-to-product. The hardest bugs sit at the seams nobody owns. I learn both sides on purpose, so when something breaks at the boundary I can actually fix it — instead of throwing it over the wall and hoping.
I use AI to type faster. I still make the calls.
Cursor and Claude Code help me draft, refactor, plan, and verify. They do not decide what to build, what to keep, or what's good. That part still comes from me — and the more leverage AI gives me, the more those judgement calls matter, not less.
I take feedback as data, not noise.
Reviews, support replies, session recordings, the message a friend sends me at 9 p.m. — I treat all of it as signal. The next thing to build is almost always already in there. The trap is filtering for what flatters; the work is staying with what frustrates.
I learn by building, not reading.
I pick up a new tool the same way every time — pick a real problem, build the thing, ship it, then go back and learn what I skipped. Wi-Fi forensics, intrusion detection, agent orchestration, payment systems — they got real because I had to make something work with them, not because I read about them.
What I can ship with, grouped honestly.
Things I actually ship with — no keyword wall, no padding. Solid chips are the daily drivers; warm chips are what I'm actively expanding.
Languages I think in
Daily. Production. Not just resumé chips.
Mobile & web
From greenfield to App Store / Play Store delivery, end to end.
Backend, data & concurrency
Where most production systems quietly succeed or fail.
Testing & release automation
Shipping with confidence across millions of endpoints.
DevOps & infrastructure
From CI/CD to cron workers to managing the deploy myself.
AI-native engineering
Not as a buzzword — as a real shift in how I ship.
Security & networking
From FortiClient release work to networking research and intrusion detection.
Product & operations
The things you only learn by being the founder, too.
The practice behind the work.
TapNGame didn't come from nowhere. It came from the fact that I'm the user — and the friction in the way of staying active in a busy city is something I personally felt.
Badminton is the one I keep coming back to. Long runs through the season. Steady strength work in between. Hiking when the weekend opens up. I'm generally suspicious of anything that promises the short way around.
This isn't decoration — it's the reason TapNGame exists. I know exactly what it feels like to want to play, and have the friction of an old booking system or a dead WhatsApp thread get in the way. The product is the way it is because I'm the user.
“The discipline doesn't change when I close the laptop.”
— On work ethic
If you're building something that needs ownership, let's talk.
I'm looking at product engineering, full-stack, AI-native software work, and backend / systems-heavy roles. The strongest fits are founder or early-team engineering, modern product teams, and any role where shipping ability and breadth count more than rigid job boundaries.