A non-technical SaaS founder posted to r/SaaS late last year describing what looked like a model outsourcing engagement: a clean offshore agency, weekly demos, screen recordings of new features, a project manager who replied within hours. Three months in, an independent US contractor opened the repo for the first time.

"$18K later I had code nobody on my team could maintain or understand." 400-line functions, no tests, no documentation, three mixed frameworks, and copy-pasted blocks. A small feature estimate jumped from 3 days to 3 weeks once a new engineer had to read what was there.

u/throwaway (anonymized), Reddit r/SaaS

If you're a Chief Technology Officer in Custom Software Development, you've watched some version of this play out — either at a portfolio company, a previous role, or in a partner audit. The demos look fine. The Jira board is green. Then someone opens the repo, and the bill comes due.

The Hidden Problem: You're Vetting at the Wrong Time

The dominant pattern across failed outsourcing engagements isn't "we picked a bad vendor." It's "we picked the only vendor who could start Monday." Deadline-driven sourcing collapses a six-week diligence process into a forty-minute sales call. The vendor optimizes for the close, not the engagement; you optimize for the start date, not the multi-quarter cost curve.

The Deloitte Global Outsourcing Survey has, over multiple cycles, pointed at the same root cause: buyers under-invest in the diligence phase relative to the contracting phase. Most CTOs we talk to can describe their MSA template in detail and cannot describe their technical-vetting checklist at all.

Real Stories From the Field

The Reddit case at the top of this article isn't isolated. Two of the three failure patterns the founder hit — opaque code quality and unmaintainability — are the same patterns the Vetted Outsource blog identifies as recurring across its case audits:

"Communication failures sink outsourcing relationships more frequently than technical shortcomings." The deeper read: most "communication failures" are downstream of process design that was never specified during vetting.

Vetted Outsource Blog, Blog Post

The portfolio question is the other recurring red flag. Hire with Near's audit observations match what our own due-diligence work surfaces:

"Every company has a portfolio of their best work. But you need to dig deeper... If they keep things vague or only show mockups, that's a red flag."

Hire with Near, Blog Post

From our work with custom software clients: We were brought in as an independent reviewer on a ~12-person B2B SaaS engagement — Node/TypeScript backend, React frontend, mid-cycle. The agency demos had been clean for four months. Our 90-minute audit turned up three production-blocking issues: no migration strategy on the primary tenant table, no test coverage on the billing module, and a single hard-coded credential in a deployment script that had been copy-pasted across three environments. The engagement was salvageable, but only because the review happened at month four and not month nine. The client's takeaway, which we now bake into every engagement scoping call: code review by an independent party is a calendar event, not a contingency.

The Pattern: Vetting Is a Continuous Process, Not a Procurement Event

The teams that consistently end up with healthy outsourcing relationships do three things differently. They maintain a warm list of two-to-three vetted partners before any specific project is approved. They treat the first paid engagement as the real interview — small scope, full code access, defined exit. And they schedule independent code reviews at fixed intervals, not when something feels wrong.

The third behavior is the most counter-intuitive one for cost-sensitive CTOs. A $1,500-to-$3,000 quarterly review from a third-party engineer is rounding error against the cost of a rebuild, but it's frequently the first line cut when budgets tighten. Turnover compounds this. The same Vetted Outsource analysis frames it bluntly:

"High turnover creates continuity problems."

Vetted Outsource, Blog Post

You can't detect turnover from demos, and you can't detect it from the master agreement. You detect it from the commit graph — and only if you have access to it.

The decision space is clearer when laid out side by side. The comparison below shows the two postures most CTOs default to, and the gap that the playbook closes:

The Playbook: Six Steps, Mapped to the Calendar

Below is the playbook we recommend to Custom Software Development CTOs who are not currently in an active sourcing cycle. If you are, jump to step 4. The sequencing matters — each step changes what you learn in the next one.

Step 1 — Build a Warm List Before You Need One

What to do: Maintain a working document of 5-8 outsourcing partners with notes on stack fit, time-zone overlap, team size, and pricing band. Refresh quarterly.

