Full-stack product engineer with ~15 years of deep B2B product work across two long-term engagements: ~8 years from first commit to exit at hipMenu, then ~7 more with the same founder on a new product. I help small teams get their systems under control.
Embedded ownership across your whole product
Your team shipped fast, and now the codebase fights every change. I untangle the architecture, fix the pain points, and make the system workable again — without a full rewrite.
Frontend, backend, infrastructure, testing — I work across all of them. One person who understands the whole system means fewer handoffs, faster decisions, and less context lost.
Legacy cleanup. Flaky CI pipelines. That migration everyone's been avoiding. I handle the structural work that doesn't fit neatly into a sprint but makes everything else easier.
I work like a team member, not a vendor. I learn your product, understand the constraints, and make decisions that account for what happens after I leave.
Features take three times longer than they should. Developers are afraid to touch core modules. Every fix creates two new bugs.
You have a React dev, a backend dev, and someone who touches infra sometimes. But nobody owns how the system fits together. Cross-cutting concerns fall through the cracks.
You've tried agencies and freelancers. They deliver features and disappear. The next person inherits undocumented decisions and missing context.
Microservices, Kubernetes, and event patterns were introduced before the product needed them. Now the complexity is expensive, fragile, and hard to justify.
CI/CD is flaky, tests are thin, and releases still feel manual. The team moves slower because the feedback loop is unreliable.
I bias toward boring technology when it makes the product more stable. If a proven SQL database solves the problem, I do not force distributed NoSQL. If a well-structured monolith is enough, I do not split it into microservices for style points.
Architecture decisions start with understanding what is already there. I map the system first, then change the parts that are actually causing pain. I avoid new abstractions unless they remove a real bottleneck.
Complexity always sends a bill later. Part of my job is cleaning up old debt without creating fresh debt your team has to carry after I am gone.
I spent ~8 years working on hipMenu — a B2B food menu platform — from the first line of code through a successful exit. During that time I worked across the entire stack: frontend, backend, infrastructure, and testing.
I wasn't just shipping features. I handled architecture decisions, system stability, performance work, and the kind of cross-cutting concerns that don't have a Jira ticket. When the product pivoted, I adapted the codebase. When things broke at scale, I was the one debugging on a Saturday.
After the exit, the founder and I kept working together on a new, larger project — another ~7 years of collaboration built on the same foundation: consistency, follow-through, and treating the work with care. That ongoing trust is what I consider the real measure of a good engagement.
Now I bring that same ownership to other teams — usually small startups or growing products where one strong generalist is worth more than three specialists.
Step 1 - Audit & Map. Before I write code, I map the architecture, deployment flow, and the parts everyone avoids. Stated pain points and actual bottlenecks are often different.
Step 2 - Embedded Execution. I work inside your team's rhythm: Slack, standups, and PRs. We ship incrementally and document decisions as we go.
Step 3 - Documented Handoff. When the engagement ends, it ends cleanly: architecture notes, decision logs, and practical runbooks. No vendor lock-in.
I currently work with one long-term client and have room for one additional engagement. Best fit is a small or mid-size product team that needs a senior generalist to stabilize the codebase and own cross-cutting engineering work.