Three kinds of vendors
Search for help automating a task and you will find three kinds of company. Each is good at something. The mistake is hiring one kind for the other kind's work.
No-code agencies build on a platform of ready-made connectors. If your task moves clean data between two products the platform already supports, they are fast and cheap, and there is nothing wrong with that. The trouble starts at the edges. A web portal with no connector, a legacy system that only exports files, an exception the tool has no block for: each of these becomes a workaround, and the workarounds pile up. You also pay for the platform every month, for as long as the automation runs, and the price usually climbs with volume.
IT firms adding automation already know your network, your logins and your servers, which matters more than it sounds. They can see the systems the task touches and they are already on the hook when something breaks. The catch is that automation is a side line. The people doing it are also resetting passwords and replacing switches, the work is often billed by the hour, and a task that needs real software gets built the way a ticket gets closed.
Custom builders write code against whatever you have: the portal, the old system, the file that arrives in a different shape every week. A good one scopes the work, gives you a fixed price, and hands you something you own. They cost more up front than a no-code build, and the thing to check is what happens after the build is done. Ask who maintains it, how they find out when it breaks, and what that costs.
CBIT is the third kind. We say that early so you can read the rest with that in mind.
Eight questions to ask any of them
Ask these of every vendor, including us. The answers sort the three kinds faster than any sales call.
- Who writes the code? A good answer names a person, not a platform. If the answer is a tool with a drag-and-drop editor, ask what happens when your task needs something the tool does not have a block for.
- Fixed or hourly? Hourly is fine for a two-day job with a clear end. For anything else, a fixed price after they have seen the task is the honest answer, because it puts the risk of misjudging the work on the vendor, not on you.
- Who owns it? You should. The code, the documentation and the accounts it runs under. If the answer involves a license fee that keeps running after the build is paid for, you are renting, not buying.
- What happens when the portal changes? It will. A good vendor says so up front, tells you how they find out, and tells you what a fix costs. A vendor who has never had a portal change under them has not been doing this long.
- Can you work without an API? Listen for care, not bravado. A good answer is: where a system offers an API, EDI or a file exchange, we use it. Where the only way in is a web portal built for people, we review that portal's terms with you first and work through your own authorized login. Anyone who treats scraping as a selling point has not thought about what happens when the portal's owner notices.
- Will you tell me what not to automate? The best answer is a story about a task they turned down. A vendor whose every answer is yes is selling hours, not outcomes.
- What will actually be running two weeks in? Not a slide, not a demo, not a design document. Something real, doing part of the job in your operation. If they cannot describe that, ask why.
- What does upkeep cost? Every automation needs some. A clear answer gives you a monthly figure or a fixed price per fix, and says what is covered and what is not. A vague answer here becomes a surprise invoice later.
When a no-code tool or a spreadsheet is the right answer
Sometimes it is, and a vendor who says otherwise is not looking after you. The signs are easy to spot.
- The inputs are clean. The same columns, the same format, every time.
- Both systems have native connectors, or one of them is a spreadsheet you already keep.
- The volume is low. A handful of records a day, not a file of thousands.
- The rule fits in one line. "If the status is late, send this email."
- Nobody needs to be paged when it fails. If it can wait until someone notices on Monday, it does not need a monitored system behind it.
If all five are true, buy the tool, spend an afternoon on it, and keep the money. If two or three are false, the tool will work until the day it does not, and that day is usually the one when the file changes shape.
When CBIT isn't the right fit
We would rather say this here than on a call after you have spent an hour with us.
- You want one tool rolled out across the whole company. That is a software selection and a training project. It is not what we do.
- You need hourly staff augmentation: a developer on your team for six months, billed by the day. We build fixed-scope work and hand it over.
- The work is rare. A task that happens twice a year is not worth automating, and we will say so. The same goes for a model when there is no history to train it on.
- You need it tomorrow. A quick task takes days, not hours, and anything larger takes weeks. If the deadline is this week, a spreadsheet and a checklist will serve you better.
How we answer the eight questions
We write the code ourselves. You get a fixed quote before work begins, and the first deliverable is running in your operation within 7 days for a quick task, 14 for a single-task automation and 30 for a larger workflow, phone agent or custom app. You own the code and the documentation. Upkeep is either the optional managed plan or a fixed quote for each fix as it comes up, your choice. When a task is not worth automating, we tell you. The published bands are on the pricing page. If you have a dozen candidate tasks and do not know where to start, the Automation Inventory is an optional half-day session, $500, credited toward your first build, that ranks them by what each one costs you. And if the question is whether your task needs AI at all, start with automation vs. AI.