Bespoke Software Development RFPs: Questions That Reveal Vendors

Four RFP responses land on your desk. All four describe a similar bespoke software development methodology, quote similar rates, and lean on nearly identical language about “agile delivery” and “senior engineers.” Ask each finalist to name the actual people who’ll be assigned to your project, though, and usually only one of the four can answer directly. The other three are often subcontracting arrangements dressed up as full-service development shops — a pattern more common in enterprise RFP responses than most buyers realize until they ask the question themselves.

That gap between what an RFP response promises and who actually writes the code is exactly what a good evaluation process is supposed to catch, and it usually doesn’t, because most RFP scoring templates are built around deliverables and timelines rather than the structural questions that expose a reseller. If you’re an IT manager or product owner running a bespoke software development RFP for your organization right now, here are the questions worth adding before you send the shortlist to procurement for final sign-off.

None of these questions require legal review or a formal RFI addendum. Most can be asked live, in the finalist interview or technical scoping call that typically happens in the final two weeks before a decision. What matters is asking them deliberately, in writing where possible, so answers can be compared side by side rather than relying on memory of who said what in which meeting.

1. Who Specifically Will Work on Our Project, and Where Are They Physically Based?

This is the single highest-leverage question in the entire RFP process, and it’s the one vendors most often deflect. A genuine bespoke software development partner will name actual team members — not job titles, but people, with LinkedIn profiles and prior project history you can verify. A reseller will say “we’ll assign our best available team” or “resourcing is finalized after contract signature,” which is a structural admission that they don’t yet control the engineering capacity they just sold you.

Ask specifically where the named engineers are located and whether that location is the vendor’s own office or a subcontracted arrangement. This matters for two reasons beyond simple transparency: time zone overlap affects your daily standups and review cadence, and direct employment (versus subcontracting) affects how much control the vendor actually has over quality, retention, and confidentiality obligations under your contract.

In practice, we’ve seen enterprise buyers add a simple clause to their RFP template that forces this issue: a requirement that the vendor list named individuals with LinkedIn URLs and years of tenure at the company, refreshed at contract signature and again at kickoff. Vendors that are direct employers of their engineering staff answer this instantly. Vendors that broker subcontracted capacity tend to push back, citing “confidentiality” or “resourcing flexibility” — reasonable-sounding language that in practice just means they can’t commit to who will actually build your software.

2. Can We See Unedited Code From a Comparable Past Project?

Portfolios show finished screenshots. They almost never show code. Ask each finalist for a code walkthrough — even a redacted repository — from a project of similar technical complexity to yours. What you’re looking for isn’t perfection; it’s evidence of consistent patterns, meaningful test coverage, and commit history that reflects iterative, reviewed work rather than a single large dump before a demo.

A vendor confident in its own engineering discipline will do this without much friction, often on a screen-share call within the RFP window. A vendor that stalls, or offers only marketing screenshots and case study PDFs instead, is very likely not the team actually writing the code — a hallmark of a reseller relationship where the underlying engineering is subcontracted to a third party the vendor doesn’t want you evaluating directly.

3. What Is Your Actual Process When We Change Scope Mid-Sprint?

Every real project changes scope at least once. The RFP answer to this question tells you more about day-to-day working reality than almost anything else in the document. A mature answer describes a defined change-request process: impact assessment on timeline and cost, a decision point with the client before work proceeds, and clear documentation of what changed and why.

A weak answer either promises unlimited flexibility with no process (a sign the vendor will absorb scope creep quietly and then blow the budget or timeline without warning you) or describes a rigid change-order bureaucracy that will make your product team miserable working with them for a year. Push for a concrete example from a past project, not a policy description — real answers include specifics like “we added two weeks and reprioritized the backlog,” not “we handle changes professionally.”

It’s worth also asking who on the vendor’s side has authority to approve a scope change without escalating to a separate account management layer. Enterprise buyers frequently discover, mid-project, that their day-to-day contact has no real decision-making power and every change request triggers a multi-day internal approval chain on the vendor’s side. That friction compounds badly on a 12-month bespoke build with dozens of scope adjustments.

Question 3.5: How Do You Handle a Legacy System We Don’t Fully Understand Ourselves?

For MNC buyers modernizing legacy platforms specifically, add a question about discovery process: how does the vendor reverse-engineer undocumented business logic before writing new code? A vendor with real experience will describe a structured discovery phase — stakeholder interviews, code archaeology, data audits — before committing to an estimate. A vendor that quotes a fixed price for legacy modernization without any discovery phase is guessing, and that guess becomes your change-order bill six weeks in.

4. How Is Source Code and Documentation Ownership Handled During the Build?

This question separates genuine custom software development services from vendors optimizing for lock-in. You want a contractual commitment to continuous repository access and IP transfer throughout the engagement, not just a final handover at project close. Ask specifically: “If we terminated this contract in month four, what would we walk away with?” A strong vendor answer: full repository access, working documentation, and a functioning (if incomplete) build. A weak answer involves vague language about “deliverables provided upon completion of milestones,” which can leave you with nothing if the relationship ends early.

For MNC buyers dealing with legacy modernization work specifically, this question also needs to cover how the vendor handles your existing intellectual property and any third-party licenses already in your stack — a detail that’s frequently glossed over in RFP templates built for greenfield projects.

5. What Are Your Actual Security and Compliance Practices — Not Certifications, Practices?

