Hey, I'm ZulkerNyne!
Math & CS student at UCalgary building backend systems, SaaS products, and full-stack apps that ship to real users. Currently leading software at AUV Calgary — building ROS2 architecture and Gazebo simulation for an autonomous underwater vehicle targeting RoboSub 2027.
Experience
Leading the software sub-team for a founding-year autonomous underwater vehicle team, building everything from scratch toward our first RoboSub 2027 competition entry. Designed the ROS2 architecture, set up the Gazebo simulation environment, and shipped the team's public website.
- Designed the ROS2 node architecture — auv_control (thrust), perception_mock (object markers), camera bridging, and TF tree
- Built the Gazebo simulation environment with custom Tethys AUV model, RoboSub 2025 world, forward + downward cameras, and RViz integration
- Shipped the team website — React + Vite SPA with team profiles, vehicle page, blog, docs, media gallery, sponsors, and judges hub
- Leading a 5-person software sub-team across simulation, perception, and controls
Building the production backend for a women's fitness centre booking system — Express + Prisma + PostgreSQL, replacing a 3,648-line localStorage prototype with a real server. Two portals (Community & School), four roles (member, student, trainer, admin), 13 Prisma models covering bookings, payments, memberships, credits, and audit logging.
- Credit ledger via SUM-delta pattern — no running balance to desync, atomic capacity enforcement
- Waitlist offer chain with 60-min reserve window, 4-day refund cutoff, FTR-XXXXX booking refs
- Stripe Checkout integration for drop-ins, memberships, and credit packs — all money in integer cents CAD
- JWT sessions via HttpOnly cookies, bcrypt 12-round hashing, Resend transactional email, audit log on all admin actions
- 9 route modules: auth, bookings, passes, schedule, roster, profile, admin, stripe, wave2
Built a SaaS sermon planning platform for mosque imams. Next.js + Prisma + PostgreSQL with session-based auth, role-based access, mosque invitations, and 18 API route groups covering sermons, themes, org management, admin, notifications, Stripe billing, and data export.
- Designed the 4-season × 16-slot annual plan model with elastic sub-bouquets — structurally coherent yet flexible per imam's needs
- Hijri occasion interleaving: Eid, Ramadan, and special sermons auto-placed by date into the correct seasonal block
- Cross-season spillover, dual-delivery Eid stacking, moon-sighting ±1 day tolerance
- Mosque invite system, multi-imam collaboration, Stripe subscription billing (Personal/Team/Institution tiers)
- Resend transactional email, rate limiting, structured logging, Prisma migrations
Built the Express + Prisma + PostgreSQL backend for a science-based addiction recovery education platform serving youth. JWT auth with silent refresh, role-based access (User/Admin), full admin CMS, automated email system, and a rule-based risk prediction engine.
- Recovery tools: private journal with mood/craving/stress tracking, HALT indicators, daily check-ins, recovery event logging
- Rule-based risk prediction — 7-day and 30-day trend aggregation, trigger frequency, risk scoring with suggested actions
- Full admin CMS: articles, courses with multi-lesson paths, videos, quizzes with scoring, resources, and 36-field homepage editor
- Email system: welcome, password reset, weekly recovery digest (personalized stats + new content), account deletion confirmation
- Account lockout after 5 failed logins, Helmet.js headers, rate limiting (10/15min auth, 100/min general), Zod validation on all inputs
A Muslim community matrimonial platform serving real users in production. React + Vite frontend on Vercel, Express 5 + Prisma + PostgreSQL on Railway, Redis for rate limiting, Cloudflare R2 for photo storage, and Socket.IO for real-time messaging. JWT auth built from the RFC — no Auth0, no shortcuts.
- Migrated live database from SQLite to PostgreSQL — zero data loss, zero downtime
- CSRF protection, request IDs, graceful shutdown, Redis-backed rate limiting
- Multi-photo profiles (4/user via R2), compatibility scoring, admin verification flow
- Real-time messaging with Socket.IO + Redis adapter, anti-spam enforcement
Tech Sketchbook 🎨
React
Next.js
TypeScript
JavaScript
Tailwind
HTML5 / CSS3
Node.js
Express
Python
C++
ROS2
Socket.IO
PostgreSQL
Redis
OpenCV
PyTorch
NumPy
Docker
Git
GitHub
Linux
NginxAbout Me 👋
I'm a Math & Computer Science student at the University of Calgary who builds backend systems and SaaS products that ship to real users. I care about the engineering underneath — not just whether it runs, but whether it's correct, maintainable, and ready to scale.
all 5 products are live in production — not localhost demos, not course assignments.Every project on this page is live and serving real users. My approach to auth, security, and data integrity is the same regardless of the project: JWT auth from scratch, rate-limited endpoints, Zod validation at the boundary, and Prisma schema modelling before writing a single query. These aren't features I add later — they're how I start.
Coming from pure mathematics, I think in systems and invariants. I ask why before I ask how. I've migrated a live production database without losing a single row, designed a 64-slot elastic data model for a SaaS sermon planner, built an atomic credit ledger and waitlist chain for a client gym booking system, and led a 5-person software team building ROS2 architecture from scratch — all as a student, all shipped, all live.
proof-first. then code. always.Security isn't a feature
I implement auth correctly regardless of what the app is. Refresh token rotation, rate-limited endpoints, input validation — these are engineering defaults, not decisions I make per-project. I read the RFC before I write the implementation.
no Auth0. no shortcuts. just understanding.Systems before syntax
Pure math trained me to model a system completely before touching the keyboard. Prisma schemas, credit ledgers, elastic data models — I architect for correctness first. I've migrated a live production schema mid-flight without data loss.
invariants first. implementation second.Internals over abstractions
I read docs and source code. I understand Stack Overflow answers before using them. Shipping to real users taught me what no textbook could — edge cases at 2am, schema gaps you only see under load, the difference between working and correct.
why before how. always.