AI Automation Services

AI agents and LLM pipelines

An AI step earns its place when a task needs judgment that rules cannot capture: reading an email and deciding what it is about, extracting fields from a messy document, or drafting a first version that a person then edits. I build these steps with Claude and Codex and wire them into a workflow so the output lands somewhere useful.

The part that matters most is what surrounds the model. I give it structured inputs, ask for structured outputs, check those outputs before anything downstream depends on them, and put a human approval step wherever a wrong answer would be expensive. The content pipeline on my work page is an example: AI writes and fact-checks the draft, and an editor approves or rejects every article, with rejections going back to the AI along with the editor’s notes.

Another example is the AI video ad studio I built, which coordinates several AI providers behind a single submit button, tracks each job’s state while it runs, and delivers the finished files with a Slack notification.

Automations built in code

Most businesses have a chain like this somewhere: an order comes in through one system, someone copies it into a spreadsheet, someone else updates the CRM, and a third person posts a summary in Slack. Each step is small, and together they eat hours every week and introduce errors.

I replace that chain with a single automation. It listens for the trigger, moves and transforms the data, checks it, and posts the result where your team needs it. When something does not match, it flags the record for a person instead of guessing. A product manager I work with described this part of my work as simplifying processes that are scattered across multiple systems and combining them into a single automation.

Typical automations include:

• Routing new leads from forms and ads into a CRM, with an alert to the right person
• Syncing records between tools that do not talk to each other
• Pulling data from several sources into one daily or weekly report
• Reconciling two sources of the same numbers and flagging the differences
• Sending notifications and follow-ups when a status changes

I write these in TypeScript and Python with AI coding tools rather than wiring them together in a visual builder. With AI writing much of the code, a coded automation now takes about as long to build as a drag-and-drop one, and it comes with tests, version history and no limits on logic. If your team already runs n8n or Make, I can maintain those workflows or move them into code when they outgrow the builder.

Custom web apps and dashboards

Sometimes the right answer is not another connector between existing tools but a small app built around how your business actually runs. I build these in Next.js with Supabase for the database and authentication, deployed on Vercel or Cloudflare.

Examples I have shipped include an AI product photography platform with order intake, in-line review comments and bulk download; a gym management system with a QR check-in kiosk and role-based staff dashboard; and a multi-tenant work management platform where each client’s workspace is isolated at the database level. You can see all three on the page about systems I have shipped.

Custom apps take longer than workflows, so I scope them in phases. The first phase delivers the one screen or flow that removes the most manual work, and later phases build on it once it is in daily use.

Scrapers and data pipelines

When the data you need lives on websites rather than in an API, a scraper collects it on a schedule. I build these with Playwright and Apify, run them on GitHub Actions or a small server, and deliver results as a daily digest, a spreadsheet or rows in your database.

Scrapers break when a site changes its layout, so I design them to make failure obvious. A digest that suddenly comes back empty tells you to check the source rather than leaving a silent gap in your data.

How I decide what to automate first

Not every manual task is worth automating. Before quoting, I look at each candidate process through four questions, and the answers decide the order of work.

• How often does it happen? A task done fifty times a week pays back an automation far sooner than one done monthly.
• How stable are the rules? Processes that change every few weeks are expensive to automate. I stabilise the process on paper first.
• What does a mistake cost? Where an error is cheap to fix, the automation can run on its own. Where it is expensive, I add a review step.
• Do the tools allow it? An API makes the job straightforward. No API means browser automation, which works but needs more care.

The first build is usually the process that scores well on all four: frequent, stable, low-risk and well connected. It proves the approach on something real, and the next automations reuse what it set up.