WRITING / VENDOR SELECTION

10 Questions to Ask Before Choosing an IT Vendor in Hong Kong

A field-tested checklist from a decade of seeing what separates a partner from a contractor — and a contractor from a cost centre.

Mar 12, 2026 8 min read By the AccordHK studio

iWhy this matters more in 2026 than it did in 2014

The Hong Kong SME software market is bigger and stranger than it has ever been. There are more vendors, more frameworks, more cheap offshore subcontracting chains — and considerably more bad outcomes. Picking the wrong partner now costs more because the work has compounded: you have a payment integration that breaks, a legacy mobile app that won't open on iOS 18, an internal tool no one alive understands.

We have walked into a startling number of those rooms, opened the laptop, and read the previous developer's source code. We have seen what good looks like, and what bad looks like. The pattern is always the same: the wrong vendor was chosen at the wrong moment for the wrong reason.

So here are the ten questions that, asked seriously at the start, almost always sort the field.

iiThe ten questions

1. Who will write the code — by name?

Not "our team" — names. The same names that will be on the project the day it ships. If the names change between the sales call and the kickoff, leave.

2. Where will the source code live?

It should live in your GitHub or GitLab organisation from day one, not theirs. If they push back, that is the answer. The code is the deliverable; you should own it as it is written, not when the project is "done".

3. Where will my data live?

If you are in finance, healthcare, education or government work, data residency is a hard requirement. Get an answer in writing about which region the database and storage are in, and what happens if you ask them to migrate.

4. What happens when something breaks at 2am on Chinese New Year?

Every good vendor has an on-call story. Bad vendors say "we monitor closely". Press for: who picks up the phone, what their target response time is in writing, and what an SLA breach actually costs them.

If they cannot tell you the name of the person who will be paged when production goes down, they do not have an on-call rotation. They have a hope.— A.K., recovered from a bad outsourcing engagement, 2024

5. How do you handle scope changes?

Software projects always change. The honest answer is "we re-plan together, and we tell you what it costs in time and money before we do it". The dishonest answer is "we absorb small changes" — meaning the inevitable big change will be silently descoped.

6. Who owns the intellectual property?

You should, on the moment of payment. Get the IP clause in the contract before you sign. Some vendors keep IP "for future support" — this is a trap, designed to lock you in.

7. What is your typical engagement length?

If the answer is 3–6 weeks, you are buying a sprint. If the answer is 9–14 weeks, you are buying a project. If the answer is "years", you are buying a relationship. Decide which one you actually want before you start.

8. Can I talk to two of your previous clients — without you in the room?

A vendor who will not introduce you to a previous client without supervision has something to hide. We always make the introduction and step out.

9. How will I know the project is on track?

The right answer is "weekly demos, in your hands". The wrong answer is "monthly status reports". Status reports are the slowest, most fragile mechanism in software project management; demos are the only one that doesn't lie.

10. What is the smallest version that could ship?

If they cannot answer this in one sentence, they are going to over-build the project. Ask it again on the kickoff call. Ask it again at the halfway point. The discipline of always knowing what the next ship looks like is what separates studios from agencies.


iiiWhat this looks like, in practice

We use a version of this list ourselves when we evaluate our partners — the financial controller, the cloud provider, the accountancy. The questions translate cleanly across industries. The answers tell you who you are actually dealing with.

The right vendor answers all ten quickly, with names, dates, and a paper trail. The wrong vendor answers with reassurances.

If you are in the middle of a vendor selection right now and you would like an outside read, we are happy to spend 30 minutes on the phone — no commitment, no pitch. That offer is real; we have made it for years and most calls end with us recommending someone else.

2026 年比 2014 年更重要的原因

香港中小企的軟件市場前所未有地龐大,也前所未有地古怪。供應商更多、框架更多、廉價離岸分包鏈更多 — 失敗結果也明顯更多。在現在這個時間點選錯合作夥伴,代價會更大,因為工作會累積:壞掉的支付整合、無法在 iOS 18 開啟的舊應用、沒人看得懂的內部工具。

我們進過令人吃驚數量的這種房間,打開筆電,讀前任開發者的程式碼。我們見過「好」與「壞」分別的樣子。模式總是一樣:在錯的時刻,因為錯的原因,選了錯的供應商。

以下十條問題,只要在開始前認真問,基本上就能篩走九成不合適的對象。

十條問題

1. 由誰寫程式 — 用名字回答

不是「我們的團隊」 — 要名字。同一個名字,要在出貨當天仍然在這個項目上。若銷售與啟動之間名字改了,離開。

2. 程式碼放在哪裡?

第一天起,應該放在你公司的 GitHub 或 GitLab,不是他們的。若他們推搪,這就是答案。程式碼就是交付物,你應該邊寫邊擁有,而非「完工」才擁有。

3. 我的資料放在哪裡?

若你身處金融、醫療、教育或政府領域,資料留港是硬性要求。要在白紙黑字上得到答案:資料庫與儲存的地區,以及若你要遷移,會發生什麼。

4. 農曆年凌晨兩點出事,會發生什麼?

好供應商有一個 on-call 故事。差的供應商說「我們會密切監察」。追問下去:誰會接電話、回應時間的書面承諾、違反 SLA 對他們的代價。

若他們答不出生產環境出事時會打電話給誰的名字,他們就沒有 on-call 輪值。他們只有一份僥倖。— A.K.,2024 年從一次糟糕的外包合作中脫身的客戶

5. 範圍變更如何處理?

誠實的答案是「一起重新規劃,動工前先告訴你需要多少時間與費用」。不誠實的答案是「小幅變更我們吸收」 — 意思是日後不可避免的大變更會悄悄被縮減。

6. 知識產權誰擁有?

付款一刻就應屬於你。簽合約前先看清 IP 條款。有些供應商會保留 IP「以便日後支援」 — 這是陷阱,專為鎖死你而設。

7. 典型合作期多長?

若答案是 3-6 週,你買的是衝刺。若是 9-14 週,你買的是項目。若是「以年計」,你買的是關係。開始前先想清楚你要的是哪一種。

8. 可否讓我與兩位前客戶通話 — 不需要你在場?

不肯讓你私下與前客戶溝通的供應商,有事要瞞。我們每次都會做引介,然後離場。

9. 我怎知項目進度正常?

對的答案是「每週示範,在你手上」。錯的答案是「每月狀態報告」。狀態報告是軟件項目管理裡最慢、最脆弱的機制;示範,是唯一不會說謊的機制。

10. 可以出貨的最小版本是什麼?

若他們不能用一句話回答,他們會把項目做大。啟動會議再問一次。中段再問一次。永遠清楚「下一個出貨點長什麼樣」的紀律,正正分隔了「工作室」與「代理公司」。


實際運作的樣子

我們自己評估我們的夥伴時 — 財務、雲服務商、會計 — 也用這份問題的變奏版。問題跨行業通用,而答案告訴你眼前是怎樣的對手。

對的供應商會用名字、日期與文件紀錄迅速回答全部十條。錯的供應商會用安撫的話回答。

若你正在挑選供應商,想要一個局外人的視角,我們很樂意花 30 分鐘通電話 — 無承諾、無推銷。這個邀請是真的:我們多年來一直這樣做,大部分電話都以我們推薦其他人結束。

/ / WORKING ON THIS?

Bring us the messy bit.

The first call is free and 45 minutes long. We listen first, and tell you honestly whether we're the right team.