What should a software outsourcing RFP contain?
A software outsourcing RFP should contain the business outcome you are buying, a clear scope boundary, the team shape you expect, your compliance and security requirements, the commercial model, and one identical costed scenario every vendor must price. That last element is what makes the responses comparable. Without it you receive five documents describing five different projects at five different prices, and the selection turns into a beauty contest between sales decks. With it, you can lay the bids side by side and see who understood the problem.
The document does not need to be long. A tight ten-page RFP with a well-defined scenario produces better bids than a forty-page procurement template written for buying office furniture.
What are the sections of a good outsourcing RFP?
- Context and outcome — what the business is trying to achieve, and how success will be measured. Not a feature list.
- Scope boundary — what is explicitly in, and just as importantly what is out. Ambiguity here becomes a change request later.
- Current state — stack, repository size, test coverage, deployment method, known debt. Vendors price uncertainty, so hiding problems costs you money.
- Team shape — how many engineers, which seniority, whether a tech lead, QA and designer are expected, and who owns product decisions.
- Ways of working — overlap hours required, ceremonies, tooling, review and release process.
- Compliance — data residency, GDPR processor terms, security certifications, subcontracting rules, IP assignment.
- Commercial model — the pricing structures you will accept and the invoicing cadence.
- The pricing scenario — one defined slice of work, described in enough detail to be costed by everyone.
- Evaluation criteria and weights — published, so vendors know where to invest their effort.
- Timeline — dates for questions, submission, demos and decision.
How long should the tender take?
| Stage | Duration | What actually happens |
|---|---|---|
| Internal scoping | 1-2 weeks | Agree the outcome, budget envelope and decision makers before contacting anyone |
| Longlist | 1 week | 6-10 vendors screened on geography, domain and size fit |
| RFP issued, questions open | 2 weeks | Written Q and A shared with all bidders to keep the field level |
| Responses evaluated | 1 week | Score against published weights before any demo, to reduce charisma bias |
| Technical deep dives | 1-2 weeks | Meet the actual proposed engineers, not the pre-sales architect |
| Paid pilot | 2-4 weeks | One real, shippable slice of work with the real team |
| Contract and onboarding | 2-3 weeks | MSA, SOW, processor agreement, access provisioning |
Eight to twelve weeks end to end is realistic for a team of five or more. Compressing it below six weeks usually means skipping the paid pilot, which is the single most informative stage of the entire process.
Which questions separate good vendors from good salespeople?
Generic capability questions produce generic answers. Specific, uncomfortable questions produce signal:
- Name the engineers you would put on this team, and let us interview them. Who replaces them if they leave?
- Describe a project that went badly and what you changed afterwards.
- What is your engineer attrition rate, and how do you handle handover when someone resigns?
- Who owns the code, the CI configuration and the infrastructure accounts during and after the engagement?
- Show us a real pull request and a real sprint report from a comparable client, redacted.
- What would you need from us in the first thirty days, and what happens if we do not provide it?
- What is your transition-out service and what does it cost?
The last question is a reliable filter. Vendors who have a priced, documented exit process are confident in the relationship; vendors who deflect it are relying on switching costs to keep you. The same instinct runs through our wider guide on choosing a software outsourcing partner in Europe.
How should the statement of work define done?
The RFP wins you a vendor. The statement of work is what you actually live inside, and its job is to make "finished" a fact rather than an opinion. A workable SOW nails down five things.
Deliverables — described as outcomes with acceptance criteria, not as activities. "Checkout flow supports SEPA direct debit, passes the agreed test suite, deployed to production" is a deliverable. "Payments work" is not.
Definition of done — the standing quality bar every deliverable must clear: code reviewed, tests written, documentation updated, security checks passed, deployed behind a flag. Written once, applied everywhere.
Acceptance and rejection — how long you have to accept, what counts as a valid rejection, and who arbitrates. Silence should not equal acceptance forever; a defined window keeps both sides honest.
Change control — how scope changes are proposed, priced and approved. Every long engagement changes scope; the ones that go wrong are those where nobody agreed the mechanism in advance.
Service levels — response and resolution times by severity, plus the reporting cadence that proves them.
Which commercial model belongs in the SOW?
| Model | Best for | Main risk | Control that fixes it |
|---|---|---|---|
| Fixed price | Well-defined, stable scope with a hard budget | Change requests for everything unstated; incentive to cut quality | Detailed acceptance criteria and a change-control rate agreed in advance |
| Time and materials | Discovery, R and D, unclear scope | Open-ended spend | Monthly cap, sprint-level forecast, right to pause on notice |
| Dedicated team | Ongoing product work and roadmap ownership | Paying for capacity you do not direct well | Named engineers, notice period, quarterly capacity review |
| Outcome or milestone based | Clear, measurable business results | Disputes over attribution | Metrics defined and instrumented before work starts |
Most European buyers of ongoing product work end up with a dedicated team, for reasons set out in our comparison of dedicated teams versus project-based outsourcing. Fixed price still earns its place for bounded pieces such as a migration or an integration, where the scope genuinely can be frozen.
What clauses do European buyers most often forget?
Four gaps recur. IP assignment that survives the subcontracting chain — assignment from the vendor is worthless if their subcontractor never assigned anything to them. Data processing terms that match the technical reality of who touches production data, covered in detail in our guide to GDPR, IP and contracts when outsourcing to India. Key-person and rotation clauses, so the senior engineers who won the pitch are the ones who write the code. And audit and reporting rights — the right to see the metrics, not just the summary slide.
How do you score the responses?
Publish the weights in the RFP and score in that order, before any demo. A defensible split for a delivery-team engagement is roughly 30% technical approach and proposed team, 20% relevant domain and stack experience, 20% commercial terms and total cost, 15% security and compliance posture, 15% ways of working and communication. Score independently, then meet to reconcile — group scoring drifts toward whoever spoke first.
Then run the paid pilot. Two to four weeks of real work with the real engineers tells you more than every reference call combined, because it exercises the thing you are actually buying: how they behave when the requirements turn out to be incomplete. If you want a partner who will price that pilot honestly and put named senior engineers on it, ILMTEC builds dedicated engineering squads for European companies and responds to structured RFPs with the same structure they were written in.
