Product Engineer
Profile
Most engineering work starts from a ticket. Mine starts earlier: working out what the problem actually is, what should change and what can wait. Then I make the technical decisions and ship it, and I judge the result by what it changes in the operation, not by how much was built.
Approach
Four habits, each with the work that shows it.
When the same request keeps arriving, the missing piece is usually a tool. I solve the category, not the next case.
The first version removes the manual step people are stuck with, and earns the next one.
If people are tracking state or refereeing by hand, the product should do it, and say no when a move breaks the rules.
Architecture, performance and refactors earn their place by their effect on the business or the operation. I report a result only when it was measured.
At ZRP: API response times from several seconds to around 500 ms
Progression
From implementation toward owning the product decisions.
Newest at the top. Each bar spans one phase, with a tick where each year begins. Filled: Product Engineering, still under way.
2025 – now
The shift was from building what was asked to deciding what should be built, then building it. Today that happens in two places. At Rare Candy, where I work through Howdy, I do it inside a team. Through Farrel.tech, I do it directly with clients such as Pro Electric, and on my own products, such as DDD Toolkit.
2022 – 2025
Client and product work at Let's, DoroTech and ZRP, and a stretch working independently. Over those years the work moved from delivering sites toward the backend underneath them: the part that has to stay fast and correct in production. Ottoset Energy / Institutional Website (Sheet 006) is from this period.
2020 – 2022
I started at Arbo as a junior full stack engineer on a real estate platform, and moved into the technical lead role after building the automation that distributed property listings to marketplaces.