You can imagine it. You can have it.

Custom software, automation, and websites.

For a long time, “we’d need custom software for that” was where the conversation ended. It isn’t anymore. Bespoke tools, automation, and websites, built by one person who learns your business first.

See the work What I build

Why now

Custom used to mean a team and a year. That’s the part that changed.

For most of my sixteen years doing this, the honest answer to “can we get software that works the way we actually work?” was: yes, and it will cost more than it’s worth. So businesses did what everyone does: bought something close enough and absorbed the gap with spreadsheets, sticky notes, and a lot of tedious labor.

That math is different now. AI leverage means one experienced builder can deliver what used to need a team, which puts a whole category of tool (too specific to sell to anyone else, too valuable to keep doing by hand) within reach for the first time. I still make every judgment call about what gets built and whether it’s right. The leverage changed; the accountability didn’t.

What I build

Two kinds of work, and they help each other.

Custom tools & automation

Usually it starts as a sentence like one of these:

  • “Someone rebuilds this report by hand every Monday.”
  • “These two systems don’t talk, so we retype between them.”
  • “We’ve been told we need the enterprise plan for one feature.”
  • “The spreadsheet works, but only one person understands it.”
  • “We know the answer’s in the data. Getting it out takes a day.”

Apps, integrations, data plumbing, and the unglamorous automation that quietly gives people their week back.

Websites

Still done properly.

The work that’s kept clients with me since 2010, and I still take it: fast, accessible sites that hold up, plus the maintenance and security oversight that keeps them that way.

The two tracks feed each other. The tooling I built to keep client sites updated safely is itself a custom software project, and it’s why site care here doesn’t look like anyone else’s.

How site care works

Selected work

Four projects, chosen because each one proves something different.

ProductionHero

Production management for film and TV

See productionhero.io

The problem. A production runs on crew lists, deliverables, schedules and paperwork that live in spreadsheets, email threads and someone’s memory. Nothing reconciles, and every question costs an afternoon.

What I built. A production management system (projects, crew, deliverables, scheduling) with LLM-assisted extraction that reads real production documents instead of asking people to retype them. FastAPI and PostgreSQL, server-rendered, deliberately boring where boring is a virtue.

What changed. One system of record that a production can actually run on, in daily use at Secret Weapon Studios.

Invoice payee matching

Knowing when not to use AI

The problem. Invoice payees had to be matched to existing people. An AI “deep match” field was doing it, and it was confidently wrong often enough that every result needed checking, which is worse than no automation at all.

What I built. I took the AI out. In its place, a deterministic rule ladder biased hard toward precision: a unique email match links automatically; a name match links only when it’s unique, strong, and corroborated by an exact phone match; everything else goes to a review queue. Every decision is explainable in one sentence.

What changed. It runs on automatic, because a false link is worse than a miss and the ladder is built to know the difference.

The 20-site update fleet

Safety at scale

The problem. Twenty-odd client WordPress sites need updates. Updating them by hand is a day of work; updating them carelessly is how you break someone’s business at 11pm.

What I built. An orchestration system that updates the whole fleet unattended: baseline screenshots at several widths, one change at a time, fresh screenshots compared against the baseline, and an automatic rollback the moment a page moves in a way it shouldn’t.

What changed. Whole-fleet updates in one sitting, with evidence for every site rather than hope.

sws-social

Small, sharp, and safe by default

The problem. Posting the same announcement to four social networks meant four logins, four formats, and four chances to publish the wrong draft.

What I built. One tool. Write once, review once, publish everywhere. Python standard library only: nothing to install, nothing to break in a year. A dry run is the default and --live is mandatory, so a half-remembered command reports instead of publishing. Credentials live in the system keychain, never in the repo.

What changed. A ten-minute chore became a ten-second one, and the embarrassing failure mode was designed out rather than warned about.

Websites & site care

Sixteen years of websites, and the tooling that keeps them safe.

A selection, not the whole catalogue.

Site care

Most maintenance pitches are built on fear: a statistic about hacked sites and outdated plugins. Here’s a better reason.

Your site gets updated by the fleet system described above. Before anything changes, it takes reference screenshots at several widths. It applies one update at a time, screenshots again, and compares. If a page shifts in a way it shouldn’t, the update rolls back automatically and I get told about it, usually before you’d have noticed. Backups, malware scanning and security patching come with it, and small content changes are included.

That’s the difference between hoping an update was fine and having evidence it was.

Ask about site care

How this goes

Starting is smaller than you think.

  1. A conversation

    You describe the problem in your own words. No spec needed: working out what to build is part of the job, not a prerequisite for hiring me.

  2. I go learn how you actually work

    The tool has to fit the real process, including the parts nobody wrote down. This is the step that decides whether the finished thing gets used or resented.

  3. Something working, early

    You get a rough but real version quickly, and we adjust against something you can click instead of something you have to imagine.

  4. Build, then hand over properly

    Documented, maintainable, and yours. If you want me to keep looking after it, I will; if you want to take it in-house, it won’t be a hostage.

Every project is quoted after step one, so you know the number before anything is committed.

Who I am

C.J. Ware

C.J. Ware

I came to software the long way round: teaching basic coding back in the early nineties, then mountaineering, ski patrol, and guiding, with building custom homes mixed in seasonally. I started CJBuilt in 2010 and have been writing software for clients ever since.

Building houses turns out to be good training for this. You learn to listen to how someone actually lives before you draw anything, that the details nobody notices are the ones holding the place up, and that whatever you build, somebody has to live in it afterwards.

I do the work myself. When you call, you get the person who wrote the code — and I still return calls the same day.

Get in touch

Describe it. I’ll build it.

You don’t need a spec, a budget, or the right words for it. A couple of sentences about the annoying part is plenty to start.