How to Choose a Custom Software Vendor: 10-Point Checklist

The right vendor is judged less by their pitch and more by how they handle ownership, contracts, and what happens after go-live — this checklist covers the 10 questions that actually separate a reliable long-term partner from one that only looks good on a sales call. Picking the wrong vendor is expensive in ways that don't show up in the initial quote: a missed handover clause, an unclear ownership term, or a vendor that disappears after launch can cost more in rework, downtime, and legal friction than the project itself.

If you're still working out what a custom build should realistically cost before you shortlist vendors, see our custom software development cost guide for Singapore businesses for the full pricing and planning picture.

1. Does the vendor have relevant portfolio evidence, not just a client logo wall?

A relevant portfolio shows 2-3 projects in your industry or a comparable technical domain, with specifics on scope, timeline, and outcome — not just a list of company names. Anyone can display logos. What matters is whether the vendor can walk you through a project similar to yours: same industry constraints (inventory complexity, compliance requirements, integration count), similar scale, and a clear account of what worked and what didn't.

Ask for the actual deliverable, not just a screenshot. A vendor building a logistics dispatch system should be able to explain how they handled route optimization edge cases or third-party carrier APIs — not just show a dashboard mockup. If every case study reads like generic marketing copy ("delivered on time, exceeded expectations"), that's a signal the vendor hasn't done the reflective work of understanding why a project succeeded or failed.

2. What does the vendor's development process actually look like?

A vendor should be able to describe their process in concrete terms — discovery, sprint cadence, demo frequency, and change-request handling — without resorting to buzzwords like "agile" as a standalone answer. "We use agile" is not a process; it's a label. Ask instead: How often do you demo working software? How do you handle a scope change mid-sprint? Who approves what, and how fast?

A vendor with a mature process will have answers ready: bi-weekly sprints with a demo at the end of each, a documented change-request form with impact assessment, and a named point of contact who isn't the sales rep who closed the deal. Vague answers here often predict vague delivery later — scope creep with no visibility until the invoice arrives.

3. Who owns the source code after the project ends?

You should own 100% of the source code, database, and infrastructure access from day one — not as a negotiated add-on after the contract is signed. This is the single most consequential clause in any custom software agreement, and it's the one vendors are most likely to leave ambiguous by default.

Some vendors build on proprietary frameworks they control, or retain admin-level access to your production environment "for support purposes," which quietly creates vendor lock-in. Ask explicitly: at contract signing, does the agreement state that all code, credentials, and deployment access transfer to us? If the answer is hedged — "usually," "in most cases," "we can discuss that" — treat it as a red flag, not a detail to resolve later.

4. Is the contract specific enough to protect both sides?

A workable contract names the deliverables, defines what counts as "done" for each phase, sets a payment schedule tied to milestones, and specifies IP ownership and warranty terms in plain language. Contracts that are vague about scope ("develop a management system") rather than specific ("develop a 4-module inventory system covering stock tracking, purchase orders, low-stock alerts, and supplier management") leave room for disputes about what was actually promised.

Look for milestone-based payment rather than 100% upfront or a single lump sum at the end — both extremes shift risk unfairly onto one party. A contract that ties 20-30% to acceptance testing gives you leverage to hold the vendor accountable for quality, not just speed.

5. What warranty or post-launch support is included, and for how long?

A standard warranty period covers bug fixes at no extra cost for 30-90 days after go-live, separate from any ongoing maintenance contract. Software has bugs after launch — that's normal. What isn't normal is a vendor treating every post-launch fix as a new billable request.

Ask specifically: what's covered under warranty (bug fixes) versus what's billed as maintenance (new features, performance tuning, capacity upgrades)? In Vietnam, ongoing maintenance for custom-built systems typically runs 15-20% of the original development cost per year, covering security patches, hosting support, and minor adjustments — this is separate from the warranty window and should be spelled out as its own line item, not bundled vaguely into "support."

6. Do Clutch, G2, or independent reviews back up what the vendor claims?

Third-party platforms like Clutch and G2 are useful because reviews are tied to verified projects and include specifics — budget range, project length, and a named reviewer role — which is harder to fabricate than testimonials on a vendor's own website. Cross-check the vendor's self-reported case studies against what's independently verifiable.

