What it looks like when an AI agent development company argues against its own scope

On one project we told the client not to have us build the core of their system, and about one fifth of the scope went to an outside vendor on our recommendation. The reason was not politeness. With a fixed 63 working day deadline, a custom core would have eaten the schedule before anyone found out whether the product was wanted. This is not a rule we follow every time.

Every vendor in this category answers the question "can you deliver" the same way. The sentence is free, so it carries no information. What carries information is a recommendation that leaves you invoicing less, because a competitor cannot copy it off your website without having done it.

Two cases follow. In the first we made our own scope smaller. In the second we did work the client never paid for. We describe the mechanism only, with no project names and no vendor name, because that is the boundary agreed with those clients.

How to tell development companies apart when every profile reads the same

Search results for this category are dominated by roundup posts titled "the best AI agent development companies", and those roundups describe each firm in a sentence that would fit any other firm on the list. That is a problem for you, not for them: the list ranks vendors on things that never separate them, such as founding year, team size and a logo wall.

Three questions separate them, and none of them appears in a roundup.

The first: has this vendor ever recommended a smaller scope than the one you asked for, and what did it cost them? The second: what do they build themselves and what do they buy, and can they explain why the line falls there? The third: what happens to the schedule when a third party is slow, and who absorbs that.

Answers to all three are checkable before you sign anything, on one small paid stage.

What exactly we gave away

The client wanted a voice agent as a fully owned, independent component. Not an add-on, but the core of the system, eventually free of any outside dependency. The brief was clear and we could have taken all of it.

We advised against building the voice engine from scratch on our side. Instead we proposed a core built on an established external voice provider, with the rest of the system, meaning logic, integrations, admin panel and data, staying with us. Scope that could have been ours went to someone else because we suggested it.

The client did not give up independence. They moved it later: the custom component gets built after validation, not before. The system runs on the external provider today, and the decision about a custom core waits for the point where there is a reason to make it.

Why a custom core before validation is a bad purchase

A properly tested core is several weeks of work. Not a working demo, but a component you can trust with a real conversation with a real customer. On a project with a 63 working day deadline, those weeks take a large share of the schedule, and they take it at the start, when nobody yet knows whether the product interests anyone in that shape.

The second reason mattered more than time, and it is the one that settled the conversation. A custom voice agent makes us responsible for every mistake in every conversation. With a business hypothesis nobody has confirmed, the client would be carrying the technical risk of a component whose value is still unknown. The external provider builds the voice layer as their main product, so that risk sits with them.

Time came third. The order matters, because an argument about deadlines sounds like a vendor excuse, while an argument about risk describes what happens to the client's money.

The second case went the other way

On another project the client arrived with a scope that had no mechanism for managing consent under data protection rules. Not through carelessness. When you plan a first version you think about features, not about what is required to release those features lawfully.

We added a consent module from our own resources: versioning and confirmation of consents. It was not in the quote and the client did not pay for it. It cost us a few days of work, reduced by reusable code from earlier projects of this type.

Without that module the problem would not have surfaced immediately. It would have surfaced at the worst possible moment, after validation in a closed beta, when moving to a wider group of users. Instead of scaling a product whose value was already confirmed, the client would have had to stop and build a layer nobody had planned for.

What both decisions cost us

The first cost about one fifth of the project. That was not a peripheral nicety to hand over. It was the core of the system, the part a vendor usually wants to keep most.

The second cost a few days of unpaid work. Smaller, but real: hours nobody paid for, done because without them the product was not fit to launch.

We put the numbers in because without them this is just a story about how pleasant we are. One fifth of a project is a specific hole in an invoice. If you are reading this as sales material, this is the point to stop and ask whether a recommendation like that gets made in order to look honest. The answer is: test it on a small paid stage before you sign a large one.

When we do not do this

We do not argue scope down every time. We argue it down when two things are true at once: a component eats the schedule before validation, and its value is not yet confirmed. With a confirmed hypothesis and a product that already has users, building a custom core is often exactly the right call.

We also do not add out of scope work as a gesture. We add it when the product is not fit to launch without it, and when we know that earlier than the client does, because we have seen it in previous projects. That is the difference between a gift and fixing something that has to be fixed anyway.

Before you write to us

We do not promise that every project has scope worth giving away. On most of them there is nothing to hand over and all the work stays with us. We also do not run projects where the scope is closed before the first conversation about risk, because then there is no way for us to propose the change that saves you money.

If you are building a first version and want to see what a conversation about scope looks like before you sign: see what an AI MVP covers. The price and the deadline are stated there.