Internal Tools & Automation

Every business has a process that runs on a spreadsheet, a shared folder, and somebody's memory. It works, roughly. It also takes four hours a week, breaks when that person is on holiday, and nobody can tell you how many times it ran last month.

That is the work I replace.

What this actually looks like

Not enterprise software. Usually something small and specific that removes one recurring job:

• A dashboard that pulls numbers from the systems you already use, so nobody rebuilds the same report every Monday
• A tool that turns a messy export into the format another system needs
• A script that runs on a schedule instead of a person remembering
• An internal app that replaces a spreadsheet several people edit at once and overwrite each other in

The test is simple: after it exists, does someone stop doing something by hand?

Things I have built

A company-wide email signature generator. A browser tool that takes a CSV of employees and produces consistent, branded signatures for every one of them. Built for a full rollout across a company — no server, no accounts, no data leaving the machine it runs on.

An automotive dealer page auditor. An open-source tool that audits dealership pages and is built to run across large dealer groups at scale, rather than one URL at a time.

A browser-based SEO audit tool. Paste a page, get technical, structural, and performance findings back. No server, no signup.

Nexus OS. My own AI operating system — agentic workflows on the Claude API running agency, SaaS, and daily-operations lanes. It is where I test the patterns before I put them in front of a client.

All of these are in Selected Work, most with source you can read.

Why several of those run entirely in the browser

A surprising number of internal tools do not need a server, a login, or a database. When a tool runs entirely in the browser:

• There is no infrastructure to pay for or patch
• Employee data never leaves the machine — which matters for HR exports, customer lists, and anything you would rather not upload to a vendor
• There is nothing to breach, because nothing is stored
• It still works in three years when nobody remembers the admin password

I reach for this first and only add a backend when the job genuinely requires one — shared state, scheduled runs, permissions, or an audit trail.

How I scope it

The fastest way to waste money here is to automate a process nobody has looked at properly. So the first step is not code:

1. Watch the actual process. Who does it, how often, what they open, where it goes wrong.
2. Decide what not to build. Some steps should be deleted, not automated. Some should stay manual because they involve judgement.
3. Build the smallest useful version, put it in front of the person who does the job, and fix what they hit.
4. Then extend it — once it is being used, not before.

This is the same process I use on larger builds, compressed. Most internal tools are small enough that a first working version arrives quickly.

What you should expect to get

• Something the intended person can use without training beyond a short walkthrough
• Documentation of what it does and how to change it
• Source code you own
• No dependency on me to keep it running

That last one is deliberate. A tool that only works while I am reachable is a liability, not an asset.

Who this is for

Ops and marketing teams doing repetitive work that a machine should do. Businesses at the size where the spreadsheet has started to creak but a full software purchase is overkill. Teams who have been quoted for a platform when what they needed was one tool.

I work with clients in Cincinnati and nationwide.

Have a process that eats hours every week? Describe it — what it is, who does it today, and how often. I reply within one business day.