How these systems were built

Context

Operations staff at a large healthcare organization used to decide service eligibility by phone calls and tribal knowledge—drive time, specialty, and facility availability lived in people’s heads. I was brought in as the sole full-stack engineer: I wrote the React 19 TypeScript SPA (8,000+ lines across search, eligibility, and scheduling), the Python Lambda backend split by domain, and the CI/CD that deploys containerized Lambdas plus a static frontend to AWS.

The problem

There was no engineering bench behind me. The tool had to meet WCAG AA, keep sensitive identifiers out of URLs, talk to upstream identity and facilities services over mTLS, and ship in a regulated cloud environment—while one person owned frontend, backend, and DevOps.

How it was built

I started with a four-tier local stack so I could ship without live production data: an Express mock server (~700 LOC), a Flask Lambda shim (~350 LOC), LocalStack for AWS services, and oauth2-proxy/Dex for OIDC. That let me develop the reactive eligibility view (1,400+ lines), a custom WAI-ARIA listbox combobox, and POST-based search that never puts sensitive fields in query strings.

On AWS, Lambdas are container images split by domain—patient lookup via mTLS, eligibility against the facilities API with DynamoDB caching, care specialty mappings, and scheduling preferences. An OpenAPI 3 contract drives API Gateway. A Python build script turns operational spreadsheets into validated JSON config so UI defaults stay synchronized with business rules. GitHub Actions builds to ECR; the SPA ships as nginx static assets on ECS.

Architecture decisions

• Domain-split Lambdas instead of one mega-handler—clearer blast radius and independent deploys
• POST for search so identifiers never appear in access logs via query strings
• Spreadsheet → JSON config pipeline with fail-fast integrity checks
• Synthetic mock personas for training without real patient data
• SigV4 AWS proxy in local dev so the SPA talks to real auth shapes without production credentials

Stack

• Frontend: React 19, TypeScript 4.9, SCSS design tokens (Style Dictionary), Jest + React Testing Library
• Backend: Python AWS Lambda (container images), DynamoDB, API Gateway, Secrets Manager
• Local: Express mock, Flask shim, LocalStack, oauth2-proxy/Dex
• Ops: Docker, ECS + nginx, GitHub Actions → ECR, OpenAPI 3 + pytest contract tests

What was built end-to-end

Every item below was designed, implemented, and tested across the full stack—no separate frontend or backend owners on this program.

• Record search & identity resolution — multi-criteria search with isolated sensitive-identifier fields, sortable results, hierarchical address sorting, batch pagination, status badges (1,100+ lines of UI logic).
• Reactive eligibility engine — 1,400+ line view computing results as users select service type, sub-service, specialty, and facility with spreadsheet-driven proximity thresholds.
• Service configuration pipeline — Python build script ingesting operational spreadsheets into validated JSON with fail-fast integrity checks.
• Scheduling preference persistence — DynamoDB composite-key Lambda, CloudFormation table, frontend service layer, OpenAPI docs, mock-server parity.
• WCAG AA accessibility — WAI-ARIA listbox with roving tabindex, aria-activedescendant, typeahead, focus return, and screen-reader status toasts.
• Security — POST bodies for lookups, client-certificate upstream auth, masked logging, Secrets Manager in Lambda handlers.

What shipped

Production platform with merge-triggered deploys, WCAG AA remediation, mTLS upstream integration, and a pytest suite covering transport errors and 4xx/5xx paths—delivered end-to-end by one engineer.

Lessons

When you are the only engineer, local fidelity matters more than clever abstractions. The mock stack paid for itself every week. Accessibility was not a polish pass—it was a design constraint from day one, especially for the combobox that ops staff live in.

More context on the homepage · Contact

Context

DAS4 moves enterprise XML (and related clinical payloads) through Step Functions, API Gateway, DynamoDB, and S3 at VA scale. I was the primary application-layer engineer on the Node.js Lambda monorepo—InboundProxy (Express 5, AWS SDK v3, XML parsing, rate limiting), OutboundProxy, Chargeback, VendorValidation, XMLSchemaValidator, and VBMS client modules—with Jest mocks and Pact contracts on the proxy layer.

The problem

Enterprise XML pipelines fail quietly. Malformed schemas, rate-limit breaches, and chargeback mismatches often surface days later downstream. The monorepo had dozens of IaC modules with their own handler contracts; local debugging meant mocking S3, DynamoDB, SSM, and Secrets Manager consistently—or guessing in CloudWatch after the fact.

How it was built

I focused on InboundProxy reliability: Express middleware for XML validation, structured error responses aligned with master dataflow specs, and VSCode launch configs so handlers could be stepped through locally. Extended Jest coverage with aws-sdk-client-mock, restored Pact CI coverage on the proxy boundary, and fixed pipeline issues that were blocking Lambda deploys.

Work also touched SOAP client + transformer + result-processor paths, injection/upload stream hardening, and service decomposition so chargeback and vendor validation stayed isolated from the hot ingestion path. Adjacent lanes on the broader program included FHIR/HL7 exchange, malware quarantine, and cost-attribution analytics—context that shaped how carefully we treated payload integrity.

Architecture decisions

• Validate early in the inbound proxy—reject bad XML before it fans into Step Functions
• Contract tests (Pact) at the proxy boundary so consumers and producers stay honest
• Local handler debug as a first-class path, not an afterthought
• Keep chargeback / vendor validation as separate modules from core ingest

Stack

• Node.js Lambdas, Express 5 InboundProxy, AWS SDK v3
• Step Functions, API Gateway, DynamoDB, S3 + KMS, ECS Fargate mTLS proxies
• MongoDB manifests, Python XSD validation, Java SOAP clients, Glue ETL
• Jest + aws-sdk-client-mock, Pact contract tests, CI/CD for Lambda deploys

Modules owned or heavily touched

• InboundProxy — Express 5 middleware, XML validation, rate limiting, structured errors
• OutboundProxy — egress paths with mTLS proxy considerations on Fargate
• Chargeback & VendorValidation — isolated from the hot ingest path
• XMLSchemaValidator — early reject of malformed payloads
• VBMS client — SOAP client, transformer, and result-processor Lambda paths

What shipped

Hardened application-layer Lambdas in a large enterprise monorepo—better test coverage on critical ingestion paths, restored Pact CI, working local debug workflows, and pipeline fixes that unblocked continuous delivery for the integration team.

Lessons

In a platform this size you do not “own the architecture”—you own reliability on the paths you touch. Making failure loud (validation, contracts, local repro) beats adding more features on a quiet broken pipe.

More context on the homepage · Contact

Context

Quest Innovation needed a hospitality platform that multiple restaurant brands could run without sharing each other’s data—while the operator still needed cross-tenant sales and review reporting. I designed and developed it end-to-end (my name sits in the admin portal header). Three PHP applications share a MySQL database (quest_restaurant): restaurant admin, super-admin, and vendor workflows, with mPDF 7.x generating the PDFs back-office teams print.

The problem

Each brand needs isolated menus, staff assignments, loyalty points, tables, and orders. The platform operator needs today’s sales, reviews-by-date, and exportable reports. Session-scoped tenant IDs must never leak across restaurants—a classic multi-tenant footgun in PHP apps that grew from single-tenant roots.

How it was built

Session auth binds every request to a per-restaurant admin ID. Floor staff use AJAX-driven table-manager workflows; loyalty points attach to customer visits; each tenant carries its own branding assets. Super-admin reads across tenants for oversight without writing into brand-scoped operational tables incorrectly.

Reporting is a shared concern: both admin and super-admin pipes go through Composer-managed mPDF 7.x so invoice-style and ops exports look consistent. That PDF pattern later became the template for Quest’s stock app—one reporting idiom across products.

Architecture decisions

• Three app surfaces, one schema—clear role boundaries without premature microservices
• Session-scoped tenant keys checked on every mutating path
• Shared mPDF pipelines so finance and ops see one document language
• AJAX table manager for low-friction floor use during service

