Short answer

Choose an enterprise software development company on ten weighted criteria: relevant delivered systems you can call about, how they handle discovery and scope, integration and migration experience, security and compliance practice, engagement model and team continuity, communication cadence, ownership of code and infrastructure, support after go-live, commercial transparency, and cultural fit with your stakeholders. Score three shortlisted vendors against the same written scope. The lowest price and the largest logo list are the two weakest signals.

Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.

Selecting the company that builds a core system is a decision you will live with for five to ten years, and most selection processes spend their effort on the two least useful signals: the price and the logo slide. Price tells you how narrowly the vendor read your scope. Logos tell you who their sales team once met. This post gives you a weighted scorecard with ten criteria, the questions to ask references so you get answers rather than politeness, a description of what a good first meeting looks like, and the list of things that should carry no weight at all. It is the vendor-selection chapter of our buyer's guide to enterprise software development, and it works best once you have a written scope, which how to write an RFP for custom software will help you produce.

What should the scorecard measure?

Score each vendor from 1 to 5 on each criterion, multiply by the weight, and total. The weights below suit a core business platform with integrations. Shift them for your situation: a regulated system raises security, a long program raises continuity.

CriterionWeightWhat a 5 looks likeHow to verify
1. Relevant delivered systems15Three or more systems of similar scale and type, in production, with clients willing to talkAsk for the systems, the dates, what they do now, and the reference contacts. Call them.
2. Discovery and scoping practice12A defined discovery phase with written outputs, priced separately, and a willingness to challenge your scopeAsk what discovery produces and whether the build price is final before it. See the discovery phase.
3. Integration and migration experience12Named integrations with ERPs, CRMs and legacy systems, and migrations with rehearsal and reconciliationAsk how they migrated data on the last project and how they proved nothing was lost.
4. Security and compliance10Secure development practice, access control, audit logging, documented policies, experience in your regulatory contextSend the questionnaire from security questions to ask a vendor.
5. Engagement model and continuity10A model that fits the program, named team members, low turnover, a plan for knowledge transferAsk who will be on the team, for how long, and what happens when someone leaves. See engagement models.
6. Communication and cadence8Working software demonstrated every one or two weeks, a named delivery lead in your time zone, written decisionsAsk to see a sprint review from a current project and the decision log format.
7. Ownership8Code, repositories, cloud accounts, domains and data in your name from day one, assignment of IP on paymentAsk for the clause. Who owns the code says what it must contain.
8. Support after go-live8Defined SLA tiers, monitoring, an upgrade roadmap, and the same engineers available after launchAsk for the support schedule and the tier pricing in the proposal.
9. Commercial transparency9A quote with discovery, design, migration, testing and support as separate lines, with assumptions stated and a change process definedRead the quote against how to read a software development quote.
10. Fit with your stakeholders8They explain technology in plain language, listen to operations staff, and disagree with you when they shouldPut a non-technical stakeholder in the first meeting and ask them afterwards.

What does a good first meeting look like?

You talk less than you planned to. The vendor asks about the process, who runs it today, what breaks, which systems it touches, what the data looks like and who owns it. They ask what success means in numbers. They ask about budget and timeline early, without apology, and they react to the answers with a view rather than a nod. At some point they tell you something you did not want to hear, usually that a part of the scope should wait, that an integration will be harder than you think, or that the data will need more cleaning than anyone has admitted. Then they describe what discovery would produce and what it costs, rather than quoting the whole program from a conversation. A vendor who leaves the first meeting with a price for the whole program has either not listened or does not intend to hold the price.

Which reference questions get real answers?

References are chosen by the vendor, so the questions have to do the work. Ask the reference these, in this order, and listen to the pauses.

  1. "What did the system replace, and is the old system switched off?" A modernization whose legacy core is still running two years later did not finish.
  2. "What went wrong, and how did they handle it?" Every real project has an answer. A reference with no answer has been coached or was not close to the work.
  3. "Who was on the team, and are they still at the company?" Continuity is the difference between a vendor and a staffing agency.
  4. "How did the final cost compare with the first quote, and why?" An overrun that was explained and agreed through change requests is normal. An overrun that was a surprise is not.
  5. "How was the data migration, and did you find anything missing afterwards?" The honest answer is usually a small number and a story about how it was fixed.
  6. "What happened in the first month after go-live?" Listen for whether the vendor was still there and whether anyone was on call.
  7. "Would you use them for the next system, and what would you do differently?" The second half of the question is where the information is.

