Entrepreneurship
I am interested in whether a useful solution can stand on its own commercially. That means thinking about the problem, the people who have it, and what it would take to serve them well — not just whether the software can be built.
Beyond technology
The part that happens outside the job.
Independent products, infrastructure experiments, and physical projects. This is where most of the learning actually happens.
The work I do professionally is only part of how I think about technology. Most of what I have learned has come from building things outside of a job description — small products, home infrastructure, and physical projects with real constraints.
Independent product development
Basket exists because a household problem kept showing up. Building it means owning the design, the data model, the mobile client, the offline behavior, and the decisions about what not to build.
Practical DIY projects
I like projects where software meets something physical: power, water, connectivity, and monitoring on a rural property. The feedback is slower and less forgiving, which makes it a useful counterweight to software work.
Learning new technologies
I learn best by setting something up and breaking it. A new tool does not really make sense to me until I have run it, misconfigured it, and had to fix it.
Infrastructure experimentation
The home lab is where I test ideas about networking, DNS, self-hosting, and local AI without a change review or a maintenance window. Some of it sticks. A useful amount of it does not.
Building things that solve real problems
The common thread is usefulness. I would rather ship a small, unglamorous tool that someone actually uses than a polished concept that never leaves the sketchbook.
Why it matters
Building outside work is how I stay honest about what it takes.
In a professional delivery, someone else owns the commercial risk. On these projects, I do. That changes how you think about scope, maintenance, and whether a feature is worth its cost.