Sites that load fast and convert
Custom builds and integrations
Bounded, auditable, human-approved
Being found, staying fast, staying safe
Somebody at your company has an AI idea, and somebody else is unconvinced. An audit settles it — with an examination of your actual data, your actual systems and your actual volumes, and a written recommendation that says build, fix something first, or don't.
This is the one service on this site we sell hoping the answer might be no. A short paid assessment that stops a bad project is worth more than the project, and we would rather be the firm that told you honestly than the one that took the build fee and delivered something nobody uses.
Drag up and down to change the bar ↓The questions
Every failed AI project we have been asked to rescue failed on one of these, and every one was answerable in the first fortnight for a fraction of what was eventually spent.
Not "we have a CRM" — does the specific information this idea depends on get recorded, consistently, in a place software can reach? Frequently it lives in someone's head or a column nobody fills in.
Checked by: pulling real records and counting the gaps.
Automation has a fixed cost to build and an ongoing cost to supervise. Below a certain frequency the arithmetic never closes, no matter how irritating the task is.
Checked by: counting occurrences over a real period.
If the answer to how a decision gets made is "it depends, ask Dave", there is nothing to encode yet. Sometimes the genuine first project is writing Dave's judgement down.
Checked by: sitting with the people who do it now.
An error tolerance question, not a technical one. Wrongly categorising an email is a shrug. Wrongly filing a regulatory return is not, and that changes the whole design.
Checked by: asking what happens on the worst day.
A vendor with no API, a database nobody has credentials for, a contract that forbids export. This is the assumption most likely to change a project's shape, and the cheapest to test early.
Checked by: attempting a real connection, not reading the brochure.
Something that runs unattended needs a named person who notices when it stops. Projects without one work for a quarter and are quietly abandoned by the next.
Checked by: asking for a name, and watching the room.
Interactive
The same six dimensions we assess, as a rough self-check. Answer honestly rather than optimistically — the point of the exercise is to find the weak one.
This is a simplified version of a real assessment and it will not substitute for looking at your systems. It is genuinely useful for one thing though: if it returns a low score, you already know what the audit would tell you, and you can go and fix that instead of paying anyone.
—
What this does not tell you. Whether your data is clean enough, whether the API you were promised actually works, or what it would cost. Those need someone looking at the real thing, which is what the audit is.
The product
A document, written in plain language, that a non-technical director can read and act on. Not a slide deck of possibilities.
It is written to be shown to whoever controls the budget, and to survive being read sceptically. Every number in it is either measured or explicitly labelled as an estimate with its assumptions stated.
Coverage
An audit looks at what you already run, not at what we would like to sell you. If the conclusion is that your existing subscription tools cover it, that is what the report says.
Models benchmarked
Business systems assessed for access
Data and infrastructure reviewed
Automation already in place
Situations
Rarely because somebody is curious about AI. Usually because a decision is stuck, or something has already gone wrong.
One director is certain this will transform the business, another is certain it is a fad. Both are arguing from instinct because nobody has looked at the actual numbers.
The most common reason
An agency has quoted a significant sum for an AI build. You want someone with no stake in the outcome to tell you whether the scope, the estimate and the assumptions are sound.
We do not bid on the work we review
A pilot that impressed in a demo and never made it into daily work. The question is whether it is fixable, and what specifically went wrong.
Usually a process problem, not a model one
A list of candidate projects and no basis for ranking them. Each gets scored on the same dimensions so the comparison is like for like.
Frequently reorders the list entirely
The question underneath most AI projects, asked directly. Real records examined for completeness, consistency and whether they say what people believe they say.
Sobering, and worth knowing
What staff may put into which tools, what must never leave your systems, who approves an AI-assisted output. Written down before a problem forces the conversation.
Usually already happening unmanaged
Honesty
Being clear about the limits is part of the product. An assessment that promises certainty is selling something else.
It establishes whether something is feasible and what it would take. Whether it delivers the value hoped for depends on execution and adoption, neither of which an audit controls.
It will tell you precisely what is wrong with your records and how much work sits between here and usable. Doing that work is a separate project, and usually a bigger one.
Ranges with stated assumptions, not a fixed price for work that has not been specified. Anyone quoting to the dollar before scoping is guessing with more confidence than we would.
Capability and pricing in this area move quarterly. Conclusions are anchored to what exists now, with a note on which of them are most likely to change.
If the real disagreement is about strategy, budget or who owns something, evidence rarely resolves it. We can only tell you what is true, not make anyone act on it.
Some questions — will staff actually use this, will customers accept it — are only answerable by putting something small in front of real people. The audit says which ones those are.
Process
Two to three weeks, a fixed fee agreed before it starts, and a short list of people we need an hour with.
An hour to establish what you are actually trying to decide. Surprisingly often this reframes the question before any work starts.
The people who do the work now, not only the people who commissioned the audit. The gap between those two accounts is usually where the finding is.
Real records, sampled from live systems, checked for completeness, consistency and whether the fields mean what everyone assumes.
What each platform will actually let you connect to. Tested by attempting it, rather than by reading the vendor's documentation.
How often the task really happens, how long it really takes, and what it really costs today — measured rather than estimated where possible.
Two or three routes, including the boring non-AI one and the do-nothing one, each with what it would cost and what it would not solve.
What could go wrong, how likely, how bad, and what would reduce it. Written so a non-technical reader can weigh it.
Delivered as a document you keep, with a clear recommendation on the first page rather than buried in an appendix.
A session to walk your team through it and be argued with. Disagreement at this stage is useful and welcome.
Questions
A meaningful share of our audits conclude that the idea should not be built, or should be replaced with something simpler — better process, a subscription tool, or a rule-based automation with no AI in it.
If that outcome would be inconvenient for us commercially, that is exactly why an independent assessment is worth paying for.
Yes, and it is a common request. We review the technical approach, the assumptions, what the scope leaves out and whether the estimate is plausible.
We do not bid on work we have reviewed. Being a potential beneficiary would make the review worthless.
Read-only access to relevant systems, a sample of real records, and an hour each with a handful of people. Where access is restricted we work from exports and note the limitation in the report.
We sign whatever confidentiality agreement you require before anything is shared.
A fixed fee agreed before the work starts, scaled to how many systems and processes are in scope. A single-process feasibility question is at the smaller end.
It is deliberately a fraction of any build it might lead to, because the whole point is that it can prevent one.
No, and the report is written to be handed to any competent developer. It belongs to you.
Some clients hand it to their in-house team, some to another firm, some to us. All three are fine outcomes.
Typically two to three weeks from the framing call, depending on how quickly interviews can be scheduled and how promptly access comes through.
Access delays are the usual reason for slipping, so we ask for it on day one.
Yes — a discovery version looks at where your time actually goes and identifies candidates, rather than assessing one you brought.
It tends to surface unglamorous, high-volume tasks nobody had thought of as automation candidates.
That is a common and useful finding. The report then says what specifically has to change first, in what order, and roughly what that involves.
Several clients have come back a year later having done exactly that, and the second answer was different.
Call back
Leave a number and a good time. We will call you back to talk about what you are trying to build — no charge for the conversation.
Or call us directly +1 (647) 385-5532