Stack

• PHP applications with MySQL (quest_restaurant) multi-tenant data model
• Restaurant admin: tables, menus, orders, reward points
• Super-admin: cross-tenant sales and reviews-by-date reports
• Vendor workflows; Composer; mPDF 7.x operational exports

What shipped

Production SaaS structure supporting day-to-day restaurant operations for Quest clients—table management, loyalty tracking, and PDF reporting that back-office teams actually use.

Lessons

Multi-tenancy is a discipline, not a feature flag. Naming tenants in session state and refusing cross-tenant writes by default kept the product simple enough for restaurant staff while still giving operators the overview they need.

More context on the homepage · Contact

Context

Warehouse supervisors at Quest Innovation clients were closing months in spreadsheets that broke under filter chaos and copy-paste errors. I built a stock management app in PHP on MySQL (quest_stock) with session-gated login, a Bootstrap operational UI, air-datepicker / datetimepicker tooling, and mPDF 7.x exports—the same reporting conventions as the restaurant SaaS.

The problem

Inventory teams need reliable on-hand visibility, date-filtered views for audit windows, and printable summaries finance will accept—without buying an ERP seat license for every supervisor.

How it was built

PHP modules cover inventory CRUD and a home dashboard gated by $_SESSION['loggedin']. Date tooling lives under a _dev asset folder for operational filters. mPDF pipelines mirror the restaurant product so staff already know how exports behave.

Author metadata in the HTML head credits the build directly—small detail, but it made ownership obvious inside Quest’s PHP portfolio when multiple apps shared patterns.

Architecture decisions

• Reuse restaurant PDF conventions instead of inventing a second report style
• Session auth first—warehouse staff needed speed, not OAuth ceremony
• Date-filtered views aimed at month-end audit, not vanity dashboards

Stack

• PHP + MySQL (quest_stock)
• Bootstrap UI with air-datepicker / datetimepicker
• Session authentication; inventory CRUD modules
• mPDF 7.x printable inventory summaries

What shipped

Practical warehouse tooling with printable PDF outputs for supervisors and finance review—part of Quest Innovation’s PHP product line.

Lessons

Replacing spreadsheets succeeds when the first export looks like something finance already trusts. Matching mPDF patterns across Quest apps reduced training and support load.

More context on the homepage · Contact

Context

EOI Digital needed a property sales platform for expressions of interest. At Octalogic I delivered both sides: a Laravel 7 API (Passport OAuth2, Cashier, Telescope, AWS S3 flysystem, OpenAPI via vyuldashev/laravel-openapi) and a React 16 CRA frontend (Material-UI, Redux + Redux-Saga, Formik/Yup, React-PDF, PayPal). Work was tracked on the Octalogic REE JIRA board.

The problem

Property sales span brokers, buyers, units, and EOI submissions—each with different permissions and document needs. The frontend had to stay maintainable: Layout → Container → Page → Component with BEM SCSS, not a tangle of one-off screens.

How it was built

Laravel routes sit behind auth:api and email-verification middleware for projects, brokers, buyers, units, and EOI endpoints. MySQL migrations and seed data include an admin persona for demos. Telescope and PHPUnit support day-to-day debugging and regression checks; Docker-ready Laravel docs made onboarding predictable.

On the React side, Redux-mapped containers encode user stories, Material-UI theming keeps the front office consistent, and @react-pdf/renderer generates sales documents client-side so brokers are not waiting on a separate doc service for every draft.

Architecture decisions

• Passport OAuth2 as the single gate for SPA ↔ API
• Strict FE hierarchy (Layout/Container/Page/Component) + BEM SCSS modules
• Client-side React-PDF for sales artifacts where latency matters
• OpenAPI generation so contract and implementation stay aligned

Stack

• Laravel 7, Passport, Cashier, Telescope, S3 flysystem, OpenAPI, PHPUnit, MySQL
• React 16 CRA, Material-UI, Redux + Redux-Saga, Formik/Yup
• React-PDF sales documents, PayPal checkout integration
• Docker-ready Laravel setup documented in-repo

What shipped

Full-stack real-estate tooling—front-office UX for buyers and brokers plus API-backed property and EOI management with OAuth-secured access.

Lessons

EOI workflows are permission puzzles. Getting the middleware and container mapping right early saved more time than any UI flourish. The same React/Laravel pattern later echoed in AYL Shop delivery.

More context on the homepage · Contact

Context

NMMC is a municipal civic portal I built at Octalogic: Express 4 with EJS admin pages, Mongoose 5 on MongoDB, and connect-mongo session storage. Staff upload documents through multer-s3 to AWS S3 (900-second presigned URLs); bcrypt handles passwords; Nodemailer sends verification mail. On boot, if the staff collection is empty, the app seeds a default user so fresh environments are never locked out.

The problem

Civic admin teams need document uploads, staff records, and email verification—not SPA complexity or a second deploy pipeline. They expect DataTables, Dropzone, and chart plugins in a familiar admin shell.

How it was built

One Express app owns persistence, sessions, and UI. express-session is backed by connect-mongo. AWS SDK integrations handle S3 uploads and presigned downloads. Admin plugins (Morris/Flot, Select2, DataTables, Dropzone) live under public/assets/plugins/ so the server-rendered templates stay self-contained.

Seeding a default staff user on empty collections is a small ops detail that prevents “deployed but unreachable” failures when handing environments to municipal IT.

Architecture decisions

• Server-rendered EJS over a separate SPA—one deploy, one mental model for staff
• Presigned S3 URLs (900s) instead of proxying every file through Node
• Session store in Mongo beside application data
• Bootstrap empty-state with a seeded staff account

Stack

• Express 4, EJS, Mongoose 5 / MongoDB, connect-mongo sessions
• multer-s3, AWS S3, bcrypt, Nodemailer, lodash
• Admin plugins: DataTables, Dropzone, Morris/Flot, Select2

What shipped

Production municipal portal foundation with cloud file handling and rich server-rendered admin tooling—usable without a dedicated frontend team.

Lessons

For civic back-office software, boring architecture wins. Staff already know DataTables; meeting them there beat inventing a React admin they would need training for.

More context on the homepage · Contact

Context

Patent licensing teams spend weeks manually cross-referencing declared patents against hundreds of pages of technical standards. At SpiderOrb I helped engineer SEPInsights—the production platform at sepinsights.com—split across a Django 4 REST API (PostgreSQL, Celery, Redis, Elasticsearch 7) and a Vue 3 + TypeScript SPA. My work spanned PDF ingestion (PyMuPDF, pdfplumber), essentiality APIs filtered by SSO and assignee, product-to-standard mapping, and claim-chart / relevant-text export flows.

The problem

Standards arrive as messy PDFs—nested sections, tables, figures—not clean databases. Analysts needed sub-second full-text search across standards and product declarations, async patent upload queues, and essentiality scoring that survives portfolio-scale filters without timing out.

How it was built

Backend work landed in modular Django apps for document ingestion, patent analysis, and product search. Haystack-backed Elasticsearch indices power search; Celery beat watches hot folders for patent processing. OAuth2 secures SPA access; cursor pagination keeps large result sets honest. A dedicated ES cluster sits beside managed PostgreSQL with SSL verification.

On the Vue side: Pinia, Ant Design Vue, OAuth2-guarded routes for standards quick-search, essentiality analysis, and html2pdf.js export/print. Vitest unit tests and Cypress E2E cover the SPA. A similarity-search POC explored transformers, LSI, and Word2Vec beside the production keyword pipeline—useful R&D without blocking the ship path.

Architecture decisions

• Separate search cluster from transactional Postgres—different scaling curves
• Async hot-folder ingestion so analysts are not blocked on upload
• Cursor pagination for portfolio-scale essentiality result sets
• Export claim charts from the SPA so counsel keeps a familiar PDF artifact
• Keep semantic-search experiments off the critical path until proven

Stack

