Most solutions look good until they meet a deadline, a constraint, or a person who actually has to use them. Thirty years of building physical things means I design for that moment first — not last.
I've spent 30 years building physical things that have to work.
I apply that same standard to software.
Most solutions look good until they meet a deadline, a constraint, or a person who actually has to use them. Thirty years of building physical things means I design for that moment first — not last.
Data Engineering
After completing Google's data analytics program I wanted to take on a project that was comprehensive and complete in its skill requirements
Built: A database pulling 8 years of data across 616 cities in 90 countries, with analysis identifying top pollutants and trends — driven by firsthand experience with air quality while living in China.
Demonstrates: Data pipeline construction, large-scale SQL database design, Python analysis at scale.
Python · pandas · matplotlib · PostgreSQL
View on GitHub →
Google Data Analytics Certified — capstone project 
Document Intelligence
Problem: My client needed to understand their customer's Coda document comprehensively without having to spend hours looking at documentation.
Built: A CLI tool using the Coda API to map every table, element, and dependency in the document, feeding a structured source of truth to an LLM for accurate Q&A.
Outcome: Client could query any proposed change and get a reliable answer about what would break. 99% accuracy on dependency questions.
Python · OpenAI Codex · Coda.io API
Web Scraping
Problem: Teacher had a paid subscription to ESLBrains but no way to access her content offline — downloading 400+ lessons manually would take days.
Built: A scraper that browsed the site, downloaded PDFs and YouTube videos, and organized everything according to the site's own structure.
Outcome: 900+ files across 400 distinct lessons downloaded and organized in under 1 hour. Still in daily use.
Python · Selenium · yt-dlp · Jupyter Notebook
Offline AI Systems
Problem: Standard spell checkers fail dyslexic writers — the error patterns are different and the corrections are often wrong. Cloud-based AI solved it but was inconsistent and too expensive for daily use.
Built: An offline browser-based system using rule-based processing and regex to check words, learn individual error patterns, and self-correct over time. No subscription, no API costs.
Outcome: V1 complete and in active use. Currently iterating on pattern recognition
Python · SQLite · Flask
This system emerged from necessity during a client website project. The client needed their React/Vite site migrated to Astro and redesigned for modern SEO best practices. The challenge is that I'm a Python developer and designer with zero JavaScript knowledge, no budget to hire a specialist, and a fixed timeline.
Initial attempts using AI directly worked…sort of. The AI would implement requested changes, but also modify things I hadn't asked it to change. Colors would shift, spacing would become inconsistent, content would be rewritten. This was expected. The problem wasn't the AI; it was ambiguity. When faced with unclear constraints, AI makes decisions. That's a feature, not a bug. Mitigating this requires explicit context engineering to be useful.
The solution evolved iteratively: First, style guides. Then domain-specific lock files covering design, content, and architecture. Then separation of planning (strategic decisions) from execution (tactical implementation). Then feedback loops, changelogs and content inventories to maintain state across iterations. After half a day of refining the workflow, implementation became not just reliable; It became pleasurable.
Result: 99% accuracy across 15+ iterations. Zero breaking changes. Features discovered and implemented mid-project. Client received a working site, full handoff documentation, and the system itself to continue iterating.
Context is the most important part of starting to build. We often get stuck solving the wrong problem entirely. Before any code gets written, I work to understand why something isn't working, not just what isn't working. Correct framing is usually where the elegant solution lives.
We live in a world of constraints. Narrowing the work to fit the frame keeps costs controlled and progress visible. A tight scope isolates what works from what doesn't and prevents adding complexity before it's necessary.
There's no such thing as a free lunch. In fabrication there's a saying: Good, Fast, Cheap: pick two. Every decision comes with tradeoffs. Understanding them upfront means we spend time on what actually moves the project forward, not on discovering constraints mid-build.
No plan survives first contact with actual use. Custom applications always reveal something unexpected once a real person sits down with them. That's not failure, its part of the process. Iteration helps lift the veil between concept and execution the moment something is actually used. The path forward then becomes more clear.
I'm fascinated by the gap between how things appear to work and how they actually do. Beneath every simple explanation is a labyrinth of decisions, constraints, and tradeoffs. I've spent my life learning to navigate it at every scale: from building PCs to halfpipes to electronic theatrical props for Blue Man Group and retail installations for Nike, Samsung, and Dyson.
Computers were always around me growing up; When a 386 laptop cost $10,000 and you learned by changing hex code on games just to see what would break. I built my first PC as a teenager, studied network engineering, then shifted focus entirely to physical building. I skated as a teenager but there were no skateparks... so I built one: an 8-foot high, 16-foot wide, 32-foot long halfpipe in my backyard. That summer I fell in love with building things.
I learned design at Parsons School of Design and became a fine woodworker making furniture. Needing more space in a cramped NYC apartment, I learned framing and built a loft. Soon after: plumbing, electricity, tiling, and eventually full apartment renovations around the city. A chance visit to help an electronics friend hang some shelves led to the Blue Man Group FX shop, where I learned to build custom props and instruments under tight deadlines. That mentality carried into theatre, film, and eventually retail — building out shops and installing campaigns for Nike, Samsung, and Dyson across New York City.
I never lost the technological streak. I learned Python and SQL before LLMs entered the mainstream. Now I apply that same drive to AI-augmented development: Building tools that work in the messy real world, not just in theory.
If something in your workflow is costing you time or creating coordination problems, I'd like to hear about it. Send a note or book a call directly — no pitch, just a conversation about whether I can help.