Grow the team, or bring a partner? Get an honest answer either way.
The five factors that actually decide it — capacity, speed, cost shape, control and horizon. No prices and no pitch: a published rubric, an honest read of where your answers point, and a real recommendation either way.
Your level, five-dimension profile and recommendations appear on screen the moment you finish — no email, and the branded PDF report is yours to keep.
01Team & Capacity
02Speed & Deadlines
03Cost Shape & Commitment
04Control, IP & Risk
05Horizon & Ownership
Scored in this browser — nothing is sent unless you choose to.
Written by DigiWagon’s delivery practiceScored with the published DigiWagon Delivery Model FrameworkISO/IEC 27001 and ISO 9001 certifiedWork we’ve delivered
Who this is for
Founders and CEOs deciding how their next system gets built
CTOs weighing hiring plans against delivery deadlines
Finance leaders comparing payroll against project budgets
The flow
How it works
01Answer quick multiple-choice questions about your team, timeline, budget shape and horizon — options, not essays.
02Get a delivery-model recommendation and a five-factor profile showing which way each factor points.
03Keep the branded PDF report — and send it through if you want the partner side of it pressure-tested.
Every result is one delivery model and five factor scores — an example profile.
The framework
Five factors, scored in the open
Every answer carries zero to three points by the direction it points — lower toward in-house, higher toward a partner. Three questions per factor give a factor score out of nine; the five dimensions together land on one of four delivery models. The rubric is published because a recommendation you can't inspect isn't worth trusting.
0–3 per answer→3 questions per dimension→dimension score out of 9→5 dimensions→your result out of 45
No gate. Full results on screen — email is never required to see them.
Nothing stored. Answers are scored in your browser and never leave this page unless you choose to send them.
No invented benchmarks. Every number derives from the published rubric and your own answers.
All five dimensions weigh equally in v1 — deliberately, until real-world results earn differentiated weights. Framework v1 · September 2026.
The team you actually have, how realistic hiring is in your market, and whether building software is your company's core business or an enabler of it.
Why this matters
Most in-house-vs-partner debates are settled here before they start: a plan that assumes engineers you cannot hire, or capacity a committed team does not have, fails on schedule regardless of its merits.
What does your technical team look like today?
How would hiring three strong engineers go for you?
Is building software your company's core business?
02
Speed & Deadlines
When this must ship, what a delay actually costs, and how settled the scope is — the calendar facts that constrain every delivery model.
Why this matters
Hiring is the slowest path to velocity: recruiting, onboarding and forming a team routinely consumes half a year before real output. When the window is short, the delivery model is chosen by the deadline.
When does this need to be live?
What does a six-month delay cost you?
How settled is what you're building?
03
Cost Shape & Commitment
Not how much — the scorecard never prices anything — but which SHAPE of spending fits: permanent payroll versus a project budget, and how much building remains after launch.
Why this matters
An in-house team is a standing commitment that outlives the project; a partner engagement ends when the work does. Matching the commitment to how long the work actually lasts is the real economics of this decision.
Which spending shape fits your business right now?
After launch, how much building remains?
How much appetite is there for managing engineers — hiring, retention, reviews?
04
Control, IP & Risk
How sensitive the system and its data are, what regulation says about who may touch them, and how much day-to-day visibility you need into the work.
Why this matters
This is the factor people feel most and examine least. Real constraints — regulated data, genuinely secret IP — do rule models out; everything else is solved by agreements and working practices, not by geography.
How sensitive is what this system does?
What do regulations say about who touches your data?
How much day-to-day visibility do you need into the work?
05
Horizon & Ownership
Whether this is one system or the start of a portfolio, and whether owning software capability is a competence your company wants to build — or an outcome it wants to buy.
Why this matters
The same project can be a purchase or an investment depending on what comes after it. A portfolio justifies building the muscle; a single system rarely does — and pretending otherwise staffs a team the future won't feed.
Is this one system, or the start of a portfolio?
Do you want software capability as a company competence?
Who will run this system in three years?
What your score means
Build It In-House0–13 of 45
Your factors point inward: capacity you have or intend to build, IP that should stay home, and a horizon long enough to repay the investment. Build the team — and spend outside help, if any, on the specialisms and peak loads that don't justify a permanent seat.
In-House Core, Partner Support14–24 of 45
The center of gravity stays with you — architecture, product direction, the sensitive core — while a partner adds what you're short of: velocity, specialisms, or hands while hiring catches up. The discipline that makes this work is a clear boundary about who owns what.
Partner-Led, Jointly Owned25–35 of 45
A partner team carries delivery while you carry intent: your product owner steering, their process shipping, with visibility built into the working rhythm. This is the most common shape for a first serious engagement — and the one where choosing a transparent partner matters most.
Full Delivery Partner36–45 of 45
Everything about your situation — capacity, calendar, cost shape, horizon — says buy the outcome. Hand a partner the whole delivery, hold them to results, and put your attention on the business the software serves. The selection criteria become durability and trust, not just capability.
FAQ
About this scorecard
Short answers to what people ask before they take it — including the bias question, answered straight.
01How do I decide between in-house and outsourcing software development?
Weigh five factors rather than instinct: the team and hiring market you actually have, how quickly the work must ship, the spending shape your business prefers, how sensitive the system is, and how long you'll own it. The right answer is a delivery model — and it is often a mix rather than either extreme.
02What does this scorecard measure?
Five decision factors: team capacity and the realism of hiring, speed and what a delay costs, the spending shape that fits (project budget versus permanent payroll), control over IP and data, and your ownership horizon. Each factor scores from three questions and points somewhere — in-house, partner, or genuinely either.
03Isn't this scorecard biased toward outsourcing?
Fair question — we are a services company. The rubric is published on this page so you can inspect exactly how answers score, "build it in-house" is a real result with real recommendations behind it, and the scorecard never shows prices. A recommendation you can't trust would be worthless to us.
04What's the difference between staff augmentation and full outsourcing?
Staff augmentation adds engineers to your team under your management — you keep direction, they add hands. Full outsourcing hands a partner the outcome: they staff, manage and deliver against agreed results. Between them sits partner-led delivery with your product owner steering — often the practical middle for first engagements.
05Do I need to share my email address to see the results?
No. Your result, the factor-by-factor breakdown and the recommendations appear on screen the moment you finish, and the branded PDF report generates locally in your browser. Contact details only come into it if you choose to send your results through for a delivery-model conversation with our team.
06What should we do with the result?
Treat the level as a starting model, not a verdict — then pressure-test it against the two factors that scored most decisively. If the result points to a partner or a mix, send it through: we'll tell you honestly what we'd take on, what should stay with you, and why.
Want the partner side pressure-tested?
Send your results through and we'll respond like it's a working session: what we'd take on, what should stay with you, and where a hybrid beats both extremes. If in-house is your answer, we'll say so.
One click opens the assistant you already use with a question that points it at this page, so the answer comes from what we publish, not a guess.
The question it opens withRead https://digiwagon.com/tools/in-house-vs-outsourcing and tell me what "In-house vs Outsourcing" helps me decide, what inputs I should gather before using it, and how DigiWagon suggests acting on the result. Stick to what the page says and mark anything you are not sure about.
