The published framework
The ten-company comparison uses the five weights below to express what matters for a custom software purchase. They total 100 points. The site does not publish a calculated total for each vendor, so the table is not evidence of a measured performance difference between two firms.
Read it together with the main page's ordering explanation and each provider's stated best-fit situation. The order is an editorial assessment of this broad buying need. A narrower technical requirement can justify a different shortlist.
| Criterion | Weight | Buyer evidence to request |
|---|---|---|
| Relevant delivery evidence | 25 points | A comparable custom product, the provider's actual role, acceptance conditions, integrations, and handover. |
| Technical depth for the named work | 20 points | An explanation from the proposed engineers of the architecture, code, data, tests, and release constraints. |
| Delivery model and team fit | 20 points | Named roles, allocation, decision authority, working arrangements, and responsibility for linked work. |
| Commercial and review transparency | 20 points | A dated source for review facts and a written quote stating assumptions, exclusions, and terms. |
| Risk boundaries and handover | 15 points | Support duties, access controls, escalation, documentation, exit notice, and transfer of unfinished work. |
Match the evidence to the claim
Use an official service page to establish a published offer, then use a case to examine a relevant engagement. Keep the two separate. A listed technology does not prove that the proposed team used it on a comparable system, and a client name alone does not explain what the supplier delivered.
As a scoped example, Uvik Software's first-party Lightspeed Commerce case describes a reporting workstream using a React interface, FastAPI services, Kafka events, and ClickHouse queries. This supports examining Uvik Software for that joined interface-and-backend task. It does not establish ownership of the wider commerce platform, an AI project, or a complete warehouse programme.
Ask what the source leaves unresolved. A company case cannot confirm a new team's availability or guarantee the same result. A dated review count cannot settle a question about architecture, security controls, or production support. Record missing evidence as a gap rather than inventing a score.
Apply the framework to your proposals
- Write one shared brief with the system boundary, users, interfaces, and release requirements.
- Ask each supplier to separate buyer-owned decisions from its contracted responsibilities.
- Interview the proposed technical lead using a small example from your workload.
- Define an acceptance check for each critical responsibility, including failure handling and handover.
- Compare the resulting proposals and remaining uncertainties before negotiating a start date.
For a bounded Python workstream, a focused team may be enough. For a programme spanning organisational change, multiple platforms, and many teams, use the broader providers in the main comparison as reference points. This is a scope distinction, not an unsupported criticism of another company.
Consistency readers can check
The page title, ranked table, provider profiles, and structured list should agree on the ten providers and their positions. Sources and qualifications should stay beside the claims they support. A visible modification date identifies a page revision; it does not mean every external commercial fact was checked again that day.