How Far Can You Delegate to a Development Vendor? What to Leave to Them and What to Keep

In system development, delegating everything means leaving post-order decisions and confirmations almost entirely to the vendor, with little involvement from the ordering company. Handing technical implementation to the vendor's expertise is reasonable on its own, but handing over business decisions as well raises the risk that the finished system will not fit actual operations. This article looks at the two sides of delegation, contrasts what can be left to the vendor with what the ordering company needs to retain, and outlines what an appropriate level of involvement looks like.

Small and midsize businesses often lack staff dedicated to information systems, so a person unfamiliar with how development projects proceed may assume it is best to leave all the technical matters to the vendor, which can end up looking a lot like full delegation. In addition, for a staff member juggling ordering duties alongside their regular job, reviewing and deciding on every item can feel burdensome, and it is easy to keep putting it off.

A development vendor brings expertise in technical areas such as design, implementation, and testing, but only the ordering company truly understands its own workflows, actual users, and priorities. The technical means of how to build something can reasonably be left to the vendor, while the business decisions of what to build and what to prioritize need to remain with the ordering company. When this boundary is left unclear and everything is delegated, the result is often a system that is technically sound but does not fit the business.

Delegation becomes a problem not because technical work is left to the vendor, but because confirmation and decision-making are abandoned along with it. There are three areas of involvement the ordering company should maintain at minimum.

- Weekly (or biweekly) progress check-ins: Have progress and issues shared through regular meetings or reports
- Reviewing demos and prototypes: Look at in-progress screens and functionality to catch gaps in the intended end result early
- Gathering on-site feedback: Regularly collect input from the people who will actually use the system and pass it on to the vendor

When delegation goes too far, mismatches with the intended end result often surface only near completion, leading to major rework and additional costs. The typical structure behind additional costs is discussed in Preventing Extra Cost Trouble. On the other hand, when the ordering company gets too involved in the technical details of implementation, the vendor's expertise cannot be put to full use, which can lower development efficiency and blur accountability. Keeping an appropriate balance of involvement matters on both sides.

- Have technical decisions been separated from business decisions?
- Have weekly or biweekly progress check-ins been scheduled?
- Have review points for demos or prototypes been decided in advance?
- Is there a mechanism to gather feedback from on-site staff?
- Have acceptance criteria been agreed on with the vendor in advance?
- Does the contract clearly define each side's responsibilities? (see Development Contract Basics)

Delegation makes sense in that it puts the vendor's technical expertise to use, but handing over business decisions as well tends to lead to mismatches after completion. Maintaining a minimum level of involvement — weekly check-ins, demo reviews, and gathering on-site feedback — while not overstepping into technical implementation details, is a practical way to keep the risks of delegation in check. For the full ordering process, see The Complete Guide to Ordering System Development.