Most of the companies we work with already have a development team, and a good one. They are not looking for somebody to take a project away and hand it back finished. They have a product they know intimately, a roadmap they are committed to, and developers who understand the codebase better than any outsider will. What they have run into is narrower than that: a piece of work their team has never done before, or more work than the people they have can get through in the time available.
That is what software development team augmentation is for. You keep your team, your product and your decisions. You add specific capability alongside them, for as long as it is useful, and then you stop. It is the model behind a large share of the work we do, and this article covers how it actually works in practice, drawing on projects we can point at rather than on theory.
The Two Reasons Companies Augment a Team
In our experience there are only two reasons anybody does this, and they are worth separating because they lead to different engagements.
The first is expertise. There is something in the roadmap that nobody on the team has built before, and learning it properly would take months that the business does not want to spend. This is the more common of the two in our work, largely because the areas we specialise in — WOPI, SharePoint Embedded, Office Add-Ins — are ones most teams meet once, build once, and never touch again. It makes very little sense to build that knowledge in-house permanently.
Corcentric is a clear example. They provide procurement, accounts payable and accounts receivable software, and, as their case study puts it, they have significant in-house skills to develop their core products. When they decided to embed Microsoft Office inside their web application using WOPI, the constraint was not general engineering capability — it was that WOPI is a specialist protocol with very little published guidance outside the .NET world, and they needed a Laravel PHP implementation running in a clustered cloud environment. The gap was specific and bounded, which is exactly the shape that suits augmentation.
The second reason is capacity. The team knows how to do the work; there is simply too much of it, and hiring takes months you do not have. AuditBoard came to us in this position with a twist: they had already begun building their Microsoft Add-In and found it was popular with their customers. The decision was to accelerate it, and they brought us in as specialist Add-In developers to do that. Nobody was replaced. The work simply went faster.
Often it is both at once — a specialism the team lacks, on a timescale that would not survive a hiring round.
What It Looks Like Day to Day
The part that decides whether an augmented team works is unglamorous: whose tools, whose process, whose standards.
Our answer is yours. On the AuditBoard engagement we worked directly in their Jira, their Figma and their other core systems, and participated directly in their Agile planning process. That is not a detail — it is the whole thing. A team that keeps its own board, runs its own sprints and reports progress in a weekly summary is not augmenting anybody; it is a separate supplier with a friendlier name. If your planning meeting does not contain our developers, we are not in your team.
The same goes for the direction of advice. Because we had built add-ins before, we were able to give AuditBoard more than development hours — recommendations on good practice, on submission to Microsoft, and on complying with the AppSource guidelines. That advisory element tends to be where a lot of the value sits, and it only surfaces when the people doing the work are close enough to your decisions to see them being made.
Working With In-House Developers, Not Around Them
The risk everybody worries about is friction: outside developers who do not respect the existing architecture, or who quietly build a parallel version of everything.
Two of our clients have spoken to this publicly. Rob Keynes, Product Manager at Workiro, described the engagement this way:
Their deep expertise in WOPI and Microsoft Outlook Add-Ins was exactly what we needed to push our platform forward. They quickly integrated with our team, collaborated closely on user experience, and helped us update our microservices architecture for WOPI and the Add-In.
Andreas Pfanner, Head of Software Development at Kendox AG, made a similar point:
McKenna’s ability to collaborate closely with our in-house developers — particularly around integrating with our existing microservices architecture and aligning with our UX goals — was invaluable.
Both mention the same two things, and they are the things that matter: working with the architecture that already exists rather than alongside it, and taking the client’s design goals as the brief rather than substituting our own. Kendox needed a WOPI implementation that worked reliably across both their SaaS and on-premise environments while meeting the standards of Microsoft’s Cloud Storage Partner Program. That constraint came from them. Our job was to meet it inside their system, not to propose a cleaner system.
It is also worth saying that augmentation does not always mean augmenting the engineering team alone. On the Astrak Group eCommerce platform, their CIO Stephen Cope singled out how closely we worked with their customers during the build, and put the resulting user experience down to that. Sometimes the capability a team is missing is the time to sit with the people who will use the thing.
The Knowledge Has to Stay Behind
An augmented team that leaves a codebase nobody internally understands has failed, however good the code is. This is the clearest practical difference between augmentation and outsourcing, and it is worth being blunt about: if your developers are not working next to ours throughout, the knowledge does not transfer, no matter how thorough the handover document.
Working in your tools and your planning process is what makes the transfer happen as a by-product rather than as an event at the end. Your developers see the decisions being made and the reasons for them. By the time we leave, the work is not a black box, and your team can carry it forward without us. That is the outcome to aim for, and it is worth checking that any partner you are considering is aiming for it too — the incentive does not always point that way.
It Does Not Have to Be Continuous
One thing that surprises people is how well this works in short bursts. Clients who have taken a product fully back in-house come back to us when they hit a peak — a release with a hard date, a customer commitment that landed sooner than planned — and we redeploy for a few weeks. For a known quantity of work with a known end, that is usually a better deal than recruiting temporary staff, and considerably faster.
It also means the relationship does not have to be all or nothing at the outset. A first engagement scoped to one specialist piece of work tells you far more about whether a partner fits your team than any amount of due diligence will.
Augmentation Is Not Outsourcing
The two get used interchangeably and they are not the same thing.
Outsourcing hands a defined piece of work to an external organisation to deliver against a specification. Control sits with the supplier for the duration, communication runs through a contract and a project manager, and success is measured against the spec that was agreed at the start.
Augmentation puts external people inside your team. You keep control of the product and the day-to-day decisions. Communication is whatever your team already uses. Success is measured the way you measure your own team’s work, because for the duration it is your team’s work.
Outsourcing is the better model when the work is genuinely separable, the specification is stable, and you do not need the capability afterwards. Augmentation is better when the work touches your core product, when the specification will move as you learn, and when you want your own people to come out of it knowing more than they did.
When Augmentation Is the Wrong Answer
It is not always the right model, and it is worth saying so.
If you have no in-house development team at all, there is nothing to augment — you need a partner who will own delivery, which is a different engagement with different reporting. If the work is genuinely self-contained and you will never need to maintain it yourself, the overhead of integrating outside developers into your process is not worth paying. And if your team is already at capacity managing its own work, adding people will slow things down before it speeds them up; augmentation costs your senior developers time in the early weeks, and that has to be budgeted for honestly.
Where to Start
If you are weighing this up, the useful first question is not “who could we bring in” but “which of the two problems do we actually have” — a capability gap, or a capacity gap. The answer changes what you should look for. A capability gap wants a specialist who has built the specific thing before and can leave the knowledge behind. A capacity gap wants people who can pick up your stack and your process quickly and add throughput without adding management overhead.
If it is the first, and the specialism is Microsoft document integration, systems integration or B2B eCommerce, that is the ground we know best. Tell us what you are trying to do and we will tell you honestly whether we are the right fit.
Sources
- Microsoft Learn — Publish an app to AppSource, for the AppSource submission requirements referenced in the AuditBoard engagement.
- Microsoft Learn — Office Add-in submission guide, for what Microsoft validates before an add-in is listed.
- Microsoft Learn — Cloud Storage Partner Program, for the CSPP standards referenced in the Kendox engagement.
Client engagement details and quotations in this article are taken from our own published case studies for Corcentric, AuditBoard, Workiro, Kendox and Astrak Group.
