Configuration of Quiet Machine

Built a small automation that watched for new orders and synced the address data directly into her delivery software. Nothing fancy. A few lines of code connecting two APIs. I charged her a flat monthly fee that was less than what she would pay for an hour of her own time. She signed up in under five minutes.

That became my template. Identify a specific task that happens repeatedly. Build a connection between the tools already in use. Price it so the math is obvious. One hour saved per day at a rate that made the decision feel easy.

Something changed in the last two years. Small businesses stopped hiring full time specialists for every problem. Instead they started looking for these tiny point solutions. A tool that only does invoice matching. A tool that only handles customer follow up texts. A tool that only checks one compliance box once a month.

They do not want to buy a platform. They want to buy a finished result delivered without fuss.

I think this is where the opportunity lives for builders who are willing to stay small and specific. You do not need millions of users. You need a few dozen who rely on your tool every day and tell others about it because it simply works.

Early on I tried the standard SaaS model. Monthly subscriptions, tiered plans, usage limits. It felt clean but it did not match what I was selling. People were not buying software. They were buying back time.

Now I structure things differently. For tools that replace a specific manual task, I price per outcome. A tool that automates proposal generation gets a flat fee per proposal sent. A tool that handles client onboarding gets a fee per new client added. The user sees the cost line up directly with the value they receive. No surprises. No unused seats.

For tools that sit in the background and run continuously, I use a simple monthly fee based on volume. But I keep the entry point low. The first ten clients or the first hundred transactions are often free. I want people to experience the relief of not doing the work before they have to think about paying for it.

I am not a brilliant engineer. I learned enough to connect APIs and handle basic data transformations. Most of the tools I build are just a few hundred lines of code. A cron job here, a webhook there, a simple interface that accepts a file or a link.

The hard part is never the code. The hard part is understanding the task well enough to automate it without creating new problems. You have to sit with someone while they do the work and watch where they hesitate. Those hesitations are where the automation needs to be careful. A tool that moves too fast or assumes too much becomes a source of stress instead of relief.

I spend more time watching people work than I do writing code. It is the only way to build something that actually fits.

They had a client who needed weekly performance reports pulled from Google Analytics, Facebook Ads, and a CRM. Each report took about two hours to compile and format. The agency owner was doing it herself on Friday afternoons because she did not trust anyone else to get the numbers right.

I built a tool that pulled all the data at the same time each week, formatted it into a consistent template, and sent it directly to the client with no manual steps. The agency owner kept the relationship with her client. She stopped working Friday afternoons. She paid me a flat fee that was less than what she billed the client for the two hours.

That is the math that works. The tool pays for itself in the first week and the user never thinks about it again.

Every time I have tried to make a tool more general, more flexible, more configurable, I have regretted it. The complexity multiplies. The support requests multiply. The tool starts to require documentation and training and suddenly it is not a simple thing anymore.

I keep my tools narrow on purpose. If someone asks if the tool can also do this other thing, I say no. If enough people ask for the same thing, that becomes a separate tool with its own pricing and its own interface. I would rather have five small tools that each solve one problem well than one tool that tries to do five things poorly.

This also makes selling easier. I can show someone exactly what the tool does in thirty seconds. There is no discovery call. No demo. No proposal. Just a link to try it and a price that makes sense.

I used to think I needed a marketing plan. A launch. A waitlist. All the things people do when they are trying to build something big. But with these small tools, the selling is just conversation.

I ask people what they do every day that feels like a waste. I listen for the tasks they mention with a particular kind of tiredness. The thing they have been doing for years and have just accepted as part of the job. That is the thing to automate.

When I show them a solution, I do not talk about features. I talk about what their Friday afternoon could look like if that task was gone. That is the thing people actually buy. Not the code. The absence of the task.

Some of the tools I built never found an audience. I made an automation for a specific accounting workflow that I thought was common, but it turned out only three people needed it. I spent a week building it and made back my time in the first month but not much more.

I do not regret those tools. They taught me to ask better questions before I start building. Now I make sure at least three people have said they would pay for something before I write a single line of code. And I make sure those people are not friends or people who feel obligated to say yes.

The validation is simple. I describe what the tool will do and I tell them the price. If they say yes without hesitation, I build it. If they pause or ask for features or say they need to think about it, I wait.

I have been doing this for about eighteen months now. I have a handful of tools that each serve between ten and fifty businesses. None of them are growing fast. None of them have venture backing or a team. They just sit there quietly, doing their jobs, collecting payments, and occasionally sending me a support email that takes five minutes to answer.

I like this model. It does not ask me to be someone I am not. I do not have to pretend I am building the next big thing. I am just connecting things that should be connected and charging a fair price for the time saved.

If you are thinking about building something, I would start with a single conversation. Ask someone what they do every day that feels like a waste. See if you can take it away.

Until next week.

I am currently working on a tool that watches for price changes across supplier catalogs and alerts buyers when something drops below a threshold. It came out of a conversation with someone who runs a small manufacturing shop. If you have a problem like that, reply to this email. I am always looking for the next one.

The DTC beauty category is crowded. To break through, Jennifer Aniston’s brand LolaVie, worked with Roku Ads Manager to easily set up, test, and optimize CTV ad creatives. The campaign helped drive a big lift in sales and customer growth, helping LolaVie break through in the crowded beauty category.

Learn more

Next week: How I handle support for tools that have no interface.