I like software that disappears into the task.

Building product software directly for small teams and businesses, choosing projects where the problem is specific enough to actually solve well rather than broad enough to require a large team.

• Scoping a project honestly matters more than any single technical decision inside it.
• Being the whole team means every shortcut you take, you also maintain.

Built the offline sync layer and most of the field-facing interface for a data collection tool used across four pilot deployments in areas with unreliable connectivity.

• Designing for the worst network condition first changes almost every other decision.
• A pilot deployment surfaces problems no amount of internal testing will.

Worked across a small engineering team building internal tooling for logistics coordination, moving between backend services and the interfaces that used them.

• Internal tools still deserve real design attention — the users just have less patience for bad ones.
• Cross-functional context is easier to build when you sit close to the problem.

First engineering role, working on a small web team shipping client sites and learning, mostly by making mistakes in front of people patient enough to explain why they were mistakes.

• Most early mistakes are process mistakes, not code mistakes.
• Asking a specific question beats a vague one, almost every time.