I started as a writer.Today I build the systems companies depend on.
I take responsibility for the digital systems small companies depend on and cannot staff for. That means the website, the search visibility, the internal tools, and increasingly the software itself.
It also means deciding what should be built, which is the part most people in this position do not do.
Then it turned into building.
I started as a writer. Five years of content marketing, SEO strategy and copywriting for B2B and SaaS companies taught me something more useful than how to write well — how to work out what a company is actually selling and why the market is not hearing it.
That turned into strategy work. Positioning, messaging, content operations, go-to-market. I was still writing, but the writing had become downstream of a diagnosis.
I expected it to be a detour. It was not.
I took a break, and during it I started building software. I now build products and internal systems, working with AI coding agents rather than writing most of the code by hand.
The first thing I built that mattered was a workforce management platform for Multiphase Projects. Their recruitment operation ran on spreadsheets, email threads and shared folders. It now runs on a platform with three role-gated portals, structured credential tracking, placement and onboarding workflows, and an audit trail. It is live, and real candidates and client organisations use it.
I also built BriefStack, an AI tool that produces content briefs and deliberately refuses to write the content, because the bottleneck in content operations was never producing words.
The pattern across both is the same, and it took me a while to see it.
In each case there was a business rule that could not be compromised. At Multiphase, clients must be able to evaluate real professionals without ever being able to identify them, because the company’s whole business is being the intermediary. At BriefStack, the product must not generate content, because generating content lets a team skip the thinking and still produce output.
Both of those are business judgements before they are technical ones. And in both cases the job was to hold the rule firmly enough that it survived contact with the build, which meant encoding it as a constraint the system was constructed against rather than a preference someone remembered.
That is the thing I am good at. Most people you could hire will either understand your customers or build your systems. The value of hiring me is that the system you end up with is the one the business actually needed.
I am not a software engineer and I do not present as one. I define the problem, make the product decisions, and direct an AI-assisted build. I read the code, I make the calls, and I am responsible for the result. I did not personally write most of it.
I have also not launched and grown a commercial product of my own. I have built systems that work and that people use. Those are different claims and I would rather make the accurate one.
I prefer ongoing responsibility to one-off projects.
The work I am proudest of came from staying with a company long enough to understand it, which is not something a two-week engagement produces.
I work with established small and mid-sized companies that depend on digital systems and have no one internally who owns them. Too small for a technical hire, too operational to keep ignoring it.
If that is your situation, I am worth a conversation.
The value of hiring me is that the system you end up with is the one the business actually needed.
If that’s your situation, it’s worth a conversation.
Let’s Talk