• Django 4 REST, PostgreSQL (SSL), Celery + Redis, Elasticsearch 7 + Haystack
• PDF: PyMuPDF, pdfplumber; Gunicorn + Supervisor; Invoke deploys
• Vue 3 + TypeScript, Pinia, Ant Design Vue, OAuth2, html2pdf.js
• Vitest + Cypress; technology dictionary for domain query expansion

Search & document intelligence

• Elasticsearch indexing — dedicated indices for standards and products with faceted filters, highlighted snippets, and paginated API responses.
• Document intelligence — multi-library PDF parsing with section demarcation, table extraction, image capture, and admin section-tagging for content quality.
• Semantic similarity POC — transformer-based search, LSI topic modeling, and Word2Vec corpus similarity explored beside the production keyword pipeline.

Infrastructure

• Managed PostgreSQL with SSL certificate verification
• Dedicated Elasticsearch cluster separate from transactional storage
• Celery worker fleet with beat scheduler for document queues and analysis jobs
• Redis-backed caching and distributed locking for concurrent pipeline safety
• Gunicorn + Supervisor; Invoke-based deploys

What shipped

A live SEP analytics product where counsel moves from PDF review to filterable essentiality analysis, product discovery against declared standards, and exportable claim charts—backed by Vitest and Cypress on the SPA.

Lessons

Domain search quality is half data hygiene, half indexing strategy. Cleaning section demarcation in PDF ingest did more for relevance than any model experiment we tried in the POC lane.

More context on the homepage · Contact

Context

A digital marketing agency needed its own rank-tracking product—not another generic SEO tool with the wrong billing model. I designed and built the B2B SaaS end-to-end: Django backend with agency→client hierarchy, keyword trackers by device/OS/location/intent, Celery workers pulling SERP data via third-party APIs with postback webhooks, Stripe tiers from 500 to 50,000 keyword credits, and AWS production with supervised workers.

The problem

Agencies run dozens of client sites under one roof. They need white-label branding, credit-based billing tied to subscription tiers, automated daily/weekly/monthly scan schedules, and historical position tracking with SERP feature breakdown—none of which off-the-shelf tools offered cleanly in a multi-tenant agency model.

How it was built

A result-queue processor extracts organic positions and 20+ SERP feature types from async API postbacks. Stripe / dj-stripe webhooks sync to keyword credit balances across 13 tiers. Django Guardian RBAC keeps agency staff inside their portfolio. Environment-split Django settings, Redis-backed Celery, Gunicorn on EC2, and DevOps scripts supervise workers and beat schedules.

CSP headers were tuned for Stripe.js. Branded email flows keep client-facing communications on-agency. Historical rank series and SERP feature breakdown replace the spreadsheets the team used before.

Architecture decisions

• Agency→client hierarchy as the tenancy root—not flat user accounts
• Credit billing synced from Stripe webhooks, not manual top-ups
• Postback-driven SERP ingestion so workers stay resilient to API latency
• Celery beat for daily/weekly/monthly scan cadences per tracker config

Stack

• Django 4, PostgreSQL, Django Guardian RBAC
• Celery + Redis workers/beat; Gunicorn on AWS EC2
• Stripe + dj-stripe (13 tiers, 500–50,000 keyword credits)
• SERP postback queue; 20+ feature types; white-label dashboards

Product surface

• Agency → client hierarchy with Guardian RBAC on portfolio visibility
• Keyword trackers parameterized by device, OS, location, and search intent
• Historical rank series plus 20+ SERP feature types from postback payloads
• 13 Stripe tiers (500–50,000 keyword credits) synced via dj-stripe webhooks
• Daily / weekly / monthly Celery beat schedules; branded client email
• CSP tuned for Stripe.js; Gunicorn + supervised workers on EC2

What shipped

Production SaaS on AWS serving the agency and its clients—scheduled rank collection, subscription monetization, and branded dashboards replacing spreadsheet tracking.

Lessons

Agencies buy billing models as much as features. Getting credit tiers and RBAC right mattered more than adding another SERP column. Sole ownership meant Ops scripts for workers were part of the product, not someone else’s problem.

More context on the homepage · Contact

Context

Datatrics is a Dutch Customer Data Platform that unifies 200+ marketing and commerce integrations into profiles and activation workflows. As a senior full-stack engineer I worked across a multi-package monorepo: Symfony 3.0 API (PHP 7.1, Elasticsearch 7.8, Enqueue/Redis, Doctrine), Laravel 8 API (OAuth for Google/Facebook/LinkedIn/HubSpot, JWT, MongoDB via jenssegers/mongodb), the Workbench ETL cron connector, and the datatrics-targeting segmentation library.

The problem

CDP customers expect connectors to stay current as third-party APIs change, segments to evaluate behavioral and predictive rules at scale, and two API generations (Symfony /2.0 and Laravel) to coexist without breaking existing integrations mid-migration.

How it was built

On the Symfony side I extended API-key authenticated /2.0 endpoints and kept Doctrine/ES-backed profile access reliable. On Laravel, OAuth connector flows for ad platforms and CRMs stayed current. Workbench cron jobs sync external sources into Datatrics profiles; Docker Compose supported local Symfony work; Mongo patterns handled high-volume events.

Segmentation via datatrics-targeting composes behavioural, commerce, predictive/geo, UTM, device, and intent rules. Journeys, next-best-action, and webhook meshes sit on top of that profile fabric—Kubernetes in production for the broader platform.

Architecture decisions

• Strangler dual-API: keep Symfony /2.0 alive while Laravel OAuth connectors grow
• Mongo for high-volume events; relational/ES for profiles and search
• Composable targeting library instead of hard-coded segment SQL per customer
• Workbench ETL as cron jobs—predictable sync over fragile always-on workers for many connectors

Stack

• Symfony 3.0 API, PHP 7.1, Elasticsearch 7.8, Enqueue/Redis, Doctrine
• Laravel 8 API, OAuth (Google/FB/LinkedIn/HubSpot), JWT, MongoDB
• Workbench ETL cron; datatrics-targeting segmentation library
• Docker Compose local; Kubernetes production

Activation & targeting

• Composable rules: behaviour, commerce, predictive/geo, UTM, device, intent
• Customer journeys and next-best-action flows on unified profiles
• Webhook mesh for downstream activation into marketing tools
• Predictive scoring signals feeding segmentation

What shipped

Production contributions to a European CDP—dual API surfaces, connector reliability, and targeting evaluation while the platform scaled past 200 integrations.

Lessons

Migration is a product, not a weekend. Keeping both API generations honest with auth boundaries and connector ownership let marketing teams keep shipping while the platform evolved.

More context on the homepage · Contact

Context

TopPropSports is a real-money NFL fantasy contest platform. I joined as senior full-stack to ship before kickoff: React 17 + TypeScript SPA (MUI, Tailwind, Redux Toolkit, Formik), LoopBack 4 REST on PostgreSQL (AWS RDS), Dwolla ACH wallets with webhook verification, third-party NFL feeds for live fantasy points, and league import from major fantasy platforms. The product went live at toppropsports.com for the season.

The problem

Real money during live NFL windows means fantasy points must update within minutes, contests must settle across spread/cover/payout mechanics, ACH deposits/withdrawals need idempotent webhook handling, and state-level compliance gates must block invalid entries—all on a hard season-start deadline.

How it was built

A centralized scheduling layer runs five-minute cadence jobs on game days for live point ingestion, win detection, and settlement—polling rather than websockets kept ops simpler under deadline pressure. LoopBack role-based authorization spans the API. Dwolla customer onboarding includes KYC; webhook signatures are verified and events applied idempotently.

Lobby flows support head-to-head contests plus league import/normalization from major fantasy platforms, with in-app league messaging. Responsible-gaming and US state gates sit in the entry path. Containerized services and OpenAPI keep the contract clear between SPA and API.

Architecture decisions

• Five-minute polling jobs over websockets for scoring—reliability under kickoff pressure
• Idempotent Dwolla webhook handling to prevent double-credits
• State compliance checks before contest entry, not after settlement
• League roster normalization so imported lineups share one contest model

