Where this scorecard comes from
The POLISH team is a vendor, and this article is written from the vendor's side.
The team works from its own standard for writing quotations: scope is listed exhaustively, every deliverable can be judged on the spot, and when the two conflict, scope gets pinned down first. Turn that standard around and it becomes the set of checks a buyer can run on a vendor.
Scorecard: confirm each row with the vendor
| What to check | What to confirm | A good answer | Warning sign |
|---|---|---|---|
| Scope | Confirm that the listed pages, features, and data tables make up the full scope of delivery | Every item can be counted one by one, anything not listed is stated to be priced separately, and negative statements are reserved for easily misread matters such as ERP integration, apps, and payment processing | Only a general description, with no way to count how many items there are |
| Judging delivery | Ask the vendor to explain how each item will be judged complete on the spot | Written as a series of actions that can be finished on the spot | Wording such as “optimized,” “refined,” “smooth,” “good,” or “attractive” |
| Data specifications | Ask the vendor to state, table by table, who prepares the data and who maintains it | The spec has a “who fills this in” column | No such column, so who maintains the data becomes an argument later |
| Fixes and new requests | Ask the vendor how a broken feature and a new request are each priced | Separated before signing: a feature in the contract that stops working is fixed free of charge, and a request beyond scope gets a transparent quote | “To be discussed later” |
| Fees | Ask the vendor to list what is already included and which third-party fees the client pays | Included items (templates, tools, data migration, training) are stated as not billed separately; third-party service fees are paid by the client | A single total price |
| Client responsibilities | Ask the vendor to list what the client must provide and how delays are handled | The main contract lists the client's responsibilities and states that delays extend the schedule | A schedule that spells out only the vendor's obligations |
| Data ownership | Confirm who owns the deliverables and the data | The main contract states ownership explicitly | Nothing in writing, only a verbal “of course it belongs to the client” |
| MVP | Ask the vendor what was cut from the first phase and how the cut items are handled for now | A stated reason: whether a third-party document requires it, whether the client will actually use it now, whether a zero-cost manual substitute exists, and whether it affects the client's channels or organization | Everything is built, or items are cut with no reason given |
| Track record and records on file | Ask the vendor about comparable projects it has done and the records kept for scans, retests, and fixes | Can describe the size and role on comparable projects; public-sector or large projects have scan, retest, and fix records on file | Talks only about company size and awards, with no comparable project to point to |
| After launch | Ask the vendor how adjustments after launch are handled | For long engagements (six months or more), a follow-up service period: regular check-ins, no deliverable items, with meeting notes as the record | The project closes at launch, and nothing is written about what comes after |
Sentences to copy before signing
- Please confirm that the pages, features, and data tables listed in the quotation are the full scope of delivery, and that anything not listed counts as a new request.
- Please explain how each item in the delivery table will be judged complete on the spot.
- Please confirm the following: a feature in the contract that stops working is fixed free of charge, and a new request beyond scope is quoted transparently before work begins.
- Please state how long after delivery, with no objection raised, the work is deemed accepted.
- For a public-sector project, acceptance may require additional proof that the software was legally obtained. Please explain who prepares that proof.
- If the project includes AI Q&A, please explain who organizes the data. (For the basic concept, see RAG for enterprise knowledge Q&A.)
- If a third-party review has to be passed, such as a vulnerability scan or penetration test, please explain which documents the vendor will help produce; whether it passes is decided by the reviewing party, so the vendor can only help produce the documents and cannot guarantee a pass.
Practices the team follows and checks it applies to itself
The gap between the envisioned feature list and a reasonable scope
The team reads client materials in a fixed order: first the client's obligations to third parties and the audit clauses that apply, then the existing systems, and only last the envisioned feature list. In the team's experience, the client's envisioned feature list is usually 1.5 to 3 times larger than a reasonable scope, so every item is checked against whether a third-party document requires it and whether the quotation covers it. Anything with neither gets moved out of scope. When a client lists a long set of features and the vendor cuts none, ask the vendor to explain how it decided.
Total amount divided by months
Divide the total amount by the total number of months in the contract to see how many people the budget can support each month, then decide how hard to cut the MVP. What matters is not what a project costs but how many months it has to be sustained. A client can run the same arithmetic on a quotation, and if scope and price do not line up, ask the vendor which side will shrink.
Checking numbers with a script before delivery
Before delivery, the team runs a script that compares the number of rows in each table with the “a total of N” count stated in the text. One example is text that names 6 page paths while the table lists 7 rows. An inconsistency like that, once it is written into a contract, becomes material for a later dispute.
Writing the hard part into the quotation before signing
On one parts-display project, a certain class of parts was hard to build as individual 3D models. Rather than wait until after signing to discuss it, the team wrote it into the quotation: this class of parts is presented through position and angle parameters instead of being modeled one by one; the client supplies the rules for which parts can be combined; and part numbers and scanning schedules are managed in a spreadsheet. Before the client signed, it already knew what this part would end up looking like.
Reverse it: ask the vendor how the hardest part of the work is written into the quotation. If the vendor cannot answer, the matter has not been made clear yet.
Judge security and operations by the record
Security and operations ability is best judged from the record. Ask the vendor to name the government or large-scale projects delivered and the role played in each, then see how findings from vulnerability scans and source code reviews were fixed and what retests showed, and finally confirm how the post-launch SLA is written into the contract.
- Similar projectsScale and role played
- Scan and retest recordsHow findings were fixed
- SLA in the contract
- All three check outCompare quotes
- No record to showAsk for evidence
SLA terms are agreed per project and belong in the contract.
The POLISH team has supported Ministry of Education projects for years, including the scans required by the authorities, fixing medium and high risks, and false-positive appeals. For this kind of support and post-launch operations, see Polish+ security and back office.
Consecutive engagements are only one signal
On the Ministry of Education outdoor education resource platform, the POLISH team took on the work from the design tender through to the engineering tender. See the Ministry of Education outdoor education platform case study.
Taking on consecutive tenders is a signal: a team that has done projects in sequential phases has also handled the transitions between phases. Each tender is awarded separately, so this signal should be read together with the other rows of the scorecard.
When this scorecard is not a fit
If the need is an off-the-shelf SaaS product or a one-time small change, this scorecard does not fit. Such needs have no scope that can be listed exhaustively and no post-launch service period, so a product plan or a one-time quotation is enough. The scorecard is for projects that run in phases, have to be sustained for several months, or face a third-party review.
Put it to use
Send the scorecard and the sentences above to every candidate vendor and ask for written answers. The POLISH team's quotation can also go into the same comparison table; contact the team.
