共用的那一段：制度層
公司設立流程、稅務申報節奏、勞動合約的基本要求、外匯與付款的實務限制——這些不分產業。製造業前輩踩過的制度坑，軟體團隊一樣會踩，這部分的經驗可以直接借，而且應該借。
這也是為什麼查設廠資料仍然有價值：它在制度層的細節密度遠高於任何軟體相關的中文資料。
- 設立、稅務、合約、外匯實務，四項可直接借
- 商會與同業組織累積的制度經驗不分產業
- 這一段別重新摸索，那是浪費
不共用的第一件：選址的邏輯完全相反
設廠看的是園區條件、電力供應、到港距離。軟體團隊這三項全部不重要，它看的是工程師住在哪個城市、通勤是否可行、辦公室租得到租不到。
所以「哪個園區優惠好」這個問題對軟體團隊沒有意義，而「這個城市有多少符合技術棧的工程師」這個問題在設廠資料裡查不到。兩套資料互相補不上。
不共用的第二件：成本結構的形狀不同
設廠的支出前重後輕：廠房與設備是一次性大額，之後是相對可預測的人力與耗材。軟體團隊沒有這個前段，它從第一天到最後一天都是人——沒有攤提、沒有殘值、也沒有設備可以抵押。
這個差異會影響現金流規劃與停損判斷。設廠停損要處理設備與場地，軟體團隊停損帳面上很乾淨，代價是知識流失——那筆成本不會出現在任何一張報表上。
- 設廠：前重後輕，有殘值
- 軟體團隊：全期都是人力，無殘值
- 停損判斷因此完全不同——一邊看設備處置，一邊看知識能不能留下
不共用的第三件：人力市場是兩個市場
一般人力與特定技術棧的工程師，在越南是兩個供需結構不同的市場。後者供給窄、流動快、薪資彈性大，而且官方沒有職類層級的薪資統計，只能靠第三方聚合判斷量級——這一點單獨寫在別拿越南全國平均薪資估工程師成本。
如果還在決定要不要自己設實體，可以先比較三種合作形態的風險歸屬，見軟體外包的三種計價模式。不少人算完會發現，先用委外或駐點跑一段，再決定要不要設實體，比一開始就設實體省很多。