What I Look For in Engineering Work
A short personal note on how I choose projects, what a good brief looks like, and the questions I ask before writing a line of code.
Quick answer
I look for a clear owner, a measurable outcome and an appetite for boring infrastructure. The best briefs state the problem and the constraint rather than the solution, and the best clients can describe what changes for their users when the work ships.
Three questions before anything else
- Who decides? A project with three equal decision-makers and no tiebreaker will stall regardless of engineering quality.
- What changes when this ships? If the answer is 'it will look modern', we have not found the problem yet.
- What are we willing to not do? Scope with no boundary is a deadline with no meaning.
What a good brief looks like
Checkout drops 30% of mobile users at the address step. We think it is the validation. Budget is fixed, timeline is six weeks, and we can ship weekly.
— A brief I would take immediately
It names a metric, offers a hypothesis, states a constraint and allows iteration. Compare that with 'we need a redesign' and the difference in likely outcome is obvious.
What I bring
- Working software weekly, not a reveal at the end.
- Decisions written down, including the ones we rejected and why.
- Boring, typed, observable systems — the interesting part should be the product.
- Honest estimates, including when the honest answer is 'do not build this'.
Checklist
- A single decision-maker identified
- A measurable outcome agreed up front
- Explicit out-of-scope list
- Weekly shipping cadence
- Written decision log
Common mistakes
- Starting build before the success metric exists.
- Accepting a solution as the brief instead of the problem.
- Hiding bad news until the deadline.
Frequently asked questions
What kind of projects do you take?
Product engineering work across React and Node.js applications, Shopify apps and storefronts, and AI-assisted tooling — usually where performance, commerce and architecture overlap.
Do you work with agencies?
Yes, as an embedded engineer or technical lead, provided there is a single point of decision on the client side.
Summary
Clear ownership, a measurable outcome, an explicit scope boundary and a weekly cadence. Those four things predict a project's success more reliably than the technology stack.
working on something like this?