AI Services
Custom AI tools and micro-SaaS
A custom AI tool does one job extremely well: processing your documents, drafting in your voice, analysing your data, answering from your knowledge base. We build small, focused tools where off-the-shelf AI products almost fit but not quite.
Who it is for: Teams with a repetitive knowledge task that generic AI tools handle badly, and founders with a micro-SaaS idea that needs building properly.
Everything in this service
- Scoping to define the one job the tool must nail
- Custom interface built around your workflow
- The right model for the job, connected via API
- Grounding on your own data where accuracy matters
- Deployment, access control and usage monitoring
What to expect
- A task that took hours now takes minutes
- Output quality that generic tools could not reach
- A tool you own, priced by build, not per seat forever
How custom ai tools actually works
Scope one job and refuse the rest
The tools that succeed do one thing. Extract the figures from supplier invoices. Draft a first-pass response to a specific kind of enquiry. Summarise a call transcript into the fields your CRM expects. Check a document against a checklist. Each of those has a clear input, a clear output and an obvious way to tell whether it worked.
The tools that fail are the ones described as an assistant for the team. That description hides the fact that nobody has decided what it does, which means quality cannot be measured, the interface cannot be designed, and the first version disappoints everyone in a different way. Breadth is what makes general chat tools inconsistent, and rebuilding that breadth in-house reproduces the problem with a smaller budget.
Scoping properly means writing down the task in a sentence, collecting real examples of the input in its actual messy state, and agreeing what a good output looks like well enough that two people would grade the same result the same way. If that last part cannot be done, the tool is not ready to build, because there is no way to know when it is finished.
- State the job in one sentence with a clear input and output
- Collect real, messy examples rather than tidy sample data
- Agree what good looks like precisely enough to grade consistently
- Refuse scope creep during the build, add it as a second tool later
- If success cannot be defined, the tool is not ready to start
When a spreadsheet is the better answer
A large share of the ideas that arrive as AI tool requests are not AI problems. They are missing-process problems, missing-integration problems or missing-report problems, and the AI framing is doing the work of hiding that. Saying so is part of the service, and it usually saves the client money.
The honest test is whether the task involves reading unstructured language, unpredictable formats or judgment about meaning. If the answer is no, then rules, a database view, a properly built form or a connection between two existing tools will be cheaper, faster, exactly repeatable and far easier to maintain. A model that produces the right answer most of the time is worse than a formula that produces it always.
The other frequent answer is that a product already exists. If a well-maintained tool covers ninety percent of your requirement at a reasonable price, building your own version of it to capture the last ten is rarely a good trade once maintenance is counted. Building makes sense when the workflow is genuinely specific to you, when per-seat pricing has grown past the cost of owning something, or when the data cannot go where the product wants to put it. We would rather tell you to buy or to skip than take a build fee for something you will regret.
- No unstructured language or judgment usually means no AI needed
- Deterministic rules beat a model that is usually right
- Check whether an existing product covers most of the requirement
- Build when the workflow is specific, pricing has outgrown you, or data cannot move
- Expect an honest recommendation to buy or skip when that is the right call
Evaluation before rollout, not after
The step that separates a dependable tool from a demo is evaluation: a fixed set of real examples with agreed correct outputs, run against every version of the tool, scored the same way each time. Without it, quality is a matter of opinion and every change is a gamble, because improving one kind of input often quietly damages another.
Building the set is unglamorous and worth the effort. Gather enough real cases to cover the ordinary and the awkward. Include the ones that go wrong, the badly scanned document, the enquiry with three questions in it, the record with a missing field. Have a person who knows the work write the expected output. Then score, and decide in advance what score is good enough to ship, because a tool that is right most of the time may be perfectly acceptable for drafting and completely unacceptable for anything that goes out unchecked.
The same set makes maintenance possible. When a model is updated, a prompt is changed or a new document type appears, you re-run the evaluation and see what moved instead of finding out through complaints. It is the single highest-value artefact of the project, and we hand it over with the tool.
- Build a fixed test set of real cases with agreed correct answers
- Include the awkward inputs, not just the clean ones
- Agree the passing standard before building, not after seeing results
- Re-run the set after every change, models and prompts both drift
- Treat the evaluation set as a deliverable you own
Guardrails, review steps and cost control
A tool that is right ninety percent of the time is useful or dangerous depending entirely on what happens to the other ten. That is a design decision, not a model limitation, and it is where most of the engineering effort in a good build goes.
The practical patterns are few. Have the tool express uncertainty and route low-confidence cases to a person rather than pushing everything through at the same level. Keep a human approval step wherever output goes to a customer or into a system of record. Validate structured output before it is used, so a malformed date or a missing reference is caught rather than written into your CRM. Constrain what the tool will discuss, so a document-processing tool does not answer general questions. And log inputs and outputs so a wrong result can be traced rather than argued about.
Cost needs the same treatment. Usage-based pricing means an unattended loop or a badly formed batch can produce a bill nobody expected. Per-user and per-day limits, alerts at defined thresholds, and caching of repeated work are cheap to add at build time and awkward to retrofit. We treat these as core features rather than extras, because a tool without them is one bad afternoon away from being switched off.
- Route low-confidence cases to a person instead of pushing them through
- Keep human approval where output reaches customers or records
- Validate structured output before anything writes it anywhere
- Log inputs and outputs so errors can be traced
- Set usage limits and alerts before launch, not after a surprise bill
Interface design is most of the perceived quality
Two tools using the same model can feel completely different, and the difference is usually the interface. A tool that fits the way the work is actually done gets used. A tool that requires people to leave their normal flow, paste things between windows and remember a format gets abandoned within weeks regardless of how good the output is.
The details that matter are small. Accept input in the form it already exists, which often means a file upload or a paste rather than a form with twelve fields. Show progress on anything that takes more than a moment. Make output editable in place, since the realistic use is a person accepting most of it and changing part. Keep a history so work is not lost. And where the tool is uncertain, say so visibly rather than presenting every result with the same confidence.
Feedback is worth building in from the first version. A simple way to mark a result as wrong, with a note, turns everyday use into a stream of real failure cases. Those cases feed the evaluation set and tell you what to improve next, which is far more reliable than asking people how it is going.
- Fit the existing workflow rather than asking people to change it
- Accept input in its natural form, minimise typing
- Make output editable in place, expect partial acceptance
- Show uncertainty visibly instead of a uniform confident tone
- Build a one-click way to report a bad result, with a note
Maintenance as models and data change
A custom AI tool is a living system with more moving parts than ordinary software. Models are updated and retired on the provider timetable, not yours. Behaviour can shift between versions in ways that are improvements on average and regressions for your specific task. Pricing changes. Your own inputs change too, as a supplier redesigns an invoice or a new document type enters the process.
Building for that from the start keeps the cost manageable. Keep the model behind a boundary so it can be swapped without rewriting the tool. Keep prompts in one place, versioned, rather than scattered through the code. Keep the evaluation set current so a swap can be judged rather than guessed. And pin to a specific model version where you can, so an update happens when you choose to test it.
Then plan for periodic review. Re-run the evaluation, check the failure reports that have come in from real use, look at cost per run against the value it produces, and decide whether a newer model would do the job better or cheaper. This is a modest ongoing commitment, and it is the difference between a tool that stays useful for years and one that quietly degrades until people go back to doing the task by hand.
- Keep the model swappable behind a clear boundary
- Version prompts in one place, not scattered through the code
- Pin model versions so updates happen on your schedule
- Re-run evaluations after any model or prompt change
- Review cost per run against the value the tool produces
Data handling, access and ownership
Custom tools handle real business data, which raises questions worth settling in writing before a line is written. Which data does the tool see. Where is it processed. How long is it retained, by you and by any provider. Who can use the tool. And what happens to all of it if you stop.
The answers we work to are straightforward. Processing happens under commercial terms that exclude your data from model training. Retention is set deliberately and kept short unless there is a reason otherwise. Access is restricted by role, so a tool that reads sensitive documents is not open to everyone with a company login. Where requirements are strict, the tool can run inside your own environment. And logs, which are necessary for debugging, are themselves subject to retention limits because a log of every input is a copy of the data.
On ownership, the position should be plain. The tool, the prompts, the evaluation set and the documentation are yours. You should be able to take the whole thing to another supplier or maintain it in-house without a dependency on us. Anything that turns into a legal question about your obligations goes to your own advisers, and we will give them a clear description of what the system does so they can answer it properly.
- Settle data flow, retention and access in writing before the build
- Use terms that exclude your data from model training
- Restrict access by role, not by company login
- Apply retention limits to logs as well as to data
- Own the code, prompts, evaluation set and documentation outright
A clear path, step by step
- 01
Define the job
One task, defined precisely, with real examples of input and the output you need.
- 02
Prototype fast
A working prototype on your real data within weeks, so quality is proven early.
- 03
Harden
Edge cases, guardrails, access control and cost limits, so the tool is dependable.
- 04
Deploy and monitor
Live for your team or customers, with usage and quality tracked.
Why choose us for this
We prototype on your real data before you commit to the full build
Model-agnostic: the best engine for the job, swappable later
Guardrails and cost controls treated as core features
Common questions
Why not just use ChatGPT for this?
General tools need skilled prompting, forget your context and produce inconsistent output. A custom tool encodes the prompt engineering, your data and your quality checks once, so anyone on the team gets expert-level output every time.
How do you keep our data private?
Your data is processed under API terms that exclude it from model training, access is restricted to your team, and where requirements are strict we can deploy in your own cloud. Data handling is agreed in writing before the build.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase