Michael W.

Most AI consultants want to rewrite your app in Python. I don't, because I have specialized in both. I've spent a decade shipping production Rails and the last two years building ML systems. The hard part of adding AI to a real product usually isn't the model - it's retrieval, background jobs, evaluation, and the fact that your data already lives in Postgres. Rails stays the system of record. Torch-enabled inference runs as its own service behind a clean adapter, so you can swap or scale it without touching your domain logic. Knowing where that boundary belongs in a robust, existing system is most of the job. Two things worth knowing before you hire me. The first is my track record here: 3,200+ hours, 100% job success, Top Rated Plus, and a decade of production web applications behind it. That's the evidence that I finish what I start. The second is in my portfolio. I built a real-time conversational voice agent that runs entirely offline on hardware at home, reachable from a phone app - no cloud, no API keys, no data leaving the house. Solo: architecture, ML, and evaluation. Every headline number in that write-up has a measurement under it, because that's the only way to know whether a system like this actually works. That's the evidence of what I can build. What that looks like on a Rails project - Embeddings and vector search in the database you already have: pgvector, hybrid retrieval, no second datastore unless you actually need one - Ingestion and consolidation pipelines as real background jobs: Sidekiq/ActiveJob, idempotent, observable, restartable - LLM features behind service objects and well-defined interfaces, so they're testable and swappable instead of a vendor SDK sprayed through your controllers - Python inference services with clean adapter boundaries: PyTorch and llama.cpp workloads that your Rails app talks to over a defined contract, not a tangle - Evaluation harnesses that live in your test suite, so "did the AI feature get worse" is a CI question and not a vibe, as well as knowledge of how to reliably test a non-deterministic model - Self-hosted and offline inference when data can't leave your infrastructure Depth behind it - Long-term memory subsystem for the offline voice agent: graph memory substrate, nightly consolidation pipeline, adversarial entity deduplication, retrieval head - Local LLM deployment on constrained hardware: quantized 35B MoE inference (fits under 16GB VRAM), RWKV, Whisper STT, containerized services over a message bus - Production systems in Ruby on Rails, Python, React, Docker, and Postgres - Custom data pipelines and integrations across messy, undocumented APIs (including Shopify) - Meritorious Winner, COMAP ICM — stochastic simulation of kidney donor networks I'm especially strong at taking loosely defined ideas and turning them into clear, reliable systems with visible progress early in the project. I work best with clients who value clear scope, early deliverables, and honest communication. Bonus points if your project description includes the phrase "we thought this would be simpler." Stack Ruby on Rails, Ruby, Python, SQL, JavaScript ML / LLM: llama.cpp, Qwen, RWKV, Whisper, embeddings, vector search, RAG, knowledge graphs, PyTorch, OpenAI APIs Infrastructure: Postgres, pgvector, Sidekiq, Docker, NATS, FastAPI, SQLite, CUDA Also: React, C/C++, Java, PHP, Matlab, R, embedded systems, legacy platforms