What I actually do
Two things, mostly. I build websites for businesses that need one, and I automate the repetitive parts of running a small operation. Both usually turn out to be the same job: taking information that lives in somebody's head or somebody's phone and putting it somewhere it can be found.
01
Web Development
Sites for businesses that need to be found and believed. Static where it can be, fast on a phone in a parking lot, and structured around the two or three questions a visitor actually showed up with.
- Sites for businesses that mostly need to be found, believed, and called.
- Static builds first. A page that is already rendered beats a page that has to think about it.
- Structure built around the two or three questions a visitor showed up with, not around a sitemap.
- Search setup that is part of the build rather than something bolted on afterward.
If what you need is a storefront with inventory and a checkout, say so early. That is a different job with different tradeoffs, and I will tell you if it is out of my lane.
02
Business Automation
Mostly trucking. Paperwork that moves itself from a driver's phone into a folder someone can search, and the mail and account plumbing underneath it that decides whether any of it arrives.
- Paperwork intake. Photos from a phone into named, filed, searchable documents.
- Google Workspace setup and administration, including the mail authentication that decides whether your email arrives.
- Glue between tools that were never meant to talk to each other, built to fail loudly rather than quietly.
- Honest answers about what should stay manual. Some things are not worth the script.
Most automation work starts with watching someone do the task once. I would rather spend twenty minutes looking over your shoulder than two hours guessing from a description.
03
IT Infrastructure
Networking and hardware. I have not written this one up yet, so there is nothing here worth reading.
Method
How a job usually goes
- 01
Watch it happen
Before anything gets built, I want to see the current process run once, mistakes included. The workaround somebody invented three years ago is usually the most important detail, and it never makes it into a written description.
- 02
Find the part that actually hurts
Most requests arrive as a solution. Underneath there is a specific moment that costs time or loses information. That moment is the thing to fix, and it is often not the thing that got asked for.
- 03
Build the smallest version that works
Something running in a week that handles the common case beats something perfect that is still being built in a month. The edge cases get handed to a person on purpose until they are worth automating.
- 04
Make failure visible
Anything I build says so when it cannot do its job. Silent failure in an automation is worse than no automation, because you stop checking.