> rules from the workshop wall

Principles

Less Miserable Tech starts from a simple belief:

Technology should reduce friction, not create new rituals of suffering.

These are the principles I keep coming back to while working with real businesses, real people, messy workflows, and tools that are usually more complicated than the problem required.

They are not commandments. They are workshop rules. If a tool, AI assistant, website, plugin, workflow, or automation makes these harder, something has gone sideways.

I use these in my own life as much as in my work. They come up in conversations with clients, friends, family, and collaborators: “What’s the smallest useful fix?” “Are we hiding the plumbing?” “Is this actually broken, or are we just tempted to tinker?”

They are not polished theory. They are workshop rules I keep reaching for when real life, real work, and real tools get messy.

I share them because they have helped me make better decisions, and maybe they will help you too.

Name the problem before picking the tool.

If you cannot name the friction, you are not ready to choose the software.

A lot of technology projects start with the visible symptom: “we need a new system,” “we need AI,” “we need automation,” “we need a plugin,” “we need a dashboard.”

Maybe.

But first: what is actually painful?

Is the work being re-entered? Is the decision being remade every time? Is someone hunting for the same document over and over? Is the system expecting a person to remember something the system should remember?

The tool comes later. The friction comes first.

Build the smallest useful fix.

You don’t have to fix everything at once or build a whole new system to remove one real obstacle.

The best fix is often smaller than the first idea. A better default. A shorter path. A checklist. A tiny automation. A clearer intake form. A way to stop retyping the same thing.

Small does not mean trivial.

Small means it can actually land, be used, and reduce pain before everyone forgets why the project started.

AI needs the backstory.

The task tells AI what to do; the backstory helps it understand what matters.

The real problem with AI is not usually that people picked the wrong magic prompt. The real problem is that the system does not know the business yet.

It does not know the documents, the workflow, the customer, the exceptions, the tone, the constraints, or what “done” means.

AI gets useful when it has context. Otherwise, it is just a very confident stranger with a keyboard.

Trust is earned one useful moment at a time.

People learn to trust technology when it reliably makes the next step easier and leaves less to guess about.

People trust systems that help them finish real work, avoid mistakes, and feel less lost the next time.

That trust usually grows through small wins:

the right information appears when needed
the next step is obvious
the repeated task gets easier
the scary part becomes routine
the system remembers what the person should not have to

Trust is cumulative. So is misery.

Choose carefully.

If it ain’t broke, don’t fix it.

If it is not causing real friction, leave it alone and spend your energy where it matters.

Corollary: If it ain’t broke, don’t fix it - but don’t leave horsepower on the floor.

This principle is not anti-change. It means don’t disturb working systems just because something newer exists. But if stronger capability can reduce real friction without breaking the working machine, use it.

If the fix costs more than the pain, it is not a fix. If automation makes the rare case easier but the common path harder, it is not progress. If the new tool creates more rituals than it removes, congratulations: you have invented a fancier problem.

Improve the parts that hurt. Respect the parts that do not.

Build the net for the river you’re already standing in.

If useful ideas, questions, or opportunities keep showing up, build a simple way to capture and reuse them.

This principle is not only about missing good ideas. Missing good ideas is one symptom. The deeper principle is: when something valuable keeps happening repeatedly, stop treating each instance like a one-off. Build a way to capture and use the pattern.

The river is the recurring flow of useful raw material: ideas, AI releases, customer questions, repeated prompts, back-patio insights, workflow fixes, business opportunities, content moments, operational lessons, and “we should save that” moments.

The net is the lightweight system that catches those things without requiring panic, perfection, or manual one-at-a-time effort.

This matters especially with AI. The goal is not to use every new model on release day, write the perfect prompt every time, or turn every good conversation into finished content by hand. The goal is to build simple capture, sorting, shaping, and reuse habits so useful work compounds over time.

For Less Miserable Tech, that means the work is not just having good ideas. The work is building a capture-and-processing system:

notice the signal
preserve enough raw context
extract the useful nugget
do the public-safety pass
shape it into a post, field note, audio segment, or principle
publish consistently when ready

A less-miserable system helps the human trust the flow because it catches enough of the good material to work with later.

Hide the plumbing.

You shouldn’t have to understand the machinery to get the help.

The system can be complicated underneath; using it shouldn’t be.

A useful technology system may have complicated machinery underneath: servers, profiles, memory stores, archives, providers, gateways, voice models, tools, logs, sync jobs, and admin workflows.

That complexity can be real. Sometimes it is necessary.

But the user should not have to understand it to receive value.

For smart, capable people who are not trying to become systems engineers, the system should feel like a calm, personal, useful front door.

The advanced system can still exist under the floorboards. But the person using it should know:

what to say
how to stop it
what it heard
how to correct it
how to ask for simpler help
whether the system needs something from them

Power can live in the basement. People should get the living room.

put it to work

The principles are useful only if they change what you build next.

Start with one real workflow. Name the friction. Make one part less miserable. Then do it again.

Start with Week 1