Why I Build My Own Workforce Tooling (and What Stays Off the Stack)

I run a one-person company that operates like a small agency. The way I do that is not magic, and it is not heroic individual effort. It is a workforce of tooling I have built up over years, layer by layer, that does most of the work a small team would do, with me at the centre making the decisions that actually matter.

People ask me what I use. The honest answer is that I build most of it myself and buy a small, deliberate set of things. This is the breakdown of what I build, what I buy, and why I have settled into that balance.

What 'workforce tooling' actually means for a solo operator

When I say workforce tooling, I do not mean automation. Automation is a piece of it. I mean the whole set of systems that absorb the work a team would do.

For a solo operator running serious volume, the workforce tooling stack covers at least three categories:

Briefing systems. The thing that tells the next part of the pipeline what to do, with enough context to do it well. In a real team, this is a manager. For me, it is a written brief, a structured prompt, or a generated playbook that flows into the next stage automatically.

Decision logs. The thing that records what you chose, why, and what the outcome was, so that future decisions are informed by past ones. In a real team, this is a senior person's memory. For me, it is a database, a structured note system, and a discipline of writing things down even when no one is asking.

Autonomous routines. The thing that actually does the work without you having to be present. In a real team, this is the doer. For me, it is a combination of scheduled jobs, AI agents wired into workflows, and decision trees that handle most of what arrives in the inbox without me opening it.

If you only have one or two of those three, you have automation, not a workforce. The combination is what makes solo operation at agency scale possible.

Five categories I built myself

These are the parts of my workforce stack that I built rather than bought. The pattern across all of them: they are too specific to my business to delegate to a generic SaaS, and they compound in value the longer I use them.

1. The briefing layer. I built my own internal brief format that every piece of work runs through. Sales outreach gets a brief. Content gets a brief. Client work gets a brief. The brief is generated, reviewed, and then handed to whichever part of the stack does the work. Off-the-shelf project management tools assumed I had a team to manage. I did not. I needed a brief generator, not a Kanban board.

2. The decision log. Every meaningful decision I make on a client, a product, or a tool gets written into a structured log. The log feeds back into the next decision of the same type. After two years of doing this, the log is one of the highest-value assets in the business, because it lets me make consistent decisions without remembering everything.

3. The orchestration engine. This is the thing that ties all the other pieces together. When a lead comes in, the orchestration engine routes it to enrichment, then scoring, then a draft proposal, then a notification to me. I tried three different off-the-shelf tools before building my own, because no tool let me wire together exactly the steps I needed in exactly the order I needed them without paying for 95 percent of features I would never use.

4. The CRM extensions. I run on a standard CRM under the hood, but the actual day-to-day interface is custom. The standard CRM is too generic and the custom layer is where the productivity lives. This is the bit I tell other operators to build only if they have real volume. Below a certain point, the off-the-shelf CRM is fine.

5. The reporting layer. My business metrics live in a structured database that I built and feed myself. Standard reporting tools either showed me too little or asked me to format my data to suit them. I flipped it, structured the data the way I needed, and now generate reports against that structure when I want them.

Three things I deliberately buy

I do not build everything. There are some categories where buying is the right answer.

1. Email infrastructure. Sending email reliably at any volume is a specialist problem. I would have to spend years learning what a dedicated provider already knows. I pay for sending, I pay for inbox placement, and I do not regret a penny of it. The upside of building this myself is zero. The downside is real and visible.

2. The AI model itself. I will build the wrapper, the prompt layer, and the orchestration around the model. I will not build the model. That is a billion-dollar problem and there are several excellent companies who have solved it. I buy access from Anthropic Claude and ChatGPT and move on.

3. Payments. Same logic as email. The risk and complexity of running my own payment infrastructure is enormous. The cost of using a reliable provider is small. I buy and never look back.

The thing nobody tells you about building your own stack

The cost of building your own workforce tooling is not the build. The build is the cheap part now, especially with AI to help. The cost is the maintenance, the integration debt, and the discipline required to keep using your own tools when they are 80 percent done and the SaaS alternative is 95 percent done.

I will be honest. There were periods where my own stack lost to the SaaS option on user experience. The thing that kept me on my own stack was not pride. It was that the SaaS option could not be customised for the specific shape of my business, and the friction of working around its assumptions cost more time than the slightly worse UI of my own version.

The threshold I use now: if a SaaS tool covers more than 80 percent of my workflow as-is, and the workflow is not strategically important to differentiate, I buy. If a tool would force me to redesign my workflow to fit theirs, and the workflow is core to how I work, I build.

The playbook

If you want to start building your own workforce stack, this is the order I would do it in.

1. Write down every routine activity you do in a week. Count how many minutes each takes.
2. Identify the three with the highest weekly time cost that are not strategic decisions.
3. For each, decide whether to build, buy, or eliminate. Eliminate first, buy second, build third.
4. For the ones you build, start with a brief generator and a decision log. Those two compound first.
5. Re-audit every six months. Some things you built will be ready to be replaced by something off the shelf. Some things you bought will have outgrown the vendor.

The aim is not to be self-sufficient. The aim is to design a workforce that fits the shape of how you actually work, where the boundary between you and the tooling is exactly where it needs to be and nowhere else.

For more on the infrastructure that sits underneath this stack, my self-hosted infrastructure starter kit covers the layers. For how I think about evaluating individual tools, the four hooks I use to decide self-host versus SaaS is the framework. More about how I work is on the about page.

For the institutional parallel of how this scales to a managed-services operation, UKFM is the same thinking applied at a larger scale.

Built by Weir Digital Media.