AI Automation

Most people entering this field build something impressive and then look for someone to sell it to. That order is backwards and it is the single most common reason these ventures fail.

Businesses pay to remove work that is repetitive, high-volume, and currently done by someone expensive. All three conditions matter. A task done once a month is not worth automating. A task done a thousand times a day by someone on minimum wage has a low ceiling on what you can charge. The money is in the middle: the operations manager spending eleven hours a week copying data between two systems, the practice that has a qualified professional writing the same report structure forty times a month.

Look for these specific signals when you're assessing a business:

• Someone is manually moving data between two pieces of software
• A qualified person is spending significant time on formatting or transcription
• Response times to customers are slow because a human has to read and route every enquiry
• The same document gets produced repeatedly with only the details changing
• Compliance or reporting work that follows a fixed structure

Note that none of these require the automation to be clever. The dullest automations are frequently the most profitable, because the business can articulate exactly what they cost and exactly what they'd save.

What businesses will not pay for, despite what the market suggests: automation of work that only takes an hour a week, automation that requires them to change how they operate, and automation of a process they can't clearly describe. If they can't describe it, you can't build it, and you certainly can't price it.

Exercise: Pick three businesses you have any connection to. For each, list every task you know is done manually and repeatedly. Rank by hours per month multiplied by the hourly cost of the person doing it. That number is your ceiling on price, and you should generally charge somewhere between 20% and 50% of the first year's saving.

There is a genuine skill floor here, and pretending otherwise sets people up to fail.

You do not need a computer science degree. You do need to be able to read an API specification, debug something when it breaks at 11pm, and understand what happens to data as it moves through a system. If you cannot currently do those things, the honest sequence is to learn basic programming first. Three to six months of consistent work gets most people to a usable level.

The no-code layer. Tools like Zapier, Make, and n8n connect services together without writing code. They are genuinely useful for simple, linear workflows and they let you deliver something in days rather than weeks. Their limits appear fast: error handling is weak, costs scale badly with volume, and you are dependent on whatever integrations the platform decides to support. Use these for prototypes and for small clients. Do not build a business that can only work inside them.

The code layer. Writing your own integrations gives you control over error handling, cost, and what happens when an upstream service changes. A workable modern stack for this kind of work is TypeScript for the application logic, a hosted Postgres database, and a serverless platform for scheduled jobs and webhooks. The specific tools matter less than the principle: own the parts that are hard to replace, rent the parts that aren't.

The model layer. Language models are one component, not the whole system. Most of the value in an automation is in the plumbing around the model — getting clean data in, validating what comes out, handling the cases where the model produces something unusable. Budget your time accordingly. If you spend 80% of a project on prompts, you have probably built something fragile.

A rule that will save you repeatedly: never let a model output go straight into a system of record without validation. Models produce plausible wrong answers, and plausible wrong answers in a client's database are how you lose the client.

A first automation, end to end. The pattern is always the same: a trigger, a transform, a write, and a notification. This is an inbox-to-CRM triage in about forty lines:

// Trigger: a webhook from the contact form
export async function POST(req: Request) {
  const enquiry = await req.json();

  // Transform: let the model do the judgement, not the plumbing
  const triage = await classify(enquiry.message);
  // → { intent: 'quote' | 'support' | 'spam', urgency: 1-5, summary: string }

  if (triage.intent === 'spam') return Response.json({ ok: true });

  // Write: one row, one source of truth
  await db.from('enquiries').insert({
    ...enquiry, intent: triage.intent, urgency: triage.urgency,
    summary: triage.summary,
  });

  // Notify: only when it is worth interrupting someone
  if (triage.urgency >= 4) await sendSlack(triage.summary);

  return Response.json({ ok: true });
}

The two rules that keep this alive in production. Always write the raw input to the database before the model touches it — when a classification is wrong you need the original to replay. And never let a model failure lose the record: if classify() throws, still insert the row with intent: 'unknown' and let a human look. The automation failing should degrade to the manual process, never to nothing.

The scope conversation determines whether a project is profitable. Everything downstream is execution.

Start by writing down what the system will do in the client's language, not yours. "When a new enquiry arrives in the inbox, it gets categorised, logged in the CRM, and a draft reply is prepared for review." That sentence is a scope. "An AI-powered enquiry management solution" is not — it's marketing copy, and you cannot defend it when the client asks for something you didn't anticipate.

Then write down, explicitly, what it will not do. This section is more valuable than the first one. It is where you put the things the client will assume are included: mobile access, historical data migration, integration with the second CRM they forgot to mention, custom reporting, training for their staff. Each of those is a separate line of work and each should either be priced or excluded in writing.

On fixed price versus day rate. Fixed price is better for both sides once you can estimate accurately, because it gives the client certainty and gives you the upside when you work efficiently. It is dangerous before you can estimate accurately, because you absorb every mistake. A reasonable progression is to start on day rate, track your actual hours against what you'd have quoted, and move to fixed price once your estimates are consistently within about 20%.

Structure the work in weekly increments. A week is short enough that a client can see progress and correct direction, and long enough to get real work done. Take payment for each increment before it starts. This does two things: it caps your exposure if the relationship goes wrong, and it filters out clients who were never going to pay. A client who hesitates at paying for week one will not become easier at week six.

