Staff Augmentation Example: How I Accidentally Built Full Scale
In this article
- What staff augmentation actually looks like in practice
- The first staff augmentation example I ever ran was an accident
- The bigger example: building a 20+ developer team for Stackify
- That team was a key reason Stackify exited in 2021
- From the example to an actual business
- When this model is the right call
- What this example tells you
- Frequently Asked Questions
I never planned to start Full Scale. The staff augmentation example I want to walk you through is the one that turned into the company I run today.
In 2018, I needed to hire ten more developers for Stackify. Local hiring in Kansas City wasn’t going to get me there fast enough. A friend had developers in the Philippines, so we set up a small office together and started building. By 2021, that team had grown past 20 people and was a big reason Stackify exited. Friends saw it working and asked for access. We hired 100 developers in the first year of the company that grew out of it.
Staff augmentation is the practice of hiring developers to work directly on your team long-term, instead of handing off a project to an outside firm. That’s the textbook definition. The rest of this post is what it looked like when I built it, what made it work, and when it’s the right call for someone else.
What staff augmentation actually looks like in practice
The clean definition: you hire individual developers who join your team, attend your standups, push to your repo, and report up to your engineering leadership. The agency or staffing company handles recruiting, payroll, benefits, and HR. You handle the work. For a Microsoft-stack team, that is how you hire dedicated C# developers without standing up a local recruiting function.
That’s it. That’s the whole model. We aren’t in this for some 3-month project. We’re trying to extend an engineering team that already exists.
The reason this trips people up is that the SERP for any “offshore” or “outsourced” term mixes two very different things together. Project outsourcing is the other one. Both involve outside developers, both can be remote, and both can be offshore. The differences only show up when you list them side by side:
| Staff augmentation | Project outsourcing | |
|---|---|---|
| What you buy | A developer on your team | A finished deliverable |
| Contract length | Months to years, ongoing | Defined by the project |
| Who runs the work | Your engineering leadership | The vendor |
| What happens when priorities shift | The team pivots with you | You renegotiate scope |
| Where the knowledge lives | On your team | With the vendor |
For more on that distinction, I wrote a longer comparison of staff augmentation vs. outsourcing recently. The short version: outsourcing is right for scoped deliverables you don’t want a full-time person on after the work is done. Staff augmentation is right when the code outlives the contract.
The first staff augmentation example I ever ran was an accident
Long before the Philippines team, I had a quieter version of the same model running at Stackify. We were building application performance monitoring software and needed Java developers for the Linux side of the product. I had to scramble for talent; today I would just hire experienced Java developers from our Philippines bench and skip the scramble. My team and I were all C# developers, and there were almost no Java developers available in Kansas City who wanted to work on infrastructure tooling. The same crunch hits every one of the top software companies in Kansas City.
A friend ran a dev agency and told me he had Java developers I could use. I trusted his vetting, didn’t interview the developers myself, and we got to work.
The first phone call is the one I remember. The two engineers were in St. Petersburg, Russia.
I was a little perturbed at first because nobody had mentioned that part. I was also surprised we were paying Kansas City rates for developers offshore, since I’d assumed offshore meant cheaper. (This was 2012, well before the Ukraine conflict. I would not hire developers in Russia today.) But the English was strong, the code quality was excellent, and we worked with that pair for about two years.
That was the first time I realized this model could work. I hadn’t read about staff augmentation as a strategy or made some careful build-vs-buy decision. I needed Java developers, my friend’s firm had them, and they happened to be in another country. The fact that it kept working is what made me try it again on purpose.
The bigger example: building a 20+ developer team for Stackify
The Russia experience changed how I thought about hiring. By 2018, Stackify needed to support multiple programming languages and I needed to hire about ten more developers. We were lightly funded, which meant I had to find the most affordable way to do it without losing quality.
A different friend had developers in the Philippines. The two Filipinos I knew personally were the nicest people I’d ever met, with impeccable English. That was enough for me to take the meeting.
The Philippines was cheaper than Latin America, with stronger English than most of Eastern Europe, and a work culture where people routinely shifted to evening hours to overlap with US business hours. The Kansas City to Manila time zone gap is 14 hours, which sounds like a problem and turned out to be a feature. Half the team’s hours overlapped mine, and the other half meant on-call coverage no local-only team could match. When something broke at 2am Central, somebody was already at their desk.
In 2018, my friend and I opened a small office there. The team grew past 20 developers over the next three years.
How it actually ran day to day is the part most blog posts skip. There was no project manager between me and the team. There was no SOW. We ran standups on the same Slack as everyone else, code reviews in the same GitHub, and our lead developers in Kansas City each managed two to five offshore developers directly. The Filipino team was Stackify in every way except where the W-2 was filed. Hire talent to work directly for you on a long-term basis. Don’t hire them just for a project. That’s the whole rule.
You can read the longer version of how I got there in the Feb 2024 newsletter on why I avoided offshore for years.
That team was a key reason Stackify exited in 2021
When Stackify sold in 2021, the Philippines team was a big part of why we got there. We supported more languages, shipped features faster, and ran on-call coverage no local-only team could match, all on a burn rate that would have been impossible if I’d tried to hire ten more Java and C# developers in Kansas City instead.
The reason I bring this up isn’t to brag about the exit. It’s that most offshore stories I hear are bad because companies hired projects, not people. They sent a spec to a firm in another country, waited a quarter, got back code they had to rewrite, and concluded offshore doesn’t work. Offshore worked fine; what didn’t work was the contract structure wrapped around it. (For the budget side of that argument, see my post on how to justify offshore development to your CFO.)
From the example to an actual business
Here’s the part that still feels accidental in retrospect. When we set up the Philippines office in 2018, we set it up as its own company. That was a tax and structure decision more than a strategic one. But because it was its own company, when friends and connections started asking how to access the same developer pool, there was already a shell ready to handle it.
We hired 100 developers in the first year of that accidental business. That business is Full Scale.
The model that worked for Stackify works for the 200+ tech companies we’ve worked with since. AMC Theatres runs a global engineering organization where developers in the Philippines are full AMC engineers, not contractors, sitting in the same Slack threads and the same code review process. LendingStandard, a Kansas City commercial real estate platform that handles roughly 30% of affordable multifamily property loans nationwide, came to us because local hiring couldn’t keep up with their growth. Same model. Different company. Same result.
Our developer retention sits north of 93%, which matters because the whole point is continuity. Staff augmentation done badly turns over every six months and you’re back to onboarding strangers. Done right, the team you have in year three is the team you had in year one, just deeper.
When this model is the right call
Three things had to be true for staff augmentation to work at Stackify, and they’re the same three things I look for when somebody asks me whether it’ll work for them. I wrote them up in detail in the Feb 2024 newsletter; the short version is:
- You have technical leadership in-house. You always need technical leadership in-house. Without a CTO, VP Engineering, or strong tech lead, you have nobody to direct the offshore team and you need a vendor to own outcomes instead. That’s outsourcing, not staff augmentation. The two models exist for different companies.
- You’re building a product, not shipping a project. If the code lives on after the contract ends, staff augmentation. If it’s a one-time deliverable, outsource it. I’ve personally outsourced WordPress builds and an Elasticsearch project, because I didn’t need a full-time WordPress or Elasticsearch person on staff after the work was done. That’s the right job for project outsourcing. Don’t confuse it for what you do with your core product.
- You’re willing to run a hybrid local plus offshore team. If your company can afford it and you have existing local talent, augmenting them with offshore is always the best formula. One local lead managing two to five offshore developers is a structure that just works. It’s how we did it at Stackify and it’s how most of our clients do it now.
One thing worth noting on the geography. About 90% of software developers don’t live in the United States, per the Stack Overflow Developer Survey. The talent is overwhelmingly elsewhere. The question is whether you’ve set up your team to actually work with it.
What this example tells you
The reason I’m comfortable recommending staff augmentation is that it’s the company I ended up running, which is the strongest validation of the model I can give. Staff augmentation is the right way. If you’re trying to scale your engineering team and the work is product, not project, here’s where we’d start.
Frequently Asked Questions
What is an example of staff augmentation?
Hiring a senior developer to work directly on your team for six months instead of handing a project to an outside firm. They join your standups, review your code, and ship features on your roadmap. The 20+ Filipino developers we hired at Stackify between 2018 and 2021 were the same thing on a larger scale.
How is staff augmentation different from outsourcing?
Outsourcing hands a vendor a defined deliverable and they go build it. Staff augmentation hires the developer directly onto your team long-term. With outsourcing you buy a project; with staff augmentation you build a team. The staff augmentation vs. outsourcing comparison covers the tradeoffs.
When should a company use staff augmentation?
When you have technical leadership in-house, you’re building an ongoing product, and you need to scale faster than local hiring allows. When the work is a scoped deliverable that won’t have a future, outsource the project. I’ve made both calls myself and the model has to match the work.
What companies use staff augmentation?
Hundreds of product companies, from VC-backed startups to public companies. We’ve worked with over 200 of them at Full Scale, including AMC Theatres and LendingStandard. The pattern is the same: a CTO or VP Engineering who needs engineering capacity but doesn’t want to manage a vendor relationship.