What good looks like: When a project is approved on Monday, you have three partners you can email by Tuesday whose first-call is a scoping conversation, not a discovery call.

Common failure mode: Outsourcing the warm list to procurement or HR. They will optimize for compliance signals (ISO 27001, NDA templates), not engineering signals (code review culture, on-call rotation, framework opinions).

Step 2 — Run a Reference Conversation Before a Sales Conversation

What to do: Ask any candidate partner for two references: one current client, one past client whose engagement ended in the last 12 months. Talk to both. Ask the past client a single question: "What does your code look like now, and who maintains it?"

What good looks like: The past client describes a clean handover, internal team comfort with the codebase, and a maintenance arrangement (extended retainer, knowledge-transfer doc, or a clean break).

Common failure mode: Accepting only current-client references. Current clients are mid-engagement and conflict-averse. The signal lives with the post-engagement reference.

Step 3 — Score the Portfolio for Depth, Not Range

What to do: Ask for three case studies in your specific stack and domain. For each, request: the engagement length, team size and roles, the deployed URL or app store link, and the names of two engineers who worked on it.

What good looks like: The agency surfaces real deployments, names engineers who are still on the team, and is comfortable with you contacting one of them.

Common failure mode: Treating breadth as a positive signal. A portfolio with 40 industries and 12 stacks is a staffing agency wearing an engineering brand. Pick the partner with 3-5 deep verticals over the one with 30 logos.

Step 4 — Run a Paid, Time-Boxed Technical Pilot

What to do: Scope a 2-4 week paid pilot on a real but non-critical workstream. Mandatory deliverables: a Git repo you own, a deployment to your staging environment, written documentation, and a test suite.

What good looks like: At the end of the pilot you have a codebase that another engineer (yours or an independent reviewer) can read and extend without a meeting.

Common failure mode: Treating the pilot as a try-before-you-buy on price. The pilot is a code-quality probe. If the price-per-week of the pilot is your dominant question, you'll skip the artifacts that matter.

Step 5 — Schedule an Independent Code Review at Day 30

What to do: Before you sign the master engagement, line up an independent engineer (not from the agency, not from your hiring pipeline) to audit the codebase at day 30, day 90, and one month before any major release.

What good looks like: The review is a calendar event with a fixed scope (architecture, test coverage, dependency hygiene, deployment process) and a written deliverable. Cost band: $500-$3,000 per review depending on codebase size.

Common failure mode: Asking your agency to recommend the reviewer. Same-tree audits are theater. The Reddit founder's $18K loss is the exact case this step exists to prevent.

Step 6 — Define the Exit Before the Entry

What to do: Before kickoff, write a one-page "graceful exit" document: who owns the repo, where credentials live, what documentation must exist for a handover, and a 30-day notice clause.

What good looks like: The agency signs it without renegotiation. Their willingness to sign a clean exit is itself a vetting signal.

Common failure mode: Letting the agency's MSA template dominate. Their template optimizes for retention; yours should optimize for portability.

The full sequence, mapped against the calendar weeks where each step pays off, is visualized below:

Close: What to Do This Week

The founder who lost $18K didn't fail because they outsourced. They failed because the only vetting signal they had was a weekly demo, and demos are designed to be the strongest signal a vendor controls. The fix isn't bringing engineering in-house — it's running a vetting process the vendor doesn't author.

Tomorrow morning: open a doc titled "Warm Partner List" and write down the three agencies you'd email if a project was approved today. Note the gaps — you'll discover at least one stack you can't currently staff.

Wednesday: email two past clients (not current) of one of those agencies and ask the single question: "What does your code look like now, and who maintains it?"

By Friday: identify the independent engineer you'd hire for a day-30 code review. Get their rate and their availability window. You don't need to engage them yet — you need to know who they are before you need them.

Diagnostic Checklist: Score Your Current Posture

Run these against your current outsourcing setup (or the one you're about to start). Three or more "No" answers = your vetting process is structurally exposed.