Read the reviews that mention problems, not just the five-star ones. A vendor with a 4.6 rating and reviews that mention "communication was slow in month two but they fixed it" is often more trustworthy than one with a suspiciously flawless record — real projects have friction, and how a vendor responds to it tells you more than a perfect scorecard.

7. How does the vendor communicate across time zones and language?

A reliable vendor commits to a specific communication cadence — typically a weekly status update plus ad hoc availability during your business hours — and assigns one accountable contact rather than routing every question through a shifting cast of developers. For Singapore businesses working with a Vietnam-based team, this matters more than most buyers initially expect.

Ask how they've handled communication with other Singapore or international clients: What tools do they use (Slack, email, a project tracker)? Is there someone who can join a call during Singapore business hours? A vendor that treats communication as an afterthought during the sales process usually treats it the same way during delivery.

8. What happens if the vendor and the business don't match on scale or specialization?

Match the vendor's typical project size to yours — a shop that mostly builds smaller MVPs may not have the process maturity for a large multi-module ERP, and vice versa: an enterprise-focused vendor may over-engineer and overcharge a small pilot. Ask directly what their median project size and team size looks like, and compare it to your own scope. For a sense of what different tiers of project typically run in Singapore, our cost guide breaks down MVP, mid-range, and enterprise ranges side by side.

This cuts both ways on cost. Offshore teams can offer different rate structures without cutting corners on process — it's a function of overhead and market cost of living, not shortcuts — so a lower rate on its own isn't a red flag; the questions above about process, contract, and ownership are what tell you whether it holds up.

9. Has the vendor been transparent about pricing from the first conversation?

A trustworthy vendor gives you a realistic estimate range early, tied to scope, and explains what would move the number up or down — rather than giving a lowball figure to win the deal and revising upward once you're committed. Transparency here is a leading indicator of transparency everywhere else in the relationship.

If you're still weighing whether a custom build or an off-the-shelf SaaS subscription makes more sense at your scale, our 3-5 year TCO comparison walks through the total cost picture — including how subscription costs compound versus a one-time build with predictable maintenance.

Giá tham khảo, báo giá chính xác sau khi khảo sát nghiệp vụ.

10. What are the clearest red flags that a vendor should be dropped from the shortlist?

The five clearest red flags are: refusal to put source-code ownership in writing, no reference clients willing to speak with you, pricing that's dramatically below every other quote with no explanation, a contract with no milestone structure, and pressure to sign within 24-48 hours. Any one of these alone is worth a direct follow-up question; two or more together is a reason to walk away.

A legitimate vendor doesn't need to rush you. If a quote seems unusually low, ask what's excluded — testing, deployment support, and warranty are common places costs get stripped out to win on headline price, only to reappear as change requests later. A vendor confident in their work will happily connect you with a past client for a reference call; one that hesitates is telling you something.

FAQ

How many vendors should I shortlist before deciding? Three to five is typically enough to compare process, pricing structure, and communication style without the evaluation itself becoming a project. More than five tends to slow decision-making without adding meaningfully different information.

Should I choose the vendor with the lowest quote? Not by default. Compare what's included — testing, warranty period, source-code handover, and support terms — since a lower headline number sometimes excludes items that reappear as extra costs later.

Is a signed NDA a sign of a professional vendor? It's a baseline expectation, not a differentiator. Any vendor handling your business data or codebase should sign an NDA without hesitation before discovery begins.

Can I request a paid discovery phase before committing to the full project? Yes, and it's a reasonable way to test a vendor's process on a small scale — a short paid discovery or scoping phase lets both sides confirm fit before signing a larger contract.

Does a vendor need ISO or similar certification to be trustworthy? Certification can indicate process discipline but isn't required — many capable vendors operate without formal certification. Portfolio evidence, contract clarity, and reference checks matter more in practice.

---

Ready to evaluate a vendor against this checklist with your own project? Contact FutureTech for a business requirements survey and a transparent quote — you'll see exactly how we handle ownership, contracts, and warranty terms before you commit.