Every line of code is a line item. Treat it that way.
How I make technical decisions with the product's P&L in mind — not the resume.
I love good engineering. I love elegant code. I love the right abstraction. None of that is what you’re paying me for.
What you’re paying me for is decisions that compound into return on investment — for your customers, your team, and your business. So that’s the lens I look through, first.
What “ROI-driven” actually looks like
It looks like a lot of small, unglamorous calls:
- Picking the boring database because it costs nothing to operate, not the trendy one because it’s interesting.
- Buying the SaaS when the maths says buy. Building when the maths says build. Telling you, plainly, which way the maths goes.
- Deleting code that’s only paying for itself in cleverness points.
- Saying “this feature doesn’t deserve to exist” out loud, in a meeting, while we still have time to not build it.
- Sizing the project so a 90% solution ships in week 3, instead of a 100% solution shipping in month 6.
”Love for product and client”
People sometimes hear “ROI” as cold. It’s the opposite. The reason ROI matters to me is that the product matters to me, and the client matters to me. A project that costs the business more than it returns is one I won’t have the privilege of working on again — and the team won’t get to keep building.
Caring about the maths is the most respectful thing I can do for the people whose business it is.
How it shows up in practice
- Discovery calls aren’t sales calls. I’d rather lose your engagement than mis-scope you into a build that won’t pay back.
- Every proposal is sized so you can see the payback window. If I can’t articulate it, we shouldn’t ship it.
- Tradeoffs are surfaced as tradeoffs, not as “best practices.” Best practice for whom, when, at what cost?
- If something we’re building isn’t going to earn out, I’ll tell you mid-build, not at delivery.