Stack

• React 17 + TypeScript, MUI, Tailwind, Redux Toolkit, Formik
• LoopBack 4 + TypeScript, PostgreSQL on AWS RDS, OpenAPI
• Dwolla ACH + KYC webhooks; NFL data feed ingestion
• Containerized deploy; structured logging and error monitoring

Contest & wallet surface

• Public head-to-head lobby plus league-based modes
• Spread / cover / payout settlement mechanics
• Dwolla customer onboarding with KYC and signed webhooks
• US state compliance gates and responsible-gaming checks on entry
• In-app league messaging alongside imported rosters

What shipped

Platform launched on schedule—public contests live, wallets funded and verified, fantasy points updating through game days, league contests running on imported rosters.

Lessons

Deadline products force trade-offs. Polling jobs and strict webhook idempotency were less glamorous than a live socket graph—and they were why settlement survived opening weekend.

More context on the homepage · Contact

Context

MoneyNetInt is a banking software platform where I contributed engineering on secure financial workflows—Java Spring Boot microservices with Oracle backends, AES-256 encryption for sensitive fields, REST APIs for account and transfer operations, and audit-friendly service layers aligned with regulatory expectations.

The problem

Banking integrations demand audit trails, encryption at rest and in transit, and transaction handling that survives partial failures without double-posting or silent data loss. Validation has to happen before commit—not in a cleanup job after money moved.

How it was built

Work sat inside the existing Spring Boot architecture on payment and account modules: service-layer validation before transactional commits, Oracle stored procedures where integrity rules belonged close to the data, RBAC on sensitive operations, and structured audit logging for investigators.

AES-256 patterns protected sensitive fields; REST boundaries kept account and transfer operations explicit. The discipline—validate early, log enough to reconstruct, never double-apply—later informed wallet and webhook handling on TopPropSports and billing flows on Mirrlo.

Architecture decisions

• Service-layer validation before Oracle commits
• Stored procedures for integrity-critical financial mutations
• RBAC + audit logs as first-class requirements, not add-ons
• Encrypt sensitive fields (AES-256) consistently across services

Stack

• Java Spring Boot microservices
• Oracle transactional database; stored procedures
• REST APIs for accounts and transfers; RBAC
• AES-256 encryption; compliance-oriented audit logging

What shipped

Contributions to a secure banking platform handling real-time transactions under regulatory constraints—experience that shaped later fintech delivery.

Lessons

Fintech bugs are expensive. Patterns that feel heavy in a startup MVP (idempotency, audit, encrypt-by-default) are cheap insurance once real balances are on the line.

More context on the homepage · Contact

Context

ROAI is a Paris-based freelance marketplace connecting clients with professionals for project-based work. I led full-stack delivery: Django 3.2.13 with Gunicorn and WhiteNoise, PostgreSQL, real-time messaging between clients and freelancers, project/bid/milestone models, email verification, and Docker + Nginx production deployment on AWS for the ROAI team. Laurent Jordi’s endorsement on the homepage covers this collaboration.

The problem

Freelance marketplaces need trust signals—profiles, portfolios, messaging, and project status—without boiling the ocean into a full agency suite. ROAI needed something shippable: account creation, project posting, bidding, and communication in one operable stack.

How it was built

Django models cover users, projects, bids, and messages with REST endpoints for the frontend. Real-time messaging keeps client–freelancer threads inside the project. Email verification gates onboarding. Docker + Nginx + Gunicorn package the app so the ROAI team can operate it without a bespoke PaaS.

Beyond feature code, the engagement included DevOps ownership—containerizing the Django monolith, CI/CD with GitLab, and AWS environments—so the MVP was not just “runs on my laptop.” That leadership surface is what made the engagement a tech-lead story, not only a CRUD build.

Architecture decisions

• Django monolith first—speed to MVP over premature service splits
• Dockerize early so Paris stakeholders share one runtime
• WhiteNoise + Nginx for static/media without a separate CDN day one
• Messaging and milestones as core trust features, not phase-two nice-to-haves

Stack

• Django 3.2.13, Gunicorn, WhiteNoise, PostgreSQL
• Real-time messaging; email verification; project/bid models
• Docker, Nginx reverse proxy, AWS deployment
• GitLab CI/CD for the ROAI delivery pipeline

What shipped

Production freelance platform for ROAI Paris—onboarding, project workflows, messaging, and a maintainable Django stack the team could operate.

Lessons

For marketplace MVPs, DevOps is product. Shipping Docker + CI with the features meant the client could iterate after I left—the real definition of done.

More context on the homepage · Contact

Context

AdInvestor is an advertising platform at adinvestor.co where I contributed full-stack engineering on campaign management, bidding workflows, and performance dashboards. Advertisers needed one surface to launch, monitor, and tune campaigns—without juggling disconnected analytics tabs.

The problem

Ad platforms live or die on latency and data freshness. Bid decisions need near-real-time performance signals, budgets must enforce hard stops, and the UI has to expose enough detail for optimization without overwhelming non-technical marketers.

How it was built

I built and extended API endpoints and frontend views for campaign CRUD, budget tracking, and performance reporting. Backend services aggregate impression and conversion data for bidding logic; the SPA structures drill-down from account level to individual creatives.

The React 18 + TypeScript client uses Redux Toolkit and Material-UI with D3 visualizations for denser performance charts. Node/Express services persist to MongoDB with Redis caching; AWS ECS handles autoscaling for bursty campaign traffic. Delivery moved through architecture, core build, optimization, and harden/deploy phases.

Architecture decisions

• Account → campaign → creative hierarchy mirrored in both API and UI
• Hard budget stops enforced server-side, not only in the dashboard
• Redis caching in front of hot performance aggregates
• ECS autoscaling for impression spikes rather than over-provisioning 24/7

Stack

• React 18 + TypeScript, Redux Toolkit, Material-UI, D3.js
• Node.js + Express; MongoDB; Redis
• Campaign/bidding services; performance aggregation APIs
• AWS ECS with autoscaling

What shipped

Live campaign operations on adinvestor.co—launch, spend monitoring, and performance drill-down without leaving the platform.

Lessons

Marketers optimize what they can see quickly. Drill-down UX and trustworthy budget enforcement mattered more than packing every metric onto one chart.

More context on the homepage · Contact

Context

AYL Shop needed a working storefront—not an ERP. I delivered catalog browsing, product detail, persistent cart, checkout, and order management for the AYL brand (Calma Properties retail client): React front office with Redux/Saga, Material-UI, and Formik/Yup, backed by Laravel + MySQL on AWS (EC2, SES, S3) with PayPal and PHPUnit coverage.

The problem

E-commerce MVPs fail when checkout is flaky or merchants cannot process orders. Requirements were a searchable catalog, cart across sessions, payment-capable checkout, and an admin surface for order status—without boiling the ocean into inventory ERP on day one.

How it was built

The React app mirrors patterns used on EOI Digital: Redux-Saga for async flows, Formik/Yup for checkout validation, Material-UI for consistent merchandising UI. Laravel owns catalog, cart persistence, checkout pipeline, and order lifecycle with merchant tooling for status updates.

AWS EC2 hosts the app; SES handles transactional mail; S3 stores media. PayPal covers payment. PHPUnit guards critical order paths so fulfillment bugs do not silently eat revenue.

Architecture decisions

• Reuse proven React/Laravel commerce patterns from EOI delivery
• PayPal first—faster to trustworthy checkout than custom PSP integration
• Merchant order admin as part of MVP, not a follow-up ticket
• S3 for media so EC2 stays replaceable

Stack

• React, Redux/Saga, Material-UI, Formik/Yup
• Laravel + MySQL; PHPUnit
• AWS EC2, SES, S3; PayPal checkout
• Catalog, cart, checkout, order lifecycle modules

What shipped

Working e-commerce storefront with end-to-end purchase flow—catalog through order tracking—for AYL Shop operations.