Certifications (ISO 27001, SOC 2) are useful filters but not sufficient ones, since a large certified vendor can still assign an inexperienced, poorly supervised subcontracted team to your specific project. Ask instead about practices tied to your project directly: how access to your production data is scoped and audited, how the vendor handles GDPR-relevant data if any of your users are in the EU, and what their incident response process looks like if a breach occurs during the engagement.

As Gartner has noted in its research on outsourcing risk, compliance failures in vendor relationships are disproportionately traced back to unclear data-handling practices at the individual engineer level, not gaps in the vendor’s corporate certification. Get the practice-level answer, not just the certificate.

Push further on data residency specifically if your organization has EU customers. Ask where production data actually lives during development and testing — not just in the final deployed environment. It’s common for vendors to build and test against a copy of production data on infrastructure that was never evaluated for GDPR compliance, creating exposure long before go-live. A vendor with a mature process for this will describe data masking or synthetic test data practices unprompted, because they’ve already had this conversation with a previous enterprise client.

6. What Does “Done” Actually Mean in Your Definition of Done?

A vendor with real engineering maturity has a specific, written Definition of Done that includes code review standards, test coverage thresholds, and acceptance criteria tied to actual functionality — not just “the client approves it.” Ask for the literal checklist. This single artifact tells you more about the quality discipline you’re buying than almost any other part of the RFP, because it reveals whether the team treats software delivery as a manufacturing process with quality gates, or as a series of demos followed by invoices.

7. What Happens When Something Breaks in Production at 2am on a Friday?

This question exposes the difference between a vendor selling development hours and a vendor acting as a genuine long-term partner. Ask for their actual support SLA, escalation path, and — critically — whether the people on that escalation path are the same engineers who built the system or a separate, unfamiliar support team. A dedicated development team model, where the same engineers who built your product also carry support responsibility, tends to resolve incidents faster simply because there’s no context-transfer delay.

This is also where communication practices matter more than almost anywhere else in the relationship. Vendors combining Scrum discipline from the Netherlands with Vietnam’s deep technical talent pool — the model Manifera runs — build support processes around genuine timezone overlap with European working hours, so an incident raised at the end of a European workday doesn’t sit untouched for sixteen hours. Ask any finalist to walk through their actual overlap hours and escalation contacts, not just their stated SLA number.

Question 8: How Do You Communicate Bad News?

This question rarely appears on a standard RFP template, and it’s the one that predicts relationship longevity better than almost any technical answer. Ask each finalist to describe an actual instance where they had to tell a client a deadline would slip or a technical approach wasn’t working. Vendors who answer with a specific story — what they said, how early they raised it, what the client’s reaction was — have almost certainly been through this before and have a mature process for it.

Vendors who can’t produce a concrete example, or who claim they’ve “never missed a deadline,” are either inexperienced or not being fully honest with you during the very process meant to establish trust. Neither is a good sign for a multi-year bespoke development relationship where honest, early bad news is worth far more than polished good news delivered late.

Turning These Questions Into a Scoring Framework

Once you’ve collected answers across these eight questions from each finalist, resist the urge to average scores into a single number immediately. Some of these questions function as gates rather than scores — a vendor who can’t name their actual team, or who won’t commit to continuous IP transfer, has failed a gate regardless of how well they score everywhere else. Reserve numeric scoring for the questions where genuine gradation exists: code quality, Definition of Done rigor, communication maturity, and support responsiveness.

Circulate the completed scorecards to whoever holds budget authority before the final decision meeting, not during it. Enterprise procurement processes frequently compress the final decision into a single meeting where the loudest opinion in the room wins. Giving stakeholders the raw scorecard data a few days in advance, with gate failures clearly flagged, tends to produce a more defensible outcome — and gives you a paper trail if the chosen vendor underperforms and the decision is questioned later.

With over 160 delivered projects and 120+ clients across a decade, Manifera’s own custom software development team is built to answer every one of these eight questions directly and specifically, including naming the actual engineers who’d be assigned to your project during the RFP stage itself — and our offshore software development model is structured around exactly the continuous, named-team transparency described above. We’d rather lose an RFP on an honest answer than win one on a vague promise we can’t keep, and that’s a bias enterprise buyers can and should test directly during evaluation.

Bring your RFP to our engineering leads for a free technical read — we’ll give you a straight answer on where your current shortlist stands up and where it doesn’t.

The Paper Trail: Financial and Contractual Due Diligence Beyond the Interview

Four documents catch a reseller that a well-rehearsed interview won’t. First, ask for the vendor’s professional liability and cyber-errors-and-omissions insurance certificate naming your organization as an additional insured — a genuine engineering employer carries this as a matter of course; a broker of subcontracted capacity often can’t produce it without involving a third party. Second, request headcount by employment type: how many of the engineers proposed for your project are direct, full-time employees versus contractors or subcontracted staff. A vendor unwilling to give a specific number, even roughly, is telling you the ratio doesn’t favor their pitch.

Third, check the entity actually signing the master services agreement against the entity described in the sales materials — enterprise buyers routinely discover, only at contract review, that the signing entity is a shell reseller layered above the engineering organization doing the actual work. Fourth, ask for average engineer tenure at the company, not team-wide averages padded by long-tenured account managers; under 18 months average tenure on the engineering side is a leading indicator of the churn that will show up as unfamiliar faces on your project by month six. None of these four checks requires legal counsel to run — a procurement analyst can complete all four in an afternoon, and a vendor’s response speed to the request is itself a data point.

FAQs