I'm Buck.

I didn't start out trying to build a software company

I spent roughly two decades in offshore medicine and operations. The work is practical by nature: when something needs doing, somebody has to understand the situation, use what is available, and make the process work.

A surprising amount of that work depends on tools that were never really meant to become systems — spreadsheets carrying years of logic, shared folders standing in for databases, repeated forms, hand-maintained schedules, and procedures that make perfect sense only to the person who built them.

The hobby was fixing those things

I have always liked making things. Sometimes that means a lathe or fabrication work. Sometimes it means hardware. Eventually it meant code. I started with small fixes, then spreadsheets with more ambition than spreadsheets should probably have, then real applications.

The common part was never the technology. It was the moment where I looked at a process and thought, there has to be a better way to do this.

Buck's & Co. is the part I'm making real

Some of those builds are becoming products. Remedy grows out of offshore medical and operational work. ComPar tackles the very ordinary problem of managing Safety Data Sheet libraries and revisions without forcing the files into somebody else's system.

Building those products created another set of problems, so I built tools for myself too. Sproutle and Dugout are the ones that became useful enough to stand on their own.

And not every useful thing needs to become a subscription product. Sometimes a company just needs the spreadsheet, calendar, form, or folder-based process it already understands turned into a cleaner tool. That is the other side of the business I'm building.

Small is a feature here

I am not trying to look like a hundred-person software company. If you talk to Buck's & Co., you talk to me. I can look at the actual process, tell you what I think is worth fixing, and tell you when I do not think custom software is the answer.

The goal is to grow the shop without losing that. Reuse what already works. Build only the part that needs to be different. Keep people in control of important decisions. Be clear about what is finished and what is still an experiment.