Lessons

Commerce MVPs are checkout and ops, not catalog beauty. Shipping merchant order tooling with the storefront avoided the classic “customers can buy, staff cannot fulfill” gap.

More context on the homepage · Contact

Context

SendOutpost matches startups with investors—a two-sided platform I built solo from architecture through beta at sendoutpost.com. Django + DRF + PostgreSQL, Celery async tasks, Stripe subscriptions, startup pitch workflows, investor discovery filters, Slack notifications, and a Knockout.js + Bootstrap/Materialize frontend guided by Figma.

The problem

Startup–investor matching needs structured profiles on both sides, search that surfaces relevant opportunities without spam, and billing that scales from free discovery to paid premium—while staying lean enough to launch and learn from real users.

How it was built

Django apps cover accounts, startups, investors, and matching. Celery handles email notifications and background scoring. Stripe checkout gates subscription tiers. Admin tooling supports moderation. The UI prioritizes profile completeness and discovery over feature bloat—Nose-based TDD kept regressions in check while iterating alone.

DigitalOcean hosted the beta. Slack notifications closed the loop when match events fired so operators were not glued to the admin panel.

Architecture decisions

• Profile-completeness-first UX—matching quality depends on structured inputs
• Celery for email/scoring so request paths stay fast
• Stripe freemium→paid from day one of monetization experiments
• Knockout MVVM for a lean SPA without a heavy modern toolchain at the time

Stack

• Django, DRF, PostgreSQL, Celery, Stripe
• Knockout.js MVVM, Bootstrap + Materialize
• DigitalOcean hosting; Slack notifications; Nose TDD
• Apps: accounts, startups, investors, matching

What shipped

Beta at sendoutpost.com with signup, profile creation, investor discovery, and Stripe monetization—solo delivery of a two-sided marketplace from zero to live users.

Lessons

Two-sided marketplaces die from empty profiles. Forcing completeness before discovery looked strict in demos and was the reason early matches were not noise.

More context on the homepage · Contact

Context

OM Sri Sai Service ran courier invoicing in spreadsheets—slow and error-prone at month-end. I built a Django invoicing system live at osss.co.in/invoice/ with shipment models, automated billing-period aggregation, spreadsheet-like data entry UX, and printable invoices that replaced manual compilation.

The problem

Courier operators generate dozens of shipments daily. Invoices must pull rates from shipment data automatically, apply the right rules, and produce printable outputs finance can reconcile—without re-entering tracking numbers by hand.

How it was built

Django models represent shipments and invoices. Views aggregate shipments into billing periods and trigger invoice generation. The UI keeps a spreadsheet-like entry feel so staff do not need a training week. Formatted outputs support client delivery and internal accounting.

Automation is the point: once shipments exist, invoice generation is a workflow—not a copy-paste marathon. That single change recovered the month-end hours the team was burning.

Architecture decisions

• Shipments as source of truth—invoices derive, they do not re-key
• Billing-period aggregation instead of one-off invoice drafts
• Familiar spreadsheet-like UX to ease adoption
• Printable outputs first-class for finance handoff

Stack

• Django models for shipments and invoices
• Automated billing-period aggregation workflows
• Printable invoice outputs for clients and accounting
• Deployed at osss.co.in/invoice/ for live ops use

What shipped

Live invoicing for OM Sri Sai Service—automated workflows replacing spreadsheet billing at month-end.

Lessons

Ops software wins on adoption. Matching the mental model of the old spreadsheet while removing the failure modes (re-keying, lost rows) got the tool used on day one.

More context on the homepage · Contact

Context

Western FIRE calculators assume 401(k)s and Roth IRAs. Indians plan around EPF lock-in, PPF caps, NPS tiers, old vs new tax regimes, and SIP/EMI cash flows. Mirrlo is the fintech MVP I built solo over several years—a Django 5 projection engine (apps/projections/engine.py models year-by-year income, expenses, assets, liabilities, and life events) with a React 18 + Vite frontend (TanStack Query, Recharts) and Razorpay subscription billing. It runs live at mirrlo.com with real users, not demo data.

The problem

Generic spreadsheets cannot compare Lean vs Coast vs Traditional FIRE paths side-by-side while respecting Indian tax regime switches, instrument-specific growth rates, and inflation assumptions in INR. Users needed scenario branching without re-entering their entire financial profile each time—and a product that felt native to Indian money, not a US calculator with a currency toggle.

How it was built

The backend is six modular Django apps—accounts, billing, profiles, projections, reports, scenarios—with JWT auth via djangorestframework-simplejwt and nested REST routers for profile income/expenses/assets/liabilities. The projection engine is the product core: year-by-year simulation that can fan into comparable scenarios without cloning the whole profile. A compare endpoint returns side-by-side corpus and SIP requirements. Settings are split (local / staging / prod); Supabase PostgreSQL backs staging and production; structured logging and custom exception handlers keep API failures diagnosable.

On the frontend, React 18 + TypeScript + Vite powers a financial profile wizard, interactive projection charts, and protected routes. Production builds run a prerender script for SEO. Sentry and PostHog cover errors and product analytics. Razorpay lives in the billing app with webhook verification so Pro unlocks (advanced scenarios, reports, export) stay consistent with payment state—not a checkbox flipped in the admin.

Architecture decisions

• Domain model first: income, expenses, assets, liabilities, and life events as first-class profile data—not a single “net worth” field
• Scenario branching on shared profiles so users compare FIRE paths without re-keying
• India-specific instruments (EPF, PPF, NPS, old vs new regime) baked into the engine, not themeable afterthoughts
• Razorpay webhooks as source of truth for Pro entitlements
• Split Django settings + Supabase Postgres so local SQLite speed does not leak into prod assumptions
• Observability (Sentry/PostHog) from early MVP—solo founders need signals when they are not watching the logs

Product surface

• 30-year wealth projections with inflation-adjusted corpus targets and milestone markers
• Lean / Coast / Traditional FIRE compare with side-by-side SIP and corpus requirements
• Profile wizard covering income, SIPs, assets, liabilities, and goals
• Freemium → Pro via Razorpay subscriptions (reports, advanced scenarios, export)
• Mobile-first dashboard for India users; JWT session handling on protected routes

Stack

• Backend: Django 5, Django REST Framework, simplejwt, six apps under apps/
• Projection engine in apps/projections/engine.py; compare endpoint for scenarios
• Frontend: React 18, TypeScript, Vite, TanStack Query, Recharts
• Data: Supabase PostgreSQL (staging/prod); split settings for local/staging/prod
• Billing: Razorpay + webhook verification; freemium/Pro gating
• Ops: prerender for SEO; Sentry; PostHog; structured logging

What shipped

A live fintech MVP with 30-year projections, side-by-side FIRE scenario comparison, India-native instruments, and Razorpay monetization—full product ownership from domain modeling through payments and observability.

Lessons

The hard part was not charting—it was encoding Indian financial reality so comparisons stay honest. Once the engine respected EPF lock-in and tax regime switches, the UI mostly revealed decisions users already needed to make. Shipping Razorpay webhooks early forced entitlement bugs into the open before “Pro” became theater.

More context on the homepage · Contact

Context

Finding a verified psychiatrist in India and running the clinic behind that appointment are two different problems—most products solve neither well. PsychePoint is the live product I built on the MindWell platform: a patient marketplace at app.psychepoint.com for discovering professionals and booking appointments, plus clinic SaaS dashboards for doctors, receptionists, and pharmacists. Django 5 with Channels for real-time features, Celery + Redis for notifications, Razorpay for patient payments and doctor subscriptions, and a React + Material-UI frontend with role-specific dashboards.

The problem

I needed both sides of a two-sided marketplace and a multi-tenant clinic operations stack—appointment conflict detection across timezones, digital prescriptions with PDF output, SMS/email/WhatsApp notifications, and a provider directory credible enough that patients would trust it. All while shipping an MVP alongside freelance contract work, without a separate growth team to seed supply.

