I build software end-to-end — from spec, to App Store, to support email.
I'm Mahesh — a Vancouver-based engineer. By day, release infrastructure for FortiClient at Fortinet — security software that ships to millions of macOS, Windows, and Linux endpoints. By night and weekends, TapNGame — a four-app sports platform I designed, shipped to the App Store and Google Play, and now run in production myself.
The short version, in my own words.
Not the LinkedIn paragraph. Not the recruiter blurb. What I'd actually tell you if you sat down across from me and asked: "so — what do you do?"
I'm a software engineer and a solo founder. By day, I'm at Fortinet — release infrastructure for FortiClient, which sits on millions of endpoints across macOS, Windows, and Linux. By night, I build TapNGame — four apps and one Postgres backend, live on iOS, Android, and the web. I designed it, shipped it, and I run it myself.
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.
I play badminton three nights a week. Booking a court was always the same friction — phone calls, screenshots of spreadsheets, dead WhatsApp threads. So I built the platform I wanted to use. Four apps — Flutter on iOS and Android, a Venue Manager OS, an admin console, and a Next.js marketing site — on one Supabase backend. Booking engine, payments, notifications, analytics, growth, venue operations, customer support. Solo, while working full-time at Fortinet. That part — that it's in the App Store and the Play Store, paying customers using it today — is the thing I'm most proud of.
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 read every App Store review. I answer my own support.
There's no substitute for being two clicks away from the people using your product. I watch real sessions. I reply to feedback. I sit with the friction. That's where the next feature comes from — not a strategy doc, not a Notion roadmap.
Every quarter, I learn one new thing — and ship something with it.
That's how Wi-Fi monitoring, MITM detection, RabbitMQ pipelines, and AI agent orchestration ended up on the resume — not because I read about them, but because I shipped real software using them. Knowing is cheap. Shipping is the bar.
What's actually open on my machine right now.
Live experiments, in-flight builds, and the next-quarter list. Not a public roadmap — just what I happen to be moving on this week.
TapNGame v2
AI-native release verifier
Booking engine, open-sourced
Pickup-game discovery agent
Operator analytics revamp
Identity & access automation
What I can ship with, grouped honestly.
Dark chips are the ones I reach for daily. Outline chips are tools I've shipped with in production at least once. Warm chips are areas I'm actively expanding. No keyword wall, no padding.
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.
Three nights a week, I'm on a badminton court. Long-distance running when the season allows. Daily strength training, because consistency matters more than intensity. 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 am the user.
“Same person at the keyboard and on the court. Show up, do the work, show up again tomorrow.”
— On work ethicIf 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.