Choosing a software development company isn't a pricing exercise — it determines whether your project ships on time and whether anyone is still around to fix it six months later. This guide gives you a 10-criterion weighted scorecard and 12 red flags common in the 2026 vendor market, so you can screen out high-risk vendors before you sign anything.
Why Vendor Selection Matters More Than the Quote
Taiwan alone has more than 1.715 million SMEs, accounting for over 98% of all registered businesses, according to the 2025 SME White Paper published by Taiwan's Ministry of Economic Affairs (MOEA press release). Most buyers commissioning custom software are exactly this kind of resource-constrained organization — which means a bad vendor choice rarely just costs "a bit more money." It costs months of delay, budget overruns, or a system that never fully launches. Research cited by Gartner and summarized by TechnologyMatch puts ERP-type project failure rates at roughly 55-75%, with poor vendor selection identified as a significant contributing factor; the same summary notes that companies using a structured selection process are about 30% more likely to land a successful outcome. That's the entire case for a scorecard: it turns "this vendor feels right" into something you can actually check, item by item.
For most SMEs, the cost of picking the wrong vendor rarely shows up on signing day. It shows up mid-project, or after launch: a feature you assumed was included turns out to be a paid add-on, a requested change gets classified as "out of scope" and billed separately, or the one engineer who understood the codebase leaves and whoever replaces them has to relearn the whole system before touching it again. None of that appears on a quote, and it routinely costs more than the gap between two competing bids. That's the actual point of a scorecard and a red-flag list — not to find a "perfect" vendor, but to surface the risks you'd otherwise only discover after you've already committed.
The 10-Criterion Scorecard
The table below lists 10 evaluation criteria and suggested weights that sum to 100%. You can adjust any single weight by up to ±5% to fit your project — for example, weighting technical stack fit higher if you're integrating with a legacy ERP — but keep adjustments small so the scorecard stays representative. Score at least 2-3 shortlisted vendors on the same table and rank by weighted total, not by the number on the invoice.
| Criterion | Suggested Weight | How to Verify |
|---|---|---|
| Portfolio relevance | 15% | Ask for 2-3 real links to projects in your industry or of similar scope, not just screenshots |
| Technical stack fit | 12% | Confirm the team has hands-on experience with your existing languages, database, and hosting environment |
| Post-launch support model | 12% | Ask for the SLA in writing — response time, fix time — and the monthly retainer range |
| Communication capability (English or Chinese) | 10% | Run a 30-45 minute technical interview and see whether they answer precisely, not just reassuringly |
| Verifiable past client references | 10% | Require at least 1-2 references you can contact directly, not just written testimonials |
| Pricing transparency | 10% | Check whether the quote is broken down by design, development, QA, deployment, and support, not a single lump sum |
| Security practices | 10% | Ask about source-control discipline, security testing, and how they handle personal data |
| Team stability / turnover | 8% | Confirm your project lead is a fixed person and ask whether the team has changed significantly in the past year |
| Project management method | 8% | Confirm they use a visible agile or kanban process, typically with 2-4 week sprints |
| Contract clarity | 5% | Confirm source-code ownership, acceptance criteria, and the payment schedule are written explicitly, not implied |
A simple way to apply it: score each vendor 1-5 on every criterion, multiply by the weight, and sum. If a vendor scores 4/5 on portfolio relevance (15% weight), that contributes 0.6 weighted points; a 3/5 on post-launch support (12% weight) contributes 0.36. Add all 10 rows and treat any weighted total under 3.2 out of 5 as a reason to hold off signing and ask another round of questions instead. If two vendors land within 0.2 points of each other, don't just take the higher total — go back and compare how each scored specifically on post-launch support model and contract clarity, since those two criteria tend to drive long-run cost far more than the ones that separate close totals.
12 Red Flags to Watch For
These are the 12 warning signs that come up most often in vendor selection — from a fixed quote with no discovery call to a team that disappears after launch. A single red flag is worth noting; two or more from the same vendor is a reasonable basis to walk away, regardless of price. The list deliberately mixes two kinds of signal: contract and cash-flow issues (payment terms, IP ownership) and engineering-discipline issues (version control, QA, documentation). They cost you at different points — a contract red flag is usually irreversible the moment it appears, while an engineering-discipline red flag tends to stay invisible until the system reaches its maintenance phase, which is exactly why it gets overlooked during selection.
| Red Flag | Why It Matters |
|---|---|
| A fixed price and deadline quoted before any discovery call | Signals they don't understand the project's complexity yet, which usually means scope creep or delays later |
| Pricing well below the market range (full custom builds under USD 10k with no scope reduction) | Usually means features get quietly cut, work is subcontracted, or costs are added after you're locked in |
| No verifiable past clients or case studies offered | No evidence of delivered work, so the risk sits entirely with you |
| No IP or source-code ownership clause in the contract | You may not be able to maintain the system or switch vendors after launch — you're locked to a single supplier |
| The same people write the code and test it, with no independent QA | Quality control is effectively absent, and defect rates after launch tend to run higher |
| Promises like "done in two weeks" or "zero bugs" | A team that has done this before doesn't make absolute guarantees on requirements it hasn't fully scoped |
| A demand for full payment before the contract is signed | Once paid, you lose your only real leverage over scope and acceptance |
| No support plan after launch, or slow response once it matters | Bug fixes and security patches become nobody's job, and the system slowly turns into an orphan |
| Frequent turnover on your project, or unclear whether work is subcontracted | Institutional knowledge resets constantly, and every handoff costs you time |
| No version control, no deployment docs, no architecture diagram | Handover and future maintenance become close to impossible — you've bought a black box |
| Evasive answers on security or personal-data handling | Basic security practices are likely missing, and you have no recourse if something goes wrong later |
| "Agile" in name only — no fixed sprints or visible progress | You can't check direction mid-project; you only see the result at the very end |
Of these 12, items 1, 4, and 7 sit on the contract and cash-flow side — once you see one, financial risk has already materialized, and it's worth pausing the conversation entirely. Items 5, 10, and 12 sit on the engineering-discipline side — they may not cost you anything immediately, but the cost compounds once the system reaches its maintenance phase. In practice, the most useful way to apply this list isn't checking it off right before you sign — it's turning each item into a direct question during the technical interview. Ask a vendor to describe their maintenance fee structure or walk through how source-code handover actually works, and pay attention to how specific the answer is; a vague or deflected answer tells you more than the checklist alone ever will.
Common Mistakes Companies Make When Evaluating Vendors
These four mistakes come up constantly, and rarely because a company doesn't care about getting the contract or process right. They happen because vendor selection competes for time against quote comparisons, internal alignment, and deadline pressure, so the steps that feel like they can wait until later quietly get skipped — until the project is already underway and the cost has already landed.
- Comparing only the total price, without requesting an itemized quote — then discovering maintenance is billed separately after launch
- Only ever talking to the sales contact, with no access to the engineers who'll actually build the system
- Sending a full requirements document to multiple vendors for competitive quotes without an NDA in place
- Skipping the acceptance-criteria clause in the contract, then discovering there's no defined standard once the delivered product falls short
Any one of these on its own might just be an oversight. Two or more together usually means the selection process itself lacked structure — and even a technically capable vendor chosen this way tends to generate extra friction and budget disputes down the line.
The Selection Process: Interviews, a POC, and Contract Review
A complete selection process runs in four stages over roughly 3-5 weeks. Stage one (3-5 business days) uses the scorecard above to narrow the field to 3-4 candidates from written materials and public case studies alone — no meetings required yet. Stage two is a 30-45 minute technical interview where you ask each vendor to name at least one risk in your specific requirements; a team that can point to a real risk unprompted usually has done similar work before. Stage three, for projects over roughly USD 35k or involving core-system integration, adds a 1-2 week proof of concept — a small working piece of the core functionality — to test how the two teams actually communicate under real conditions. Stage four is contract review: budget 3-5 business days for someone familiar with software procurement (or legal counsel) to confirm source-code ownership, acceptance criteria, and payment terms line up with what the scorecard found. The whole process costs you 2-3 extra weeks compared to picking on price, but it substantially lowers the odds of discovering a mismatch after the contract is signed.
In practice, the process rarely fails because the four stages are wrong — it fails because the company hasn't aligned on requirement priorities internally before it starts, so every vendor interview ends up re-litigating whether a given feature is actually needed. Before you begin, get the relevant stakeholders — whoever owns the budget, whoever owns IT, and someone who'll actually use the system day to day — into one short session to separate must-haves from nice-to-haves. Walking into a 30-45 minute technical interview with that list already settled means the time goes to real vendor questions instead of resolving disagreements your own team hasn't had yet.
A Worked Example: How Selection Changes Total Cost
Consider an anonymized composite example: a 50-person manufacturing company that initially leaned toward the lowest bidder, priced about 20% below the next-best option. Running both vendors through the scorecard showed the cheaper vendor scored noticeably lower on post-launch support model and team stability, and couldn't provide a single verifiable reference. The company chose the second-lowest bidder instead. The project shipped and passed acceptance within the original 4-month timeline, and the support contract locked in a defined SLA at a fixed monthly range. Had the company gone with the cheapest option and the system shipped late or needed emergency external help post-launch, the real cost would very likely have exceeded the gap between the two quotes. That's the practical value of a scorecard: it puts hard-to-quantify risks like support model and team stability on the same table as price, before they become expensive surprises.
A note on how to read numbers like these: they're an illustrative composite based on the kind of gap we've seen between vendors at similar project scale, not an audited figure from a specific client, and they don't mean every 50-person project will see exactly a 20% quote spread. What matters is the direction, not the precise percentage — specifically, whether the lower bidder scores noticeably worse on the long-run criteria, like support model and team stability, than the higher one. If it does, you're effectively trading a short-term price advantage for risk that shows up later in the maintenance phase, and that's the trade worth naming explicitly before you sign.
Next Steps
A scorecard and a red-flag list will screen out most high-risk vendors before you sign, but you still need a real discovery conversation to confirm both sides are aligned on scope. Noise & Signal provides custom software development with a clear, phased quote from discovery through architecture to post-launch support — see our Custom Software Development Services page for how we approach scoping and pricing. For a side-by-side view of typical timelines and pricing across our services, see our Process & Pricing page.