How to Outsource SaaS Product Development Without Losing Control

Problem 1: The vendor builds what was specified, not what was needed

The requirement was ambiguous. The vendor interpreted it one way. You intended it another. The feature ships. You discover the misalignment at demo. This is a specification problem, not an outsourcing problem. It happens with in-house developers too. The fix is a better brief and a better acceptance criteria process, not abandoning outsourcing.

Problem 2: The vendor makes architecture decisions without client input

The vendor chose the approach that was fastest to build rather than the one that was easiest to extend. The client discovers this when they try to add the next feature and the architecture makes it expensive. This is a governance problem. The fix is establishing architecture decision rights in the contract and the sprint process.

Problem 3: The client does not know what is happening until it is too late to change

No visibility into in-progress work. Updates only when asked. Problems surface at sprint review rather than mid-sprint. This is a communication structure problem. The fix is a defined communication cadence with mid-sprint check-ins, not just end-of-sprint reviews.

1. Sprint priorities are set by you, not the vendor

The vendor executes. You direct. Sprint planning is a standing meeting between your product owner or CTO and the vendor's technical lead. The agenda is yours: what gets built this sprint, in what order, and to what standard. The vendor translates priorities into tasks. The client does not assign tasks to individual developers, but the client owns the priority stack absolutely.

2. Architecture decisions require client sign-off

Significant architecture choices, technology selections, and structural design decisions require explicit client approval before implementation begins. This does not mean the client makes every technical decision. It means the vendor proposes, explains the trade-offs, and the client approves. A vendor who makes architecture decisions unilaterally is one who will build something that is hard to change later.

3. Mid-sprint check-in is mandatory, not optional

End-of-sprint reviews catch problems too late to fix without cost. A 30-minute mid-sprint check-in on Wednesday, for a Monday-to-Friday sprint, allows problems to surface while there is still time to course-correct within the sprint. This single practice eliminates most of the surprise delivery that erodes trust in outsourced engagements.

4. Code lives in the client's repository from Day 1

Not transferred at engagement end. Not in the vendor's repository with periodic exports. Every commit goes directly into your repository under your access controls. This is a non-negotiable contract term. It means you can terminate any engagement and take the codebase with you without negotiation.

5. Acceptance criteria are written before development starts

Not evaluated at the end. Written at sprint planning, before any development begins. The developer knows what done looks like before they start writing code. Acceptance criteria written after development is done is the vendor deciding what they built was what you wanted. That is the opposite of control.

6. The vendor tracks and reports delivery metrics

Sprint delivery rate, ticket cycle time, PR review time, and defect rate are tracked by the vendor and reported to the client on a weekly basis. A vendor who does not track their own delivery performance is a vendor who cannot tell you whether they are performing well. The metrics should be in the contract as a reporting obligation, not as a favour.

Does your standard contract include the client's repository as the primary code location?

Yes: proceed to next question. No: negotiate this or move on. Code in the vendor's repository with client access is not the same as code in the client's repository.

Do you run mid-sprint check-ins with clients or only end-of-sprint reviews?

Mid-sprint is the right answer. End-of-sprint only is the answer from a vendor who does not want problems surfaced while they can still be fixed at no cost to the vendor.

Who owns architecture decisions in your typical engagement?

The right answer is: we propose, you approve. The wrong answer is either: we own the architecture (vendor overreach) or: you own all decisions (the vendor is abdicating the expertise you are paying for).

What metrics do you report to clients and how often?

A vendor who tracks nothing cannot demonstrate performance improvement. A vendor who tracks delivery rate, ticket cycle time, and defect rate weekly has thought about accountability.

Sprint delivery rate

What percentage of committed sprint items are completed by sprint end? Below 80% for two consecutive sprints is an underperformance signal, not a temporary dip.

Feature cycle time

How long from feature definition to feature in staging? Increasing cycle times with no corresponding increase in feature complexity indicate a growing problem in the development process.

Defect escape rate

How many bugs reach staging or production that should have been caught in development? A vendor with a well-functioning QA process has a low defect escape rate. A vendor without one does not.

Architecture review time

How quickly does the vendor respond to architecture questions and produce proposals? Slow architecture response delays every decision that depends on it.

Dependency on the client

How many blockers per sprint require client decisions to resolve? A high number means the vendor is not managing the engagement proactively. A low number means they are.

Week 1 to 2: Discovery and architecture

We review your product brief, existing codebase if any, and product roadmap. We produce an architecture proposal with trade-offs for the client to approve. Multi-tenancy strategy, billing architecture, and API design are the first decisions we establish.

Week 2 to 3: Team assembly and sprint 1 planning

The named development team is confirmed and the client interviews key team members. Sprint 1 is scoped at 60% of normal velocity to allow for codebase and architecture context building. Acceptance criteria for sprint 1 items are written in the planning session.

Week 3 onwards: Sprint delivery rhythm

Monday sprint planning with client. Wednesday mid-sprint check-in. Friday sprint review. Weekly delivery metrics shared every Monday morning before planning begins. Architecture decisions proposed in async first, approved in sync sprint planning.

Month 2 to 3: Full velocity

By sprint 3 to 4, the team is at full velocity. The client's management overhead is 2 to 3 hours per week: sprint planning, mid-sprint check-in, and sprint review. Everything else runs under the vendor's management.