The Software Development Outsourcing Process, Step by Step

The process at a glance

The phases overlap in practice, and smaller projects compress several into one conversation. But each phase produces a specific output, and if that output is missing, the next phase quietly does its work badly. Here is the whole sequence on one timeline, for a mid-sized build of about six months.

This article is about the process for a product or project. If you're building a long-term team, the steps after contracting look different, and we cover them in the guide to setting up a dedicated offshore team. For choosing between fixed price, dedicated teams and augmentation, see software development outsourcing models.

Phase 1: Define the need (1–2 weeks)

Before talking to any vendor, write one page that answers five questions. What business result should this produce? What can we spend, as a range? When does it need to be live, and what happens if it isn't? How will we know it worked? Who on our side owns it?

The last question is the one companies skip. Outsourcing doesn't remove the need for an owner; it changes the job. The owner writes or approves requirements, makes trade-offs, attends demos and accepts the work. Plan for 20–40% of a senior person's week during the first two months and 10–20% after. If nobody has that time, solve that first.

This is also where you decide what kind of help you need. Do you have a backlog and need hands? Then you're looking for team extension. Do you have an idea and need a product? Then you need a vendor that does discovery, design and delivery. Our article on in-house vs outsourced development helps decide which parts to outsource at all.

Phase 2: Requirements (2–6 weeks)

Vendors can only estimate what they can see. A brief that says "a marketplace like Etsy for vintage furniture" will produce quotes ranging from $40k to $400k, and all of them will be technically honest. The goal of this phase is to narrow that range.

You don't need a 100-page specification. You need:

• Who the users are and the five to ten main things each type of user does.
• Integrations (payments, CRM, identity, data sources) and any existing systems the product must work with.
• Non-functional requirements: expected load, security and compliance needs (HIPAA, SOC 2, PCI, state privacy laws), supported devices and browsers.
• What is explicitly out of scope for the first release.
• Wireframes or a clickable prototype for the core flows, if you can produce them.

If you can't write this yourself, run a paid discovery phase, usually 2–6 weeks with a business analyst, a designer and a part-time architect. It costs a fraction of the build and produces the document every vendor will quote against. Our business analysis team does this as a standalone engagement, and the output belongs to you whether or not you build with us.

Phase 3: Find vendors (1–3 weeks)

Build a long list of 8–12 vendors from referrals, review platforms and your network, then cut it to 3–5 using criteria you can check from the outside: relevant projects in a similar domain or stack, team size that fits yours (you want to be a meaningful client, not their smallest), time-zone fit, and how they responded to your first email.

Decide on geography deliberately. For US companies, nearshore means Latin America, with most of the workday shared. Central and Eastern Europe, where Gilzor works, is offshore with a two-to-four-hour overlap with the East Coast. Asia offers the lowest rates and the least overlap. Each can work. Rates by region are in our nearshore rates guide.

For larger engagements a formal RFP makes comparison easier. Our RFP guide has a structure you can adapt for project work too.

Phase 4: Evaluate (2–6 weeks)

