Case studies, not claims.

A cooperative HMO federation ran its entire financial operation on QuickBooks Desktop Enterprise — 32-bit, Windows-Server-bound desktop software with no public API. The organization needed a modern, in-house healthcare management system for billing and disbursements, but the accounting team could not abandon QuickBooks: it held years of financial history and remained the system of record. Every proposed solution before this one assumed a rip-and-replace the business could not afford.

Architect a Django + PostgreSQL platform that treats QuickBooks Desktop as a live, first-class data source: mirror its Chart of Accounts, enforce accounting-grade correctness on every transaction, and guarantee that nothing posted from the new system could ever duplicate or corrupt the ledger — all without disrupting the accountants' daily workflow.

Solved the core blocker first: QuickBooks Desktop is 32-bit, so the integration had to run on a 32-bit Python runtime speaking through the FLEXquarters QODBC driver via pyodbc — including diagnosing a session-mode connection error that had no documented fix. Built a Chart of Accounts sync pipeline (extract → JSON payload → HTTP POST → reconciliation on QuickBooks' own primary keys) producing a 1:1 mirror in Django. Enforced financial integrity with a Service Object layer, double-entry validation (total debits must equal total credits on every entry), `transaction.atomic()` wrapping so multi-row operations are all-or-nothing, and a Draft → Approved state machine gated by idempotency keys so no receipt or voucher can post twice. Documented the whole architecture so the client's team can maintain it without me.

A modern web platform and a 20-year-old desktop accounting system now operate as one coherent whole: accounts stay reconciled 1:1, financial operations cannot partially complete, and double-posting is impossible by design rather than by policy. The integration pattern — 32-bit ODBC bridge plus idempotent sync — is rare enough that it doubles as a reusable playbook for any business locked into legacy desktop software.

English and Japanese trading-card markets price the same cards differently — a real arbitrage opportunity, but one buried in a third-party pricing site with no public API, an unstable DOM, and active hostility to automated access. Naive scrapers against sources like this break weekly, and a price dashboard that shows blanks the moment the scraper fails is worthless to anyone making buying decisions.

Build an arbitrage dashboard that stays populated and trustworthy no matter what the upstream source does — while keeping scraping load low enough to be sustainable and every price labeled with exactly how fresh it is.

Designed a three-tier fallback pipeline: a Playwright headless-browser scrape as the primary, a Cheerio static-HTML parse with heuristic DOM-candidate scoring as the fallback, and the last known database snapshot as the floor — so the worst case is stale data, never no data. Added an in-memory LRU cache (5,000 entries, 6-hour TTL) to eliminate redundant headless-browser launches, and a nightly `node-cron` job that refreshes only records older than six hours, bounding scrape load to the stale subset of the catalog. Modeled a weighted arbitrage-scoring engine in Prisma/PostgreSQL, exposed through a single aggregated dashboard API computing leaderboards, freshness charts, and top movers across hundreds of tracked card pairs per request, with a multi-state sync status (healthy / fallback / stale / unavailable) surfaced honestly in the UI. Core scoring and fallback logic covered with Vitest.

The dashboard delivers near-100% data availability against a source that regularly defeats single-strategy scrapers, with per-record freshness the user can verify at a glance. Batch CSV ingestion and a resale ROI calculator (fees, shipping, grading) turn raw price gaps into actionable buy/sell decisions — a complete decision-support system, not a scraper with a UI.