Every growing organization hits the same wall: there is more to build than the team can deliver, and the way through is one of three choices, hire, outsource, or augment, and the right one depends on whether the work is yours to keep and whether you have the leadership to direct it. This post covers the one question that sorts the three, a worked example, the traps we see most in the Kingdom, and how to start.
None of the three is “the” answer. Hiring is slow and brutal in a competitive market. Outsourcing is fast, but you can lose control and capability. Augmenting is flexible, but easy to do badly. So let’s make it a decision you can walk through, instead of a vibe.
The one question that sorts the three options
Start with one question: is this a core, permanent capability? If yes, own it. If no, ask a second: do you have the leadership to direct the work? That second answer separates augmentation from outsourcing, and it is the one most owners skip.
flowchart TD
A(["You need more engineering capacity"]) --> B{"Is this a core, permanent capability?"}
B -->|Yes| C(["Hire and build in-house"])
B -->|No| D{"Do you have the leadership to direct the work?"}
D -->|Yes| E(["Augment with embedded engineers"])
D -->|No| F(["Outsource a well-defined, time-bound scope"])
Follow the chart and here is what sits behind each box.
Hire and build in-house when the capability is yours to keep
- It is core and permanent. You will need it for years, not months. The platform your customers log into, the pricing engine, the data model your reporting sits on.
- You are building institutional knowledge you want to hold onto. Every decision and every “why is it like this” lives in people’s heads. Those heads should be on your payroll.
- You can actually attract and keep the talent. That is a real constraint in the Kingdom’s competitive market, and a good reason to invest in local capability on purpose.
In-house is the slowest to stand up and the most valuable to own. For the systems that are your business, it is usually right even though it costs more. The trap is hiring your way out of a short-term crunch: a seat that takes, say, four months to fill does nothing for a deadline in six weeks.
Outsource when the scope is small enough to specify and verify
- The scope is clear and time-bound. A data migration, a payments integration, a compliance module with a known spec. Something with an end.
- You need a whole capability you don’t plan to keep. You will never have a full-time team for it, so renting one is honest.
- You can specify and verify the outcome. If you cannot write down what “done” looks like, you cannot buy it.
Vague scope plus outsourcing is a classic way to fail, and the data backs the instinct to keep scope tight. The Standish Group’s CHAOS research finds that roughly 31% of projects succeed, ~50% are “challenged” (late/over budget/under scope), ~19% fail outright, and that small projects succeed far more often than large ones (Standish, via InfoQ). At the large end it gets worse: a McKinsey and Oxford study of 5,400+ IT projects found that large IT projects (initial budget > $15M) run on average 45% over budget and deliver 56% less value than predicted (McKinsey, 2012). If the thing you want to outsource is big and fuzzy, break it into pieces you can verify one at a time, and score the vendor on the outcome, not the slide deck. We covered that in how to write a technical RFP that gets you the right vendor.
The risk is dependency, and a hole in your capability the day they walk out. You manage it by keeping ownership in-house even when someone else does the building: your repositories, your cloud accounts, your architecture decisions, and a handover your own people have actually run.
Augment when you have the direction but not the hands
- You have leadership and a plan. Someone on your side owns the roadmap, the architecture, and the priorities. You just need more capacity or specific skills.
- You want to move fast now while you hire for the long term. Embedded engineers start in weeks; permanent hires take months. Run both in parallel and let the outside capacity taper off as seats fill.
- You want to keep control and grow your own people alongside the help. Pair every outside engineer with one of yours. The knowledge transfer is the point.
Done well, that means engineers embedded inside your team and your process: your standups, your code review, your repositories. Not a sealed black box you toss requirements at. Done badly, it is just outsourcing with extra steps, and you inherit the dependency without the fixed price.
If you do not have that leadership yet, an interim CTO or embedded technical lead is often the cheapest fix: it turns an outsourcing problem into an augmentation one.
A worked example, and the lens behind it
Say you need four more engineers for a year to rebuild a customer app and integrate a payments provider. The numbers are made up to show the shape.
- Hire only. In Riyadh a good senior seat takes, say, three to four months to fill, and you fill them one at a time. You get perhaps 20 engineer-months of the 48 you planned, and the app ships half a year late.
- Outsource only. A vendor quotes a fixed price and delivers at month nine. Then your team of three inherits a codebase nobody inside has seen, and the first production incident takes a week because the people who understood it are on another client.
- Augment, and hire in parallel. Four embedded engineers start in three weeks, working in your repositories under your lead. You hire two permanent engineers by month six, and they pair with the embedded ones. By month twelve, two of the four roll off, the app is live, and your two hires can maintain it.
The third option is not always cheapest on the invoice. It is cheapest on what matters: the capability you are left holding at the end.
Step back and the lens behind all three is simple. Own the systems that make you different, and own the leadership. Rent raw capacity and commodity work.
quadrantChart title Own it or rent it x-axis Commodity work --> Differentiating work y-axis Short-lived need --> Permanent need quadrant-1 Hire and own quadrant-2 Augment, then hire quadrant-3 Outsource a fixed scope quadrant-4 Augment under your lead "Core product platform": [0.85, 0.85] "Pricing and data model": [0.75, 0.9] "Security operations": [0.3, 0.8] "Payments integration": [0.5, 0.35] "Data migration": [0.2, 0.15] "One-off app rebuild": [0.7, 0.3]
Where this goes wrong
- Outsourcing the thinking. The vendor decides the architecture, and you find out at the end. Rent hands, never the judgment about what your business needs.
- Augmentation that is outsourcing in disguise. Outside engineers on their own ticketing system, repositories, and standup. If your team cannot see the work happening, it is not augmentation.
- Hiring for a deadline. The seat fills after the deadline passes. Hire for the team you want in two years, and rent for the next two quarters.
- Forgetting where the data goes. Outside engineers touch production data. Under the PDPL, SDAIA is the regulator and cross-border transfer is governed by Article 29 and SDAIA’s Transfer Regulations (Morgan Lewis, 2024), so an offshore team with a copy of your customer database is a compliance question before it is a staffing one. Grant access in-Kingdom, scoped and logged, in line with the NCA ECC access controls you already have to meet.
- No exit plan. The contract ends and the knowledge leaves with it. Write the handover into the scope from day one: documentation, runbooks, and one of your engineers who has deployed the thing alone.
How to start: one team, one quarter, one measure
Pick one piece of work that is hurting, not the whole roadmap. Ask the one question: is it yours to keep? Then measure what it costs you today in delay, honestly. If it is core, open the hiring now and augment to cover the gap. If it is a bounded scope, write it down well enough that a vendor could be scored on it, and keep the repositories and accounts in your name. Run a quarter, then check what you can do alone that you could not before. That check, not the invoice, is the measure.
Whatever path you pick, keep the knowledge in-house. The worst outcome of all is being unable to maintain the thing that was built for you. If you are inheriting a team rather than building one, the same questions apply in reverse; see assessing a tech team before you fund or acquire it.
Need engineering capacity without losing control of your roadmap? SDCG augments and leads engineering teams as embedded partners, and helps you build lasting in-house capability instead of permanent dependence. Book a free 30-minute review.