How do you compare a shortlist of three?

  • Send the same written scope to all three. Different briefs produce incomparable proposals. The RFP template in how to write an RFP keeps them comparable.
  • Score before you see the prices. Fill in the scorecard from the meetings, the proposals and the references first, then open the commercial section. Price anchors judgement if it comes first.
  • Normalize the price. Add what each proposal excludes. A quote without migration or support is not cheaper; it is incomplete. How much enterprise software development costs gives the lines that should be present.
  • Check the location logic. Onshore at $120 to $220 per hour (€105 to €190 per hour, £90 to £165 per hour), nearshore at $45 to $90 per hour (€40 to €80 per hour, £35 to £65 per hour) and offshore at $25 to $50 per hour (€20 to €45 per hour, £20 to £35 per hour) are different propositions in overlap, management load and continuity, not just rate. Nearshore vs offshore vs onshore explains which fits which program.
  • Run the red-flag list. Red flags in a software development proposal has it. One serious flag removes the vendor regardless of score.
  • Weigh the pushback. The vendor who challenged your scope most usefully in the first meeting is the one who will keep doing it during the build, and that is where the money is saved.

What should carry no weight?

  • The lowest price. It is the price of the narrowest reading of the scope. The difference arrives as change requests or as a system that does not do the job.
  • The logo slide. Large client names tell you about the sales team. Ask what the vendor actually built for them and whether it is still in use.
  • Headcount. A vendor with 2,000 staff will put six of them on your project, the same as a vendor with 60. Ask about the six.
  • Technology enthusiasm. A vendor who leads with a framework is selling their preference. Enterprise systems should be built on boring, well-supported technology chosen for a ten-year life.
  • Certifications alone. Useful as a floor for security and process, meaningless as a signal of delivery quality. Score the practice, not the badge.
  • Speed promises. A core platform with integrations and migration in three months is a prototype or an untruth. Six to twelve months is honest.
  • Free discovery. Unpaid discovery is a sales process. Paid discovery, at $15,000 to $60,000 (€13,000 to €50,000, £11,000 to £44,000), is work that produces a plan you own.

Choose the vendor that

  • Has built systems like yours that you can call about.
  • Wants to run discovery before pricing the build.
  • Has migrated data and can explain how they reconciled it.
  • Answers the security questionnaire without hesitation.
  • Names the team and keeps it.
  • Shows working software every one or two weeks.
  • Puts everything in your name.
  • Prices support in the proposal.
  • Disagreed with you at least once in the first meeting.

How 7L measures up

We would rather you ran this scorecard on us than took our word for it. 7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens, founded during the Greek financial crisis and now with more than one hundred organizations supported end-to-end, from discovery through design, build, launch and support. We run discovery as a paid, separate phase with written outputs, we modernize incrementally rather than big-bang, we have delivered in regulated industries, IoT and smart buildings, hospitality and fleets, and the code and the cloud accounts are in the client's name from the first commit. We will give you references and we will tell you what went wrong on those projects before the reference does. If you have a scope or an RFP in progress, send it over and we will respond to it as the scorecard asks.

Frequently asked questions

How many software development companies should we shortlist?

Three. Enough to compare, few enough to give each a real meeting, a full proposal review and a reference call. Send all three the same written scope, score them on the criteria before you open the prices, and normalize the prices by adding what each proposal excludes. Longer shortlists produce shallower evaluations.

Should we choose a large consultancy or a specialist firm?

Choose on the team you will actually get and the systems they have delivered, not on the size of the company. A large consultancy puts six people on your project, the same as a specialist firm, and the six are what matters. Specialist firms often offer more senior involvement and better continuity; large consultancies offer scale for very large programs. Score both on the same card.

Is a paid discovery phase a red flag?

The opposite. Paid discovery, typically 3 to 8 weeks at $15,000 to $60,000 (€13,000 to €50,000, £11,000 to £44,000), means the vendor takes scoping seriously and produces a written plan, architecture and phased price that you own and can take to any vendor. Free discovery is usually a sales exercise that produces a proposal rather than a plan. A vendor who prices the whole program without discovery will not hold the price.

How much weight should price carry in vendor selection?

Less than most selection processes give it, and only after normalization. Score the vendors on delivery criteria first, then add to each price whatever the proposal excludes: discovery, design, migration, testing, documentation, support. Compare the normalized totals. A proposal 20 percent cheaper that excludes migration is more expensive, not less.

What is the single most reliable signal of a good vendor?

Reference calls where the client describes something that went wrong and how the vendor handled it. Every real project has such a moment. A vendor whose references all describe a flawless delivery either coached the references or picked clients who were far from the work. Follow with whether the legacy system was actually switched off.