How it was built

MindWell’s Django apps (users, appointments, prescriptions, payments, notifications, core) sit under role-based access for doctors, patients, receptionists, pharmacists, and caregivers. django-allauth and Jazzmin admin cover auth and ops. Supabase PostgreSQL is the production datastore. Celery + Redis drive notification fan-out; Channels cover real-time clinic surfaces. Razorpay handles patient checkout and doctor subscription plans via configured plan IDs.

Supply was the cold-start risk. I built an enterprise provider scraper (Selenium + BeautifulSoup, proxy/UA rotation, parallel workers) targeting 15,000+ Indian mental-health professionals across MCI, RCI, NIMHANS, AIIMS, hospital networks (Apollo, Fortis, Max, Manipal, Narayana), JustDial cities, and platforms like Practo/Lybrate—with phone/email validation, deduplication, and confidence scoring so the directory was not a dump of junk rows. The React app splits dashboards by role: appointments, billing, messaging, and pharmacy modules for clinic staff; discovery and booking for patients.

Architecture decisions

• One platform, two products: marketplace UX for patients + ops SaaS for clinics on shared domain models
• Role-based dashboards instead of one overloaded admin for every persona
• Scraper pipeline as a first-class supply system—marketplace liquidity is an engineering problem
• Celery for SMS/email/WhatsApp so request paths stay fast during booking spikes
• Razorpay for both patient payments and doctor subscriptions—one billing vendor, two monetization surfaces
• Supabase Postgres in production to move fast without standing up DB ops day one

Marketplace & clinic surface

• Verified professional listings with discovery and booking for patients
• Appointment scheduling with conflict detection across timezones
• Digital prescriptions with PDF generation tied to appointments
• Multi-channel notifications: SMS, email, WhatsApp
• Role dashboards: doctor, receptionist, pharmacist, patient/caregiver
• Razorpay checkout for visits + subscription plans for clinic/doctor tiers

Stack

• Backend: Django 5, Channels, Celery + Redis, django-allauth, Jazzmin
• Apps: users, appointments, prescriptions, payments, notifications, core
• Frontend: React + Material-UI role-specific dashboards (MindWell-react)
• Data: Supabase PostgreSQL; PDF generation for prescriptions/receipts
• Supply: Selenium + BeautifulSoup enterprise scraper (MCI/RCI/NIMHANS/hospitals/Practo, …)
• Billing: Razorpay patient payments + doctor subscription plan IDs

What shipped

Live MVP with active users—verified professional listings, end-to-end booking with Razorpay checkout, and clinic management tools for staff. A regulated healthcare domain taken from scraper pipeline through production deployment solo.

Lessons

Two-sided healthcare products die on empty directories. Investing in the scraper and verification pipeline felt like “not the product”—and it was the only reason booking flows had someone to book. Role-split dashboards kept clinic staff from drowning in patient-marketplace chrome.

More context on the homepage · Contact

Context

ProHouse started as a MERN marketplace experiment—React 18 frontend, Express 4 API, Mongoose 8 on MongoDB, running concurrently via concurrently in dev. The domain grew beyond property listings into a full e-commerce surface: products, orders, cart, wishlist, reviews, Q&A, notifications, Paytm checksum payments, Cloudinary image hosting, and SendGrid email—with JWT auth and bcrypt password hashing throughout.

The problem

Housing marketplaces need rich listing detail, search, and buyer-seller communication—but the repo also explores e-commerce patterns (cart, wishlist, mined product recommendations via a minedProduct Mongoose model) that could extend to property personalization later.

How it was built

Express server with modular models under server/models/, JWT middleware in server/middlewares/user_actions/auth.js, and a React SPA for browsing and account flows. Paytm and Cloudinary integrations for payments and media; concurrent dev script runs API and CRA together.

What shipped

Full-stack MERN marketplace demonstrating property listing UX alongside e-commerce infrastructure—personal project showing breadth across auth, payments, and catalog management in one codebase.

More context on the homepage · Contact

Context

Nursing programs still grade on paper and compile reports by hand. EduNurse is a Django 4.2 app I built for structured test marks entry: Student, Subject, and Test models with first/second test marks per subject, a report generation view that aggregates per-student subject marks into printable output via ReportLab 4.0.4, and Vercel deployment config routing all traffic to the Django WSGI handler.

The problem

Education admins need repeatable grading workflows—enter marks once, generate consistent printable reports per student across all subjects, without Excel macros that break when someone adds a column.

How it was built

Single grades Django app under the edunurse project with models for students, subjects, and tests. Views aggregate marks into report data structures; ReportLab renders PDF output. vercel.json routes all paths to the WSGI entry for serverless deployment.

What shipped

Focused grading and reporting tool for nursing programs—marks entry, aggregated reports, and deployable on Vercel without a dedicated ops team.

More context on the homepage · Contact

Context

Before Instagram had a usable web app, I built one—deployed to Heroku at django-advance-photos-app.herokuapp.com. Django 3 with DRF, PostgreSQL, and django-storages uploading to AWS S3. Every photo upload generates three renditions via ResizedImageField (240×135, 720×405, 1200×675) so the infinite-scroll gallery loads the right size for each viewport. python-magic validates MIME types (PNG/JPEG only); Lightgallery and Dropzone power the upload and slideshow UX.

The problem

Photo galleries on slow connections need progressive loading—not full-resolution images on every scroll event. Upload flows must reject bad files server-side, generate compressed variants in-memory before S3 write, and group photos by date for browsing.

How it was built

In-memory image processing with Pillow on upload, three stored renditions per photo in S3, infinite scroll in the gallery module loading smaller renditions first, and DRF in INSTALLED_APPS for future API extension. Gunicorn on Heroku for production serving.

What shipped

Deployed Instagram-style web app optimized for low-bandwidth users—multi-rendition uploads, infinite scroll, and slideshow browsing on infrastructure I managed solo.

More context on the homepage · Contact

Context

A job board platform with employer posting workflows, candidate search and filters, and application tracking—I built the full-stack implementation covering job listing CRUD, category and location filters, employer dashboards, and candidate-facing browse and apply flows.

The problem

Job boards fail when search is slow or employer posting is painful. Both sides need fast filtering (role, location, salary range) and a posting flow that doesn't require a tutorial.

How it was built

Backend models for jobs, employers, and applications with indexed search fields. Frontend browse with filter panels, job detail pages, and employer admin for posting, editing, and reviewing applications.

What shipped

Functional job listing platform with search, filters, and employer posting workflows—two-sided marketplace mechanics from listing through application.

More context on the homepage · Contact

Context

A proof-of-concept for live and on-demand video streaming—I explored architecture options for ingest, transcoding, CDN delivery, and player integration to understand what a production streaming service would require before committing to full build-out.

The problem

Streaming POCs often demo playback without addressing the hard parts: adaptive bitrate, upload ingest pipelines, storage costs, and latency between live capture and viewer playback.

How it was built

Architected and prototyped the ingest-to-playback path—upload or capture endpoints, storage layer, transcoding considerations, and a web player consuming the output streams. Documented trade-offs between self-hosted and managed CDN approaches.

What shipped

Working POC demonstrating live and VOD playback paths—technical foundation and documented architecture decisions for a future production streaming product.

More context on the homepage · Contact

Context

I built analytics pipelines and reporting layers on Google BigQuery—ingesting operational data into a warehouse schema, writing SQL transformations for business metrics, and surfacing dashboards that stakeholders could query without waiting for engineering ad-hoc requests.

The problem

Raw application databases aren't shaped for analytics. Reports that took hours of manual SQL each week needed to become scheduled queries with consistent definitions everyone trusts.

How it was built

BigQuery table design with partitioned datasets, scheduled query jobs for recurring metrics, and documented SQL views that product and finance teams could reference. Data engineering focused on reliable ingestion and idempotent transforms.

What shipped

