Small dev shops lose money on enterprise clients because the enterprise engagement comes with governance overhead, communication complexity, and scope management demands that the dev shop was never resourced to handle. The dev work is priced correctly. The work around the dev work is not priced at all, and it absorbs more time than the billable work does.
When a small dev shop prices an enterprise engagement, they price the development work. They factor in the technical requirements, the complexity, the testing, the delivery timeline. What they rarely factor in is everything else.
Enterprise clients come with internal IT divisions that want to be involved in every integration decision. They come with procurement teams that require documentation the dev shop has never had to produce before. They come with executives who need briefings in non-technical language, finance teams who have reconciliation requirements, security teams who change access controls mid-engagement without notifying anyone.
None of this is development work. All of it lands on the dev shop anyway, because the dev shop is the only party in the engagement who has ownership of the delivery. That work is not billable under the original SOW. It is absorbed. And it adds up faster than most dev shops expect.
Large institutions do not communicate efficiently. They have multiple stakeholders with competing priorities, internal political dynamics that affect every decision, and a tendency to route communication through whoever is most responsive rather than whoever is most appropriate.
For a small dev shop without a managed communication layer, this means the developer becomes the default contact point for every institutional stakeholder who wants a faster answer. Each contact is brief. Each contact is individually manageable. Collectively, they consume hours of developer time every week, time that was priced for development work.
The communication overhead compounds. Once an enterprise stakeholder has established a direct line to a developer, they use it. Other stakeholders notice and use it too. By the middle of the engagement, the developer is managing more stakeholder communication than development, and the dev shop is bleeding margin.
Enterprise clients do not add scope maliciously. They add scope because they have legitimate needs that emerge as the engagement progresses, because the original requirements documentation was incomplete, and because the people adding scope often do not know they are doing it.
The result is the same regardless of intent. Work gets done that was not priced. Hours get absorbed that were not budgeted. The original SOW, which may have looked profitable at signing, turns into an engagement where the dev shop is working for less than their day rate by the end.
The thing that prevents this is a clear SOW with explicit scope boundaries and an enforced change control process. For most small dev shops, writing a tight SOW is something they do once or twice a year. For enterprise procurement teams, it is their daily work. That asymmetry has a predictable result.
For more on what a well-structured SOW covers, see what a SOW should cover for an enterprise client.
The most damaging enterprise engagement is not the one that goes visibly wrong from the start. It is the one that looks fine until the final third of the delivery.
By that point, the dev shop has already absorbed months of unscoped work. The developer has built a relationship with the enterprise stakeholders that makes it politically difficult to draw a line. The SOW is vague enough that both sides can make a reasonable argument about what is in scope. And the dev shop needs the project completed and paid before they can close the engagement.
That is when the enterprise finds its position. That is when additional requirements get framed as defects. That is when UAT cycles extend beyond anything that was agreed. And that is when the dev shop, already underwater and needing the final payment, agrees to absorb what they should not have to absorb.
Preventing this outcome does not require a different type of client. It requires a different engagement structure for the clients you already have.
That means a SOW reviewed before signature for exactly the kind of clauses that create exposure. It means a managed communication layer between the enterprise stakeholders and the development team. It means a liaison who can attend the institutional meetings, manage the enterprise's internal politics, and hold the scope boundary without making the enterprise feel adversarial.
A Contract Readiness Review addresses the first of these before the engagement starts. If the engagement has already started and the pattern is already visible, engagement recovery addresses it mid-delivery. For more on what a structured pre-signature review covers, see what a Contract Readiness Review involves.
Whether the engagement has not started yet or is already absorbing work it should not be, the structure to fix it is the same. It starts with a conversation about exactly where the exposure is.
Read next
Pushing back on scope creep from an enterprise client requires a documented position, the right communication layer, and a framing that protects the relationship while drawing a clear line.
Read moreWhen enterprise clients bypass the liaison and contact developers directly, it creates scope exposure, communication risk, and developer burnout that compounds quickly.
Read more