David
Gary

Problem

Most handwriting tools stop at toy OCR examples. The real problem is turning messy cursive documents into something usable without forcing users into a notebook-only workflow.

Approach

Built the system as three surfaces around the same core pipeline: a macOS GUI app, a CLI for automation, and a Python API. Added model packaging, offline-friendly distribution, batch processing, and optional GPU acceleration instead of treating inference as a one-off script.

Outcome

Produced a usable transcription tool rather than just a model checkpoint. The project now supports end-user installation, custom training, and multiple interaction modes for real document workflows.

Problem

Move-day planning is usually guesswork: room constraints, doorway clearance, and item dimensions are handled separately (if at all), which causes bad load plans and repeated rework.

Approach

Implemented a bare RN app with a local Expo native module for RoomPlan room capture and ARKit tap-to-measure, then layered an arrangement heuristic over the captured room geometry. Added camera media intake per item, automatic sensor matching, and a fallback chain for non-LiDAR runtimes.

Outcome

Delivered an iOS-first planning workflow that can run on real hardware with LiDAR and still remain usable on fallback paths in simulator/non-LiDAR environments, with EAS profiles in place for release builds.

Problem

Forensic imaging on macOS is often ad hoc, error-prone, and missing chain-of-custody metadata. The challenge is acquiring evidence safely while preserving auditability.

Approach

Built a Python CLI that enumerates and validates sources, performs guarded imaging, computes and verifies SHA-256 digests, records acquisition context in a structured manifest, and supports optional Ed25519 signatures, RFC3161 timestamps, and APFS mapping documentation.

Outcome

Produced a repeatable acquisition workflow with integrity verification, preflight safety checks, mode-based risk controls, and portable release artifacts for field use and intake validation.

Problem

System dashboards are often either overbuilt enterprise products or shallow toy demos. The gap is a lightweight monitoring tool that still feels production-minded and reacts in real time.

Approach

Built a single-binary Go service with gopsutil collection, websocket broadcast, REST endpoints, and embedded frontend assets served via go:embed. Added local BoltDB persistence, a VIEW selector in the dashboard, source=db API reads for historical inspection, and a Python analysis workflow (make analyze / make analyze-up) for deeper offline runs.

Outcome

Shipped a practical observability tool with production-minded web ergonomics: real-time telemetry, persisted history replay, analyzable anomaly registry data, and self-contained deployment without external infrastructure dependencies.

Problem

Small vendors need practical software for day-to-day inventory, sales history, orders, expenses, and reporting without adopting heavyweight enterprise tooling.

Approach

Built a reusable admin toolkit (tabbed inventory/sales/orders/expenses/events/reports) backed by an Express + SQLite API and configurable store metadata, plus adjacent planning tools for sourcing and operational decisions.

Outcome

Created a maintainable operations foundation that can be adapted per-store, run locally with minimal infrastructure, and extended incrementally as business requirements evolve.

Problem

Climbers tracking board sessions in spreadsheets have no fast way to see trends across grades, walls, styles, or time — the signal is in the data but buried in rows.

Approach

Built a monorepo with a Vite + React frontend and an Express + SQLite backend. The seed pipeline imports an Excel climbing log on first run; the analytics endpoint aggregates across various chart types. Recharts handles rendering; interactive filters let users slice by date range, wall, grade, and style.

Outcome

Turned a flat spreadsheet into an interactive training dashboard that surfaces trends — grade plateaus, flash-rate improvements, overtraining by day — that would be invisible in a raw log.