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. 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
A client needed their React/Vite site migrated to Astro and redesigned for modern SEO. I'm a Python developer and designer: zero JavaScript knowledge, fixed timeline, no budget for a specialist.
Direct AI coding worked up to a point. The model would implement the requested change but then modify small things. Colors shifted. Spacing drifted. Content rewrote itself. I noticed it rewrites the whole file every time, and without explicit constraints, it decides what goes back in.
When constraints are unclear, the model fills in the gaps.
That's expected. The fix was making every constraint explicit as reusable files before implementing changes. This evolved in stages: first a singular style guide, then domain-specific lock files; one for design, one for content, one for architecture.
Then separation of planning from execution: one AI makes decisions and writes specs, a separate AI implements. They never communicate directly; everything passes through files. Then a feedback loop: after each phase, the executor generates a snapshot of current state. That snapshot goes back to the planning AI before the next phase starts. Stateful awareness on each end.
The result: scroll through the site, brain dump changes, have them reliably show up without breaking anything else. The client received the working site, full handoff documentation, and the workflow itself. Enough to keep iterating without depending on me.
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.