Send each shortlisted vendor the same requirements package and ask for the same things back: approach, team composition with seniority, timeline with milestones, estimate with ranges and assumptions, and how they handle change. Then compare on one scorecard (there's a template below).

Three activities separate good evaluations from guesswork:

1. Meet the actual team. Not the sales lead, the engineers and the project manager who would work on your project. Ask them to explain a past project's architecture and what they would do differently.
2. Call references that look like you. Same size, same kind of project. Ask what went wrong and how the vendor handled it. Every project has something.
3. Run a paid pilot when the engagement is large. Four to eight weeks on a real slice of the product tells you more than any proposal. The cost is one to two months of a small team, and if it fails you've lost a month instead of a year.

Watch the estimates. The lowest quote usually assumes the narrowest scope. Ask each vendor to list what is not included, and you'll often find the gap between quotes there.

Phase 5: Contract (1–3 weeks)

A typical structure is a master services agreement for the legal relationship, a statement of work per project or phase, and a data processing agreement if the vendor touches personal data. The clauses that matter most: IP assignment to you that covers the vendor's own engineers and subcontractors, ownership of accounts and infrastructure, acceptance criteria, payment tied to milestones or monthly T&M with a forecast, replacement of team members, termination and handover obligations. We walk through each one in the software outsourcing contract guide.

Plan the time. A founder signing a vendor's standard terms after one legal review can close in a week. A company with procurement, security questionnaires and insurance requirements often needs a month, so start the paperwork in parallel with the evaluation.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

SaaSMagmaset: one tool for all project tasks→ManufacturingIncident management system for auto parts manufacturer→Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Plan your timeline

Pick the options closest to your situation. The planner estimates each phase and the dates that matter: when the contract is signed, when the first sprint starts and when the product could be ready to hand over.

The default setup lands the first sprint around week 12. Companies that come to us expecting to start "next week" usually have phases 1–4 partly done already: a clear brief, written requirements and a decision to work with us specifically. When those exist, our internal commitment is a maximum of two weeks from signed agreement to the first day of development.

Phase 6: Onboard (1–2 weeks)

Onboarding is where the contract becomes a working relationship. It should end with a team that can push code to your repository, deploy to a staging environment and knows what it's building in the first two sprints. The essentials:

• Access in your name: code repository, cloud account, issue tracker, design files, communication channels. Invite the vendor's people as users; don't let the vendor create the accounts.
• Working agreements: sprint length, demo cadence, the overlap window with your time zone, response times, who can approve what.
• Definition of done: code reviewed, tests written and passing, QA verified, deployed to staging, documented if it changes setup or architecture.
• A kickoff where the vendor plays back the requirements in its own words. Misunderstandings that surface here cost an hour; the same ones found in month three cost a sprint.

Phase 7: Deliver (months)

Delivery runs in cycles of one to two weeks: plan, build, test, demo, adjust. Your role shifts from choosing to steering. The rhythm that works for most of our clients is a short daily sync in the overlap window, a demo every sprint where working software is shown on staging, and a monthly steering call that looks at budget against forecast, risks and upcoming decisions.

Ask for three numbers every sprint: what was planned versus completed, how many items came back from QA, and the forecast to finish the current milestone. On our projects about 5% of tasks sent to QA come back to developers, and 98% of projects are delivered on time; we track both because a vendor that can't show its numbers can't manage them. Testing should run inside each sprint, not as a phase at the end. Our QA team works that way by default.

The risks that show up in this phase, and the warning signs that precede them, are covered in our outsourcing risk register. A project manager on the vendor side should run this rhythm. Your job is to make decisions quickly and attend the demos.

Phase 8: Hand over or transition (2–6 weeks)

Handover isn't only for the end of a relationship. It's the moment the product becomes fully yours: maintained by your in-house team, by the same vendor under a support agreement, or by someone new. If the earlier phases were done well, most of it is a formality, because the code was always in your repository and the accounts were always yours. What still needs deliberate work:

• Documentation that a new engineer can follow to set up, run, test and deploy the product without asking anyone.
• A list of known issues, technical debt and the reasoning behind non-obvious architecture decisions.
• Recorded walkthrough sessions with the receiving team, plus two to four weeks during which the vendor answers questions.
• A test: the receiving team ships a small change to production on its own before the vendor rolls off.

Templates you can copy

Four documents carry most of the process. Shorter is better; these fit on a page each.

Where the process usually breaks

The broader decision of how to hire and assess a team is covered in how to hire a dedicated development team.

FAQ

Where Gilzor fits

We can join this process at any phase. Some clients come with a one-line idea and start with a discovery phase that ends in a scope document and estimate they own. Others arrive with written requirements and need a team within two weeks. Either way, the repositories and accounts are in your name from day one, and we plan the handover in the first month, not the last.

A note on geography: our teams are in Poland and Cyprus, so for US clients we're offshore with a two-to-four-hour overlap with the East Coast, not nearshore. We'll set the overlap window in the proposal so you can judge whether it fits how you work.