Repeatable analytics infrastructure on BigQuery—scheduled pipelines and reporting views that reduced manual data wrangling and gave stakeholders self-serve access to key metrics.

More context on the homepage · Contact

Context

Salary comparisons across countries are misleading at face value—a $100K offer in San Francisco isn't the same as $100K in Bangalore. The PPP Salary Converter at ahmadwkhan.com/ppp-converter/ uses World Bank purchasing power parity data to show what a salary actually buys in each location, with live data fetching and client-side conversion.

The problem

Exchange rate converters answer the wrong question. Job seekers and remote workers need PPP-adjusted comparisons that account for cost-of-living differences, updated from authoritative sources—not static multipliers from a blog post.

How it was built

JavaScript app fetching World Bank PPP indicators, normalizing salaries across country pairs, and presenting both nominal and PPP-adjusted figures. README documents data sources and update cadence; SEO block attributes the tool to my portfolio.

What shipped

Live PPP converter helping users compare international offers on purchasing power, not just exchange rates—one of the free tools I maintain on ahmadwkhan.com.

More context on the homepage · Contact

Context

I wanted a ChatGPT-style assistant that runs entirely on my machine—no API keys, no data leaving the network. RAG Personal AI is that experiment: FastAPI backend, Ollama for local LLM inference (Mistral/LLaMA), Qdrant vector store for semantic retrieval, LangChain orchestration, and Sentence Transformers for embeddings. Feed it PDFs or Markdown notes; it chunks, indexes, retrieves relevant passages, and grounds answers in your documents.

The problem

Cloud LLMs are fast but expensive and leak context to third parties. Local models are private but hallucinate without grounding. The hard part is the glue: chunking strategy, embedding quality, retrieval ranking, and prompt assembly that keeps answers faithful to source material on consumer hardware.

How it was built

RAG pipeline with overlapping text chunks, Qdrant collection per document set, semantic search retrieval before each Ollama completion, and Docker Compose to wire FastAPI + Qdrant + Ollama together. Supports GPU and CPU inference paths so it runs on a laptop or a workstation.

What shipped

Working offline assistant that answers questions from uploaded documents with retrieved context—useful as a reference architecture for privacy-sensitive domains and as a sandbox for experimenting with local model quality vs cloud APIs.

Architecture

RAG Pipeline

• Document loading (PDF, Markdown)
• Text chunking with overlap
• Embedding generation (Sentence Transformers)
• Vector storage (Qdrant)
• Semantic search retrieval
• Context-augmented prompting

Technology Stack

• FastAPI for REST API
• Ollama for local LLM (Mistral/LLaMA)
• Qdrant vector database
• LangChain for orchestration
• Docker for containerization
• GPU/CPU support

More context on the homepage · Contact

Context

Oli's WebGL Experiment is a birthday gift I shipped as a browser game—Unity WebGL export loaded via legacy UnityLoader.js, fullscreen canvas spanning the viewport, low-poly third-person build artifact at Build/oli_lowpoly6.json. HTML comment and meta author tag credit the build directly. Not a commercial product—a personal project proving I can take a Unity scene from editor to playable WebGL deployment.

The problem

WebGL builds are unforgiving: bundle size, load times, and browser memory limits kill games that run fine in the Unity editor. I had one low-poly scene and a deadline tied to a birthday, not a sprint cycle.

How it was built

Low-poly art direction for performance, Unity WebGL build targeting browser deployment, and a minimal HTML shell with fullscreen CSS on #gameContainer—no unnecessary JS frameworks wrapping the loader.

What shipped

Playable 3D game running in the browser—Oli's WebGL Experiment delivered on time as a technical gift, not a product launch.

Technical Implementation

Game Systems

• Inventory management system
• Item interaction and pickup
• Collision detection algorithms
• Rigid body physics
• Survival mechanics
• Low poly 3D graphics

Technical Stack

• Unity game engine
• C# scripting for game logic
• WebGL build target
• Browser deployment optimization
• 3D graphics and rendering
• Physics simulation

More context on the homepage · Contact

Context

How do people actually earn money in India? Not the LinkedIn version—the kirana owner, the gig worker, the government clerk, the OnlyFans creator. The India Work & Earning Landscape at ahmadwkhan.com/india-work-landscape/ is an interactive catalog I built ranking jobs, gigs, and businesses by entry difficulty, income potential, and realistic barriers.

The problem

Career advice online is US-centric or aspirational fluff. Indian readers need an honest map of earning paths—what it takes to start, typical income ranges, and how hard entry actually is.

How it was built

Structured data model for earning categories with difficulty rankings, filterable browse UI, and narrative context per path. Static hosting on my domain with client-side interactivity for exploration.

What shipped

Public research artifact cataloging India's earning landscape—used by visitors exploring career pivots, side income, and realistic entry points.

Key pieces

Data & Analysis

• Master taxonomy of work types in India
• Entry Accessibility scoring (0-100%)
• Composite Sustainability metrics
• Automation risk assessment
• Capital requirement analysis
• Income potential tracking

Technical Implementation

• Chart.js for data visualization
• PapaParse for CSV parsing
• Advanced filtering and search
• URL-shareable state management
• Print/PDF export functionality
• Responsive design for all devices
• Research-grade data accuracy

More context on the homepage · Contact

More context on the homepage · Contact

Context

The FIRE Calculator at ahmadwkhan.com/FIRE-calculator/ is a client-side tool I host for corpus planning in INR, USD, and Euro. Vanilla JavaScript computes financial independence age from savings rate, expected returns, and withdrawal assumptions—with no backend, no account required, and instant results as you slide inputs.

The problem

Most online retirement calculators assume US tax brackets and 401(k) limits. Indian users planning FIRE need INR defaults, sensible return assumptions, and a UI that updates projections live without page reloads.

How it was built

Single-page calculator with script.js driving compound growth math, currency-specific defaults, and responsive CSS. Hosted as static files on my domain—same pattern as my other free finance tools.

What shipped

Live FIRE calculator used by visitors exploring financial independence timelines—simple, fast, and tuned for multi-currency corpus planning.

Key pieces

Calculator Features

• Monthly expense input with slider
• Current age and corpus tracking
• Expected annual return percentage
• Required corpus calculation
• Age at FIRE determination
• Multi-currency support (INR, USD, Euro)

User Experience

• Interactive sliders with number inputs
• Real-time calculation updates
• Clean, intuitive interface
• Mobile-responsive design
• Free, accessible tool for all
• No account required

More context on the homepage · Contact

Context

Get Off Your Ass at ahmadwkhan.com/GetOffYourAss/ is a habit accountability tracker I built for myself first—mark daily routines, track streaks, and get nagged (gently) when you skip. Client-side persistence, no signup wall, focused on consistency over feature count.

The problem

Habit apps become social networks or subscription traps. I wanted a blunt tool: did you do the thing today or not? Streak visibility without gamification noise.

How it was built

Simple web app with daily check-off flows, streak counting, and local storage so it works offline. Minimal UI—function over aesthetics, hosted on my domain alongside other personal experiments.

What shipped

Working accountability tracker I actually use—proof that useful tools don't need a backend or a business model to ship.

Key pieces

Core Functionality

• Random activity suggestion generator
• Curated collection of uplifting activities
• Beautiful, engaging user interface
• Animation and visual effects
• Mental wellness focus
• Mobile-responsive design

User Experience

• Simple, intuitive interaction
• Instant activity suggestions
• Focus on positivity and motivation
• Self-care and mental health support
• Free, accessible tool
• No account required

More context on the homepage · Contact

Context

Tim Urban's "Your Life in Weeks" stuck with me—a 4,000-week grid makes mortality tangible. I built my version at ahmadwkhan.com/your-life-in-weeks/ in React + TypeScript: enter your birthdate, see weeks lived vs remaining, mark milestones on specific weeks, and export a custom wallpaper via html2canvas.

The problem

Life visualization tools either feel morbid or gimmicky. The grid needs to feel personal—milestones you define, colors that distinguish past from future, and an export worth setting as your phone wallpaper.

How it was built

Week-by-week grid with age-based calculation, color-coded cells (lived, future, milestone), interactive hover tooltips, local state for milestones, and html2canvas wallpaper generation. Tailwind CSS for responsive layout.

What shipped

Mindfulness tool I use myself and host publicly—helps people see time as finite weeks rather than abstract years, with exportable visuals for daily reminder.

Key pieces

Visualization Features

• Week-by-week life calendar (4,000 weeks)
• Color-coded weeks (filled, future, custom)
• Milestone tracking and labeling
• Interactive hover tooltips
• Progress visualization
• Age-based calculation

Technical Implementation

• React with TypeScript
• Tailwind CSS for styling
• html2canvas for wallpaper export
• Responsive design
• Local state management
• Smooth animations and transitions

More context on the homepage · Contact

Context

I keep a repo of 20+ standalone Python simulation scripts—FIRE planning, UBI macro modeling, Indian stocks and mutual funds, SaaS unit economics, game-theory negotiation, nomadic life costs, and more. The UBI package (ubi_simulation/) splits economic, consumer, and government models with NumPy. FinSim is a Django subproject where probabilistic life events (health crisis, inheritance, rental vacancy, vehicle purchase) hit your net worth via Monte Carlo draws in simulation_algos.py.

The problem

Spreadsheet models hide assumptions and break when you want stochastic outcomes—run the same FIRE plan 1,000 times and see the distribution of retirement ages, not a single optimistic number. Policy questions (what if UBI shifts GDP?) need agent-based or equation-driven models you can actually tweak.

How it was built

Each simulation is a focused script or package with explicit parameters and NumPy random draws. UBI sim models GDP, unemployment, and inflation under different transfer scenarios. FinSim wraps algos in a web UI for interactive exploration.

What shipped

Research sandbox I use to stress-test financial and policy ideas before building product features in Mirrlo or public calculators—20+ prototypes covering personal finance, macro policy, and business dynamics.

Architecture

Simulation Engine Patterns

• Monte Carlo loops — 30 to 10,000 runs with percentile bands (5th/50th/95th)
• Stochastic life events — probabilistic shocks with configurable cost ranges per event type
• Economic regimes — boom, normal, recession return/inflation multipliers
• Rich terminal UI — live progress bars, formatted INR tables, inline histograms
• Export pipelines — Matplotlib charts, Excel workbooks, CSV result sets

Stack & Tooling

• Python 3.9+, NumPy, Pandas, Matplotlib, Seaborn
• Rich + Babel for Indian locale currency formatting
• scikit-learn (Random Forest, IsolationForest, KMeans)
• Django 5 + DRF for FinSim web prototype scaffolding
• yfinance, scipy, tabula-py, statsmodels, TextBlob
• Chart.js browser demo (Simulate the Dough)

Idea-to-Product Pipeline

The Simulation Lab follows a deliberate promotion path: validate the math in a CLI script, extract models into Django if persistence/API is needed, then rebuild for production with proper auth, payments, and frontend. Mirrlo is the clearest example of this pipeline in action.

1. Script — personal_finance_simulation_01.py
2. Django POC — Simulations/finsim
3. Production API — mirrlo/FinTwin/finsim_backend
4. Live MVP — mirrlo.com

Key capabilities

• Monte Carlo Mastery — Life-event finance, portfolio forecasting, India macro futures—probabilistic modeling across domains with validated output distributions
• Rapid POC Velocity — Standalone scripts ship in hours; Rich CLI gives immediate feedback; no boilerplate blocking hypothesis testing
• Product Lineage — FinSim to Mirrlo proves simulation-first development—algorithms tested in the lab before production hardening
• India-First Modeling — INR formatting, crorepati milestones, EPF/PPF/NPS, rental income, parental support—culturally grounded defaults Western tools ignore

More context on the homepage · Contact

Context

WorldFeed is my answer to information overload—a Python 3.12+ intelligence terminal positioned as accessible production insight. FastAPI REST server, SQLAlchemy + Alembic persistence, Redis caching, aiohttp and feedparser for ingestion, Rich terminal UI, and a plugin architecture under plugins/. CLI entry points: worldfeed for the terminal and worldfeed-api for the REST server. Documented tiers: Free, Pro ($29), Enterprise ($299).

The problem

News aggregators give you headlines without context; terminal tools are developer-only. I wanted 200+ direct-source feeds across 24 categories with sub-second latency, extensible via plugins, and a monetization path that doesn't require selling user data.

How it was built

Modular package layout (config/, core/, api/, models/, storage/, utils/) with Docker deployment under deployments/docker. Feed ingestion pipeline with Redis-backed caching; plugin hooks for custom sources and enrichers.

What shipped

Working intelligence platform prototype with terminal and API surfaces—foundation for a freemium micro-SaaS around curated, low-latency feed aggregation.

Architecture

Platform Core

• FastAPI with OpenAPI docs and rate limiting
• Intelligence engine: trend detection, breaking news, correlation
• Plugin system for extensible enrichers
• PostgreSQL + Redis with structured logging
• Prometheus metrics and Docker Compose deployment

User Interfaces

• Bloomberg-style terminal CLI (`worldfeed`)
• REST API (`/v1/feeds`, watchlists, analytics)
• React dashboard for web access
• WebSocket for live feed updates
• Freemium tiers: 50 feeds free, all feeds Pro

Key pieces

• Direct-Source Aggregation — 200+ authoritative feeds across finance, health, tech, climate, and geopolitics
• Terminal UI — Keyboard-driven Bloomberg-style interface with search, filters, and live refresh
• Plugin Architecture — Extensible enrichers—sentiment analysis, custom alerts, enterprise integrations
• Micro-SaaS Model — Free (50 feeds), Pro $29/mo (all feeds + analytics), Enterprise $299 (SLA + plugins)

More context on the homepage · Contact

Context

Indian kirana stores run on intuition—what to stock, when to reorder, how long customers will wait. Kirana Sim models that in TypeScript + Vite: a fixed-timestep game loop at 30 FPS where 90 seconds real-time equals one sim day. Inventory lives on shelves, in fridges, and in the backroom with freshness decay. Suppliers arrive by scooter or truck; customers queue with patience timers; cashiers and stockers have speed, wage, fatigue, and skill attributes loaded from JSON data files.

The problem

Retail simulation usually means abstract tycoon games—not the specific economics of a neighborhood store where milk spoils, regulars expect staples, and staffing mistakes show up in the day-end P&L.

How it was built

Core game engine in src/core/game.ts with data-driven items, suppliers, and random events from JSON. UI modules for HUD, inventory, queue, staff, orders, and day summary; canvas renderer and audio subsystem; Assamese-first i18n via src/locale/i18n.ts because the POC targets Northeast India retail context.

What shipped

Playable kirana simulation for exploring reorder timing, spoilage waste, and staffing trade-offs—research tool for retail ops, not a generic store tycoon clone.

Simulation Systems

Game Loop

• Fixed-step tick (30 TPS) with rAF render decoupling
• Day/night progression with pause on hidden tab
• Customer spawn with budget, patience, and elasticity
• Checkout flow with cash, reputation, and SFX
• End-of-day summary: revenue, COGS, spoilage, profit

Data & Localization

• JSON packs: items, suppliers, cultural events (Bihu, rain)
• Perishability and shelf-life decay modeling
• Scooter delivery with ETA and freshness penalty
• Assamese-first i18n with language selector
• WebGL1 with graceful fallback if blocked

Key pieces

• Inventory & Spoilage — Shelf slots, per-item shelf life, decay toasts, and reorder triggers for milk and perishables
• Dynamic Pricing — Price sliders with margin hints and demand elasticity—customers abandon if overpriced
• Scooter Delivery — Order from mandi suppliers, pay upfront, receive stock after ETA with freshness loss
• Assamese-First Experience — Localized HUD, ordering flow, and day summary—designed for regional cultural authenticity

More context on the homepage · Contact