Bear Trail Works: starting with a small, real problem

Some software starts with a very ordinary question: who has paid for class?

My salsa teacher runs informal community classes. People show up through friends and social events, and groups grow over time. One day, I watched her spend several minutes sorting out payments. Someone had already paid. Someone had credit from a previous class. Someone couldn’t remember.

She took the time to work through it with everyone. But it was another thing asking for her attention, class after class.

That became the starting point for Studio Ledger: a way for independent instructors to track attendance, payments, and credits. My teacher became its first tester, and her feedback helped shape the product.

It’s also a good place to begin explaining Bear Trail Works, where I build software for small businesses and founders, alongside my own products.

The starting question is simple: what are you doing today, and where does it get unnecessarily difficult?

Sometimes the answer is copying the same information between two systems. Sometimes it’s keeping track of something in a notebook that works perfectly well until you need to find an old entry. Sometimes it’s an idea that needs a small working version before anyone can tell whether it makes sense.

There’s plenty to build in those ordinary situations.

Two other projects at Bear Trail show different versions of that approach.

Reef Keeper is an aquarium tracker for logs, tasks, and tank care. An aquarium involves things you observe, things you measure, and things you need to do again. Keeping a record gives those details somewhere to live besides your memory.

Ritual Cafe offers guided coffee recipes, brewing timers, and ratio adjustments. Anyone who makes coffee knows how many details can change from one cup to the next. Having a recipe and a timer close at hand makes it easier to pay attention to the brew.

Teaching a class, maintaining an aquarium, making coffee. Different activities, each with its own details. In each case, the software has a specific job.

That last part matters.

It’s easy to make a project bigger while explaining it. Add another feature, imagine another kind of customer, account for every possible situation. Eventually, the first useful version starts to look very far away.

I’ve written here before about learning through execution. The same principle applies to software: choose a problem you can describe clearly, build something people can actually use, and pay attention to what happens.

Sometimes an existing app is enough. Sometimes the workflow needs a small adjustment. And sometimes building a focused tool makes sense. Understanding that comes before deciding what to code.

That’s the approach behind the custom work at Bear Trail, too. I work directly with small businesses to simplify manual tasks and connect their tools, and with founders to build a first version they can put in front of people.

The salsa-class example keeps the point concrete. The instructor already knew how to teach. The bookkeeping was a recurring interruption around that work. Giving it a simpler place to happen was a useful problem to tackle.

If you’re curious about what I’m building, take a look around Bear Trail.