I start by checking whether AI is worth doing here. Sometimes the answer is no.
A lot of what gets sold as AI never pays for itself, so I start from the work: one job that gets done over and over, looked at properly, and a written answer on whether software should take it over. You do not need any technical knowledge for that conversation.
One process, one conversation, and my view of whether AI would take that work off someone. It is the smallest AI job you can order here.
What it is
A conversation about the work itself
One process walked through step by step, the way it runs today
The data it uses, the tools it passes through, the decisions inside it and the exceptions that break it
An NDA first, if you would rather sign one before showing me anything
What you get back
Where AI would take real work off someone
Where a simpler change would do the same job without a model
What I would build first, and in what order
What I would not automate, and why
Who it suits
Anyone doing the same task several times a week
Anyone retyping the same information from one place into another
One-person companies as much as firms with an IT department
Anyone who has been told they should be doing something with AI and wants a straight answer
How to start
You do not have to prepare anything. Two sentences about the work that takes the most time in your week are enough. If it turns out there is nothing here worth building, you will have lost an afternoon and learned where not to spend money.
Worth reading first
How the audit works, and when a chatbot on a company website pays off, are two separate articles on the blog.
The same four steps every time. Choosing a tool comes after the process is on paper.
One process, with something at stake.
I pick a single job where the stake is clear: time, how often it repeats, what an error costs, or what a customer feels. Only one, because a pilot that touches everything is hard to judge afterwards.
Map it before choosing a model.
I write down the data it uses, the tools it passes through, the decisions inside it and the exceptions that break it. Most AI pilots that fizzle out skipped this step.
Build a small flow that runs in production.
Input, context, the action it takes, the point where a person steps in, and a way to measure whether it did the job. It is small, and it handles real cases from day one.
Test on real examples, then extend.
I run it on cases that have already been handled and compare what it did against what a person did. It gets a second job only once the first one holds.
One job, end to end
Example flow
A supplier invoice reaches the inbox. The system reads the fields, checks them against the order, updates the CRM and routes mismatches to a person for approval.
Somebody opens an email, reads four numbers off a PDF, compares them with what was ordered, types them into another system and files the PDF. A few minutes each time, dozens of times a month, and nobody notices the work until something goes wrong.
Each part of that flow does a different job. A model reads the document, because it copes with a badly scanned PDF better than ordinary code does. Ordinary code does the comparing and the writing, because a comparison has to give the same answer every time. The last part matters most: when the invoice and the order disagree, the flow stops and shows the case to a person, and those are the only cases that need anyone's attention.
First I run the flow over invoices that have already been processed and compare its results with what was done by hand. It handles live documents only once the two match.
What I build
Six things. Each one is a job somebody is doing by hand today.
Assistants. A chat window that answers customer or sales questions from your own materials and nothing else.
Task agents. Software that carries one multi-step job through the tools you already use, and stops for approval where it should stop.
Integrations. The CRM, the mailbox and the helpdesk you already pay for, connected so the same information is not typed in twice.
Documents. Invoices, contracts and forms read automatically: the fields pulled out, the document filed under the right label, and findable a year later.
Reporting and alerts. A summary written in plain sentences, and a message when a number moves in a way somebody should look at.
Prompt libraries and training. Prompts written for your actual tasks, kept in one place you own, and a session that teaches the people who will use them.
Where this already runs
Asystent PV is my own chat assistant for solar installers, live at asystentpv.pl. It answers customers under the company's name, says when it does not know and passes the question to the office. You can ask it something right now. The same build goes onto another company's offer, prices and questions.
Money leaving, a contract, an answer to a customer that cannot be taken back: the flow prepares it and a person releases it. That step is part of the flow's code, so the model cannot talk its way past it.
Quality is measured before anything is given more to do.
Before a flow gets more work, I measure on your own examples how many cases it handled without a person and how many it got wrong.
It runs on your data, in your tools.
I build inside the systems you already have: your CRM, your mailbox, your server.
You can see what it did.
Every automated action is written to a log a person can read afterwards. When something looks off, you and I start from the same record.
The answer is allowed to be no.
If the audit finds AI would not take real work off anyone, the note says so and suggests what would help more. You read it before any build starts.
Tools, and where they stop
The tools I reach for most often.
Workflows
n8n
Scheduled and triggered runs
Human approval steps
Readable logs
Small jobs
Zapier
Make
Forms and inboxes
Spreadsheets and shared drives
What it connects to
CRM
Email and helpdesk
Documents and files
Reports and alerts
Underneath
Node.js
Google Cloud Run
MySQL and PostgreSQL
Supabase
Where AI is not worth it
Plenty of steps do not need a model at all. If a rule with three conditions gives the same answer every time, it beats a model that is right most of the time, and it never surprises anyone on a Monday morning. Where the job is small enough that custom code would be the wrong answer, I wire it up in Zapier or Make and write nothing. And where the honest fix is a better form, a tidier spreadsheet or one fewer step, I will tell you that.
Selected work
Four projects that run every day. Each write-up shows what was built and how it works.