about_
I'm a product-focused engineer with 7 years of experience building web-based products for early-stage startups. That means pre-seed to Series B, and 3-50 employees roughly. Those are the two problems I tend to solve.
You need to test a fresh hypothesis.
We work out what the product needs to prove, where rigor will pay for itself, and what can wait. Then I build it, or assemble and lead the small team that does.
I did this for Paragon Social: scoped the product, hired the team, and delivered it end to end in about twenty weeks. The client came back with more work.
The MVP exists, but it's too unreliable to ship.
This is the version I keep encountering after another team or dev shop has technically built the requested features. QA fails for different reasons every run. Bugs all over the place. Nobody can easily explain what happened because there is no useful observability. Every fix appears to create another bug.
The answer is not automatically a rewrite. First, we have to define what is actually failing, make the critical paths observable, and separate what blocks release from what is merely ugly. Then we repair only as much as the product and the business need.
That is the work I am increasingly best at:
- Paragon brought me a trading prototype that ran out of memory within an hour. I led the rebuild into a system that reliably handles thousands of market-data events per second across hundreds of assets.
- xGame had to feel live on a slow, flaky, eventually consistent network. We made failure visible and recoverable. Its first week did $300k in volume, and the launch itself was uneventful.
- Dextrac, a monitoring and analytics tool for blockchain transactions, had pages that took minutes to load over millions of rows. The finished design loaded them in one or two seconds while keeping the data fresh enough for what users actually needed.
Where the rigor comes from.
I spent years building systems that moved real money and data, and then auditing smart contracts where one missed edge case could become a very expensive lesson. That taught me what rigor costs and when it is worth paying for.
A product hypothesis does not need the controls of financial infrastructure. It still needs to be reliable enough that your users can complain about the product and not the bugs though.
This means artisanal code in and of itself should not be the goal. Matching the engineering to the consequences and what the actual business needs is the goal.
And "well-made" software is as much about the product as the code: the features you pick, the onboarding, and the small polish that makes software a joy to use (local-first, low-latency, keyboard-first, etc).
This whole thing, where you take an idea to a real production-grade product and not just a prototype, is the thing I enjoy most. I am a builder at heart before all else.
How I work now.
I use coding agents heavily, some of them on my laptop (Claude Code, OpenCode), some of them in the cloud (I have my own fork of OpenInspect).
I obviously use skills. Some of them are my own, but I'm also a big fan of Matt Pocock's skills.
As I said, I'm a huge fan of cloud agents, so that means automated reviews, bug triage, etc. I really think AI and automation are most beautiful when they happen semi-invisibly around you and not prompted by you.
I still believe in having a human in the loop, particularly at planning phases but also at code review where it matters.
All of this is not magic though and I will not tell you it makes me 10x. It is simply how I produce more without scaling garbage code and garbage git hygiene.
A little about me.
I have spent my whole career in early-stage companies of roughly 3–50 people, contributing as a developer, lead, and auditor. I'm at my strongest in TypeScript, React, and Node.js, but have also shipped Rust, Go, Python, and Solidity in production.
I work remotely from Eastern Europe with teams across Western Europe and the US. I lean async, stay reachable for a substantial part of the day, and prefer doing the work over filling the calendar with recurring meetings.
Outside of work I'm an ex-amateur boxer who still trains, a bit of a data science hobbyist, a husband, and a father of two.
Working together.
Some of my clients begin with a short, scoped engagement (maybe an MVP, an architectural exploration, an audit of your codebase and processes). Others need a more embedded approach, whether full time or with a flexible hours setup.
If you lead product or engineering at a lean startup and are trying to get software from nearly there to genuinely shippable, tell me what is happening: [email protected].