We wrote a checklist a while back about questions to ask an AI agency before you sign. One of them was whether they will ever tell you no. It seems fair to publish our own list rather than just recommend the question.
Software that already exists and works
Accounting. Payroll. Email marketing. Calendars. Generic support ticketing. These are markets where the available products have been refined for two decades against millions of businesses, and the gap between what they do and what you need is small.
We can build you a custom version. It will cost more, do less on day one, and you will own the maintenance forever. Buy the tool, connect it properly, and spend the money on the part of your operation that is actually unusual.
The line we use: build where you are different, buy where you are the same.
A rebuild of a process nobody has questioned
Sometimes we map out how work moves through a business and find several steps that exist because of a constraint that disappeared years ago. A form that gets printed to be signed to be scanned. An approval that exists because of one incident in 2019.
We will not quote a system that automates that faithfully. Automating a step that should be deleted makes it permanent, because now it is in software and removing it is a project. We would rather spend the first week arguing about the process and then build less.
Anything where the data is not ready
If the customer database has the same account four times and the status field means different things to different people, we will say so and propose fixing that first. Usually with no build attached.
It is a smaller invoice and an awkward conversation. It is also the only version where anything built afterwards produces numbers you can rely on.
The thing you saw in a demo
Demos are made under conditions you will never have. Clean data, a happy path, no exceptions, no angry customer at 4pm on a Friday. The distance between a demo and a production system is mostly exception handling, and exception handling is most of the cost.
We are happy to build the capability the demo implied. We will not agree to reproduce the demo, because the demo is not a thing that exists.
A project with no owner on your side
This is the one we hold hardest. If nobody at your company owns the outcome, it will not work regardless of the code.
Someone has to answer questions about edge cases, decide what the status field means, and say whether the thing is working once it is live. If that person cannot be named at the point of quoting, we would rather wait until they can.
Every failed build we have watched from the outside had no owner. Not a bad developer, not the wrong tool. Nobody whose job it was to care.
Work we would be learning on at your expense
If something sits far enough outside what we have done that you would be funding our education, we will say so and point you at someone better suited.
This costs us work. It also means that when we say we can do something, that statement is worth something, which is the only reputation worth having in a market this noisy.
Why publish this
Partly because it saves everybody time. Mostly because an agency that will not tell you no is not evaluating your problem, it is selling you inventory. Every yes from a shop like that is worth less, including the ones that were genuinely a good idea.
If your project is on this list, the conversation is still worth having. Some of these are timing problems rather than permanent noes, and a twenty minute call that ends in “fix your data first, call us in a month” is a good outcome for both of us.