On change requests. They are not a problem, they are a revenue stream — but only if there's a process. Every change gets written down, estimated, and either scheduled into a future increment or priced as an addition. The failure mode is absorbing changes verbally to keep things pleasant, then finding you've delivered 40% more than you quoted.

The scoping document that prevents the argument. One page, agreed before any code. It is not legal cover; it is the thing you both point at in month two:

IN SCOPE
  Enquiries arriving by web form and info@ inbox
  Classified into: quote / support / spam
  Written to the CRM within 60 seconds
  Slack alert for urgency 4-5 only

NOT IN SCOPE (quoted separately)
  Phone calls, WhatsApp, historic backlog
  Anything that sends a reply to the customer

DEFINITION OF DONE
  100 real enquiries processed, <5 misclassified,
  running unattended for 7 days

WHAT I NEED FROM YOU
  CRM API key, Slack workspace access,
  200 past enquiries with the right answer already known

That last line is the one people forget, and it is the one that sinks projects. You cannot measure "<5 misclassified" without labelled examples, and the client is the only person who has them. Ask on day one, not week three.

Clients buying automation are usually nervous, because they've either been burned before or they've read enough to be scared. Your delivery process is doing as much work as your code.

Make progress visible. Push work continuously rather than disappearing for three weeks and returning with a reveal. A client who can see steady movement doesn't need reassurance; a client in the dark invents worst cases. A short daily written update — what was done, what's next, anything blocking — costs you five minutes and prevents most relationship problems.

Sign off in writing at the end of each increment. Not a chat message saying "looks good." A short document listing what was delivered against what was scoped, with an explicit confirmation. This is unglamorous and it is what stops a dispute in month four about something agreed in month one.

Handle failure openly. Automations break. Upstream APIs change, edge cases appear, a model behaves differently after an update. The clients who stay are not the ones whose systems never broke — they're the ones who were told immediately and clearly when something did. Build monitoring in from the start and tell the client when it fires, before they notice.

Document the handover properly. What the system does, how to access it, what to do when specific things go wrong, and what the ongoing costs are. This feels like it reduces your leverage. It does the opposite: clients renew with people they trust, and nothing destroys trust like a system only you can understand.

The mistake almost everyone makes is pricing against their costs. Clients do not care what it costs you.

Price against the value of the outcome, with a sanity check against the alternatives available to the client. If a system saves a business £40,000 a year in staff time, a £15,000 build is straightforwardly good value and they will recognise it as such. The same build priced at £3,000 doesn't win you the work faster — it makes them doubt it will work.

Establish your floor. Take a completed project, count your real hours including admin, sales, and the parts that went wrong, and divide. That's your actual effective rate. Most people find it's substantially lower than their nominal day rate, because they've been ignoring unbilled time. Once you know the real number, you can tell whether a new opportunity is worth taking.

Use a small paid engagement as an entry point. A short, tightly-scoped piece of work — an assessment of where a business is losing time, delivered as a written document with costed recommendations — does several things at once. It gets money moving, it proves you can deliver, and it produces a scoped proposal for the larger build that the client has effectively co-written. Offset the fee against the full project if they proceed. The conversion rate on this is far higher than pitching a large build cold.

Instrument it or you are guessing. Every automation needs to answer "is it still working?" without anyone checking manually:

await db.from('runs').insert({
  job: 'enquiry-triage',
  ok: true,
  duration_ms: Date.now() - started,
  input_hash: hash(enquiry),      // replay without storing the payload twice
});

Then one scheduled query: did this run in the last hour, and was the failure rate under 2%? Alert on that, not on individual errors. An automation that fails silently is worse than no automation, because the business has already stopped doing the manual version.

Recurring revenue. Build projects are lumpy. Maintenance and monitoring retainers smooth that out and are genuinely valuable to the client — someone has to watch the system. Price these as a percentage of the build cost annually, and be honest about what's included. A retainer that quietly becomes unlimited support is worse than no retainer.

The difference between a well-paid contractor and a business is what accumulates.

Reuse aggressively. After a handful of projects you'll notice the same components recurring: authentication, scheduled jobs, error notification, document generation, data validation. Extract them. Every project after that starts from a higher baseline, which means you can quote the same price for less work. This is the entire economic engine of a small software business and it compounds quietly.

Specialise by problem, not by technology. "I build automation" is a commodity claim. "I build compliance reporting systems for UK electrical contractors" is a position. Specialisation lets you reuse more, estimate more accurately, charge more, and be findable. The fear is that specialising shrinks your market. In practice it shrinks your market and multiplies your conversion rate, and the second effect is larger.

Watch for regulation-driven demand. When a law changes and creates a new mandatory process for a category of business, demand arrives on a known date with a known deadline. That's a far better signal than trying to guess what people want. Track the legislative pipeline in whatever sector you serve.

Know when to stay small. Hiring is not automatically the next step. A solo operator with strong tooling can deliver work that would occupy several people at an agency, at agency prices, with none of the overhead. Growth in headcount often reduces income per person. Grow capability first, and only add people when there's genuinely more demand than tooling can absorb.