Đầu năm ngoái, mình ngồi cùng một anh chủ công ty logistics 80 người ở Bình Dương. Ảnh đang trả $2,400/tháng cho stack SaaS gồm ShipStation, một CRM ngoại, phần mềm kho nội địa, và 4 tool khác. Và ảnh vẫn phải thuê 2 người nhập liệu full-time vì các tool không "nói chuyện" được với nhau.
"Em có nên build phần mềm riêng không?". Câu hỏi này mình nghe ít nhất 2-3 lần/tháng.
Câu trả lời thật là: đôi khi có, đôi khi không. Bài này là framework mình đã dùng để tư vấn 20+ SME Việt qua quyết định đó, kèm những lần phán sai và học được gì.
Key Takeaways - Chi tiêu SaaS toàn cầu đạt $295 tỷ năm 2025, tăng 19.6% YoY (Gartner, 2025), nên cost thực sự là yếu tố quyết định. - Build custom khi quy trình là competitive advantage + tổng cost SaaS vượt cost build trong 24 tháng + team có khả năng maintain. - 31% dự án phần mềm bị huỷ và 53% vượt budget (Standish CHAOS Report, 2015), discovery phase 4 tuần là không thể bỏ qua. - SaaS trước, custom sau, khi đã biết rõ mình cần gì. Đó là quy tắc 80% SME nên áp dụng.
Mục lục
- Tại sao SaaS không đủ cho một số SME?
- Framework quyết định Build vs Buy như thế nào?
- Kiến trúc phần mềm custom phổ biến cho SME
- Chi phí thực tế — không phải marketing estimate
- Timeline thực tế ra sao? Vì sao luôn trễ?
- Stack lựa chọn cho SME Việt 2026
- 5 sai lầm phổ biến khi build custom
- Case study thật: 3 dự án mình đã làm
- FAQ
1. Tại sao SaaS không đủ cho một số SME?
SaaS giải quyết được 80% use case của 80% doanh nghiệp, nhưng phần 20% còn lại đắt giá hơn bạn nghĩ. Theo Gartner (2025), chi tiêu SaaS toàn cầu chạm mốc $295 tỷ trong năm 2025 (+19.6% YoY), và phần lớn các SME Việt mình tư vấn đang trả $1,500–$3,500/tháng cho stack SaaS chắp vá. Ở scale đó, cost SaaS 24 tháng thường vượt cost build custom.
Quy trình quá đặc thù: Một công ty sản xuất đá nhân tạo ở Long An có quy trình đặt hàng ngược: khách đặt hàng trước, họ mới mua nguyên liệu, sản xuất, rồi mới giao. Không có SaaS nào handle được workflow này mà không cần custom rộng.
Integration hell: Khi bạn dùng 5-7 SaaS và phải copy data qua lại bằng tay (hoặc trả thêm $200-500/tháng cho Zapier/Make), đôi khi build một system riêng integrate tất cả rẻ hơn về dài hạn. Nghiên cứu của MuleSoft Connectivity Benchmark (2024) cho thấy doanh nghiệp trung bình dùng 991 ứng dụng nhưng chỉ 28% được tích hợp với nhau. Phần còn lại là việc tay.
Compliance và data sovereignty: Một số ngành tại Việt Nam (y tế, tài chính, giáo dục công) có yêu cầu dữ liệu phải lưu trong nước, trên server do doanh nghiệp kiểm soát. Nghị định 53/2022/NĐ-CP về bảo vệ dữ liệu cá nhân quy định rõ các loại dữ liệu cần lưu trữ trong nước. SaaS nước ngoài thường không đáp ứng được.
SaaS lock-in và giá leo thang: Mình thấy nhiều trường hợp dùng SaaS 3 năm, vendor tăng giá 40% vì biết khách đã phụ thuộc. Custom software không bao giờ bị tăng giá một chiều.
Toàn bộ lộ trình phần mềm custom cho doanh nghiệp Việt xem tại hub /phan-mem-custom.
2. Framework quyết định Build vs Buy như thế nào?
Theo nghiên cứu McKinsey Digital (2023), 70% các chương trình chuyển đổi số không đạt mục tiêu, và phần lớn thất bại đến từ quyết định sai ngay từ đầu: build cái không nên build, hoặc buy cái không phù hợp. Mình dùng 4 câu hỏi dưới đây mỗi khi tư vấn để giảm rủi ro đó.
Câu hỏi 1: Quy trình này có phải competitive advantage không?
Nếu quy trình là generic (kế toán, HR standard, email marketing), nên Buy SaaS. Nếu quy trình là lý do khách hàng chọn bạn thay vì đối thủ, Consider Custom.
Câu hỏi 2: Tổng chi phí 24 tháng là bao nhiêu?
SaaS cost 24M = monthly_fee × 24 + setup + training + integration_tools
Custom cost 24M = dev_cost + monthly_hosting + maintenance + support
Nếu SaaS cost > Custom cost × 1.5, custom thắng về tài chính.
Câu hỏi 3: Team bạn có khả năng maintain custom software không?
Custom software cần người biết sửa khi bug, upgrade khi cần. Nếu không có CTO hoặc dev in-house, chi phí outsource maintenance cộng thêm 20-40% cost/năm. Nhiều SME quên tính phần này.
Câu hỏi 4: Bạn có biết chính xác mình cần gì không?
"Tôi muốn phần mềm quản lý mọi thứ": đặt cược rủi ro cao nhất. Custom software thành công cần requirements rõ ràng, được viết ra, và ổn định trong ít nhất 80% quá trình build. Nếu bạn đang explore, thử SaaS trước để hiểu mình cần gì.
Scoring: - 3-4 câu trả lời thiên về custom, build custom. - 2 câu mixed, hybrid (SaaS core + custom layer). - 0-1 câu thiên về custom, stick with SaaS.
3. Kiến trúc phần mềm custom phổ biến cho SME
Theo Stack Overflow Developer Survey (2024), PostgreSQL là database được dev yêu thích nhất với 49% trong số 65,000+ developers tham gia khảo sát, và đó là lựa chọn an toàn cho hầu hết app SME. Về kiến trúc, mình thấy 3 pattern lặp lại trong 20+ dự án đã tư vấn, mỗi pattern phù hợp một quy mô khác nhau.
Pattern 1: SaaS Core + Custom Extension
Dùng một platform mạnh (Odoo, Salesforce, HubSpot) làm nền, build custom module/plugin cho phần đặc thù. Chi phí thấp nhất, risk thấp nhất.
Ví dụ: Odoo ERP làm core (kế toán, kho, HR) cộng custom module quản lý đơn hàng đặc thù của ngành sản xuất.
Pattern 2: Microservices với API Gateway
Nhiều service nhỏ, mỗi service làm 1 việc, kết nối qua API. Linh hoạt nhất, phức tạp nhất.
Phù hợp khi bạn đã có tech team mạnh hoặc đang ở scale stage company.
Pattern 3: Monolith với clean architecture
Một ứng dụng, tổ chức code tốt, dễ maintain. Best cho SME build lần đầu. Framework phổ biến: Django (Python), Laravel (PHP), Next.js (TypeScript full-stack).
# Ví dụ kiến trúc Django monolith cho logistics SME
# apps/orders/models.py
class Order(models.Model):
customer = models.ForeignKey(Customer, on_delete=models.PROTECT)
status = models.CharField(choices=OrderStatus.choices, max_length=20)
created_at = models.DateTimeField(auto_now_add=True)
def can_be_cancelled(self) -> bool:
return self.status in [OrderStatus.PENDING, OrderStatus.CONFIRMED]
def total_weight_kg(self) -> float:
return sum(item.weight_kg for item in self.items.all())
# apps/inventory/services.py
class InventoryService:
def reserve_for_order(self, order: Order) -> bool:
"""Atomic inventory reservation, fail-safe"""
with transaction.atomic():
for item in order.items.all():
sku = item.sku
if sku.available_quantity < item.quantity:
return False
sku.available_quantity -= item.quantity
sku.save()
return True
4. Chi phí thực tế — không phải marketing estimate
Báo cáo Standish CHAOS (2015) cho thấy 53% dự án phần mềm vượt budget ban đầu, và 31% bị hủy giữa chừng. Ở Việt Nam, các con số mình thấy thực tế trong Q1 2026 (theo dữ liệu nội bộ từ 20+ dự án mình đã tư vấn) như sau.
| Loại dự án | Timeline | Chi phí dev | Chi phí/năm (maintain) |
|---|---|---|---|
| MVP đơn giản (1-3 module) | 3-4 tháng | 150-400 triệu | 20-50 triệu |
| App trung bình (5-8 module) | 6-9 tháng | 400 triệu-1 tỷ | 60-150 triệu |
| Hệ thống lớn (ERP custom) | 12-18 tháng | 1-3 tỷ | 200-400 triệu |
Những chi phí hay bị quên: 1. Business Analyst / Discovery phase: 20-50 triệu cho requirements gathering đàng hoàng. 2. Testing (QA): 15-20% tổng dev cost. 3. Data migration: Nếu đang có data cũ, 10-30 triệu tùy volume. 4. Training cho staff: 2-5 ngày × số user. 5. Infrastructure: Hosting, domain, SSL, backup, 3-15 triệu/năm. 6. Bug fix warranty period: Thường 3-6 tháng sau go-live.
Theo nghiên cứu của IBM Systems Sciences Institute, chi phí fix bug ở giai đoạn production cao gấp 100 lần so với fix ở giai đoạn design. Đó là lý do discovery phase nên được đầu tư đàng hoàng.
Red flag: Vendor quote quá rẻ (dưới 80 triệu cho app phức tạp) thường có nghĩa: thiếu kinh nghiệm, cut corners, hoặc sẽ tính thêm sau.
5. Timeline thực tế ra sao? Vì sao luôn trễ?
Theo Standish CHAOS Report (2015), chỉ 16.2% dự án phần mềm hoàn thành đúng thời hạn và đúng budget. Trong thực tế các dự án SME mình từng tham gia, vendor quote 3 tháng nhưng thường mất 6-9 tháng, không phải vì vendor lừa đảo, mà vì requirements thay đổi giữa chừng và stakeholder feedback chậm.
Rule of thumb mình dùng: Nhân timeline vendor estimate với 1.5-2x cho planning nội bộ.
Những gì kéo dài timeline nhất: 1. Requirements chưa clear, build xong rồi đổi 30-50% (mình thấy nhiều lần). 2. Phê duyệt chậm từ phía khách hàng (review sprint mất 2 tuần thay vì 3 ngày). 3. Third-party API issues (Zalo OA API thay đổi không báo trước, đã gặp). 4. Data quality issues từ legacy system.
Cách giảm thiểu: Dùng Agile/Scrum với sprint 2 tuần. Mỗi 2 tuần có deliverable cụ thể để test. Không chờ đến tháng 6 mới feedback.
6. Stack lựa chọn cho SME Việt 2026
Theo Stack Overflow Developer Survey (2024), JavaScript vẫn là ngôn ngữ phổ biến nhất với 62% developers sử dụng, Python xếp thứ 3 (51%), và PHP vẫn còn 18%. Ở thị trường VN, độ sẵn có dev đóng vai trò quyết định không kém gì kỹ thuật. Bảng dưới đây là gợi ý mình dùng cho SME 2026.
Backend
| Stack | Khi nào dùng | Dev available ở VN |
|---|---|---|
| Django + PostgreSQL | App phức tạp, data-heavy, AI integration | Nhiều |
| Laravel + MySQL | Team PHP, e-commerce, CMS | Rất nhiều |
| Node.js + PostgreSQL | Real-time features, API-first | Nhiều |
| Odoo (Python) | Muốn ERP foundation cộng customize | Trung bình |
Frontend
- Next.js (React): Modern, SEO-friendly, tái sử dụng code với mobile.
- Vue.js: Dễ học hơn React, community VN lớn.
- Flutter: Nếu cần mobile app iOS cộng Android song song.
Hosting
- AWS (ap-southeast-1): Chuyên nghiệp nhất, cần DevOps.
- DigitalOcean: Đơn giản hơn, đủ cho đa số SME.
- Viettel IDC / VNPT: Data sovereignty requirement, server đặt VN.
7. Năm sai lầm phổ biến khi build custom
McKinsey Digital (2023) chỉ ra rằng 70% chuyển đổi số thất bại, và nguyên nhân thường lặp lại. Năm sai lầm dưới đây mình đã chứng kiến trực tiếp ở SME Việt, và mỗi cái đều tốn 6 chữ số USD nếu không tránh được.
Sai lầm 1: Không có BA/Product Owner phía khách hàng
"Em tự làm hết cho anh nhé.". Câu này mình nghe nhiều. Không có người phía khách hàng chịu trách nhiệm requirements, dev build theo hiểu biết, cuối cùng sai 40% use case.
Sai lầm 2: Cố build feature "sẽ cần trong tương lai"
YAGNI: You Aren't Gonna Need It. Mình thấy nhiều dự án build 60 module, cuối cùng dùng 15. 45 module còn lại tương đương $200K đổ xuống sông.
Sai lầm 3: Không có staging environment
"Cứ deploy lên production cho nhanh.". Một lần đủ học bài học này. Production bug = business down = stress thật sự.
Sai lầm 4: Không có data backup plan từ ngày 1
Database corruption không có backup tương đương dữ liệu 3 năm mất hết. Mình biết 2 trường hợp như thế này. Đủ rồi.
Sai lầm 5: Chọn vendor theo giá thấp nhất
Phần mềm rẻ cộng build xong abandon tương đương tốn gấp 3 lần để thuê vendor khác fix và maintain. Chọn theo portfolio, reference từ khách cũ, và khả năng communicate.
Nếu muốn tích hợp AI vào phần mềm custom, xem AI Agent là gì?. Bài đó có section về architecture kết hợp AI agent vào hệ thống business logic.
8. Case study thật: 3 dự án mình đã tham gia
Theo dữ liệu nội bộ từ 20+ dự án custom software mình tư vấn (2020-2026), tỷ lệ thành công khoảng 60% (12/20), partial winner 25% (5/20), và 15% (3/20) không nên build ngay từ đầu. Ba case dưới đây đại diện cho mỗi nhóm.
Case 1: Logistics 80 người, Winner
Bài toán: 6 SaaS không nói chuyện được với nhau, 2 nhân viên nhập liệu full-time.
Solution: Django monolith tích hợp Zalo OA, vận chuyển (GHN, GHTK), kế toán MISA qua API. Single source of truth.
Kết quả: Giảm từ $2,400/tháng SaaS xuống $400/tháng hosting cộng $60K/năm maintenance. 2 nhân viên nhập liệu chuyển sang công việc khác (không sa thải). ROI dương sau 11 tháng.
Case 2: Phân phối F&B, Partial winner
Bài toán: Quản lý 200 đại lý, đặt hàng qua Zalo.
Solution: Custom app với Zalo OA integration. Build 4 tháng.
Vấn đề: Owner thay đổi requirements 3 lần giữa chừng. Timeline thực tế: 9 tháng. Budget overrun 60%.
Lesson: Discovery phase không đủ kỹ. Giờ mình bắt buộc 4 tuần discovery riêng trước khi quote.
Case 3: Retail 15 cửa hàng, không nên build
Bài toán: Muốn POS cộng inventory cộng loyalty riêng.
Recommendation của mình: Dùng KiotViet cộng addon. Không cần build từ đầu.
Kết quả: Họ thuê vendor khác build, tốn 8 tháng và 600 triệu. Cuối cùng vẫn thiếu tính năng KiotViet có sẵn. Giờ họ dùng KiotViet.
Tích hợp ZaloCRM vào hệ thống phần mềm custom của SME: xem ZaloCRM. Có API documentation và integration guide đầy đủ.
FAQ — Câu hỏi thường gặp về phần mềm custom
Q1: SME bao nhiêu nhân viên thì nên cân nhắc custom software? Không phải số nhân viên mà là complexity của operations. Mình thấy công ty 15 người nhưng quy trình đặc thù cần custom, và công ty 200 người dùng Odoo off-the-shelf hoàn toàn OK. Theo Gartner (2025), SaaS spending tăng 19.6% YoY, vậy rule of thumb: khi bạn đang trả >50 triệu/năm cho SaaS stack và vẫn cần 1-2 nhân viên nhập liệu thủ công, đáng xem xét custom.
Q2: Outsource hay thuê in-house developer? In-house: tốt hơn khi software là core business, cần iterate nhanh, knowledge retention quan trọng. Outsource: tốt hơn cho one-time build, khi chưa biết tech requirements, hoặc cần chuyên môn đặc biệt (AI/ML, infrastructure phức tạp). Hybrid (in-house 1 PM/BA, outsource dev) thường là giải pháp tốt nhất cho SME, theo kinh nghiệm 20+ dự án mình đã làm.
Q3: Mã nguồn sau khi build xong thuộc về ai? Phải ghi rõ trong hợp đồng: bạn phải sở hữu 100% source code sau khi thanh toán đầy đủ. Nhiều vendor không nói thẳng điều này. Nếu không có source code, bạn phụ thuộc vào vendor mãi mãi. Đây là điều không thể thỏa hiệp. Theo BSA Global Software Survey (2018), 37% SME bị mắc kẹt với vendor cũ vì IP rights không rõ ràng.
Q4: Có thể dùng AI (Claude, ChatGPT) để giảm chi phí dev không? Có và đáng kể. Theo GitHub Copilot Research (2022), dev dùng AI assistant tăng 55% productivity trên các task hoàn thành code. Nhưng AI không thay thế kinh nghiệm architecture và domain knowledge. Budget tiết kiệm được nên đầu tư vào senior developer review.
Q5: Phần mềm custom có cần nâng cấp thường xuyên không? Có, và đây là chi phí ẩn lớn nhất. Dependencies (framework, thư viện) cần update bảo mật thường xuyên. Theo Snyk State of Open Source Security (2024), 84% codebase chứa ít nhất một lỗ hổng đã biết trong dependencies. Tính thêm 15-25% build cost/năm cho maintenance, nếu không sau 3-4 năm tech debt tích lũy và phải rebuild.
Q6: Nên chọn SaaS nào làm foundation để extend custom? Odoo là nền tảng phổ biến nhất ở Việt Nam cho SME muốn có ERP foundation mạnh cộng khả năng custom. Salesforce cho enterprise. WooCommerce/Shopify cho e-commerce. Mình thích Odoo vì open-source, community VN lớn, và module ecosystem đủ rộng. Theo Odoo Annual Report (2024), Odoo có 12+ triệu users toàn cầu và 4,000+ apps trong store.
Kết luận
Phần mềm custom không phải câu trả lời cho mọi vấn đề, nhưng đôi khi là câu trả lời đúng duy nhất. Framework đơn giản: nếu quy trình của bạn là competitive advantage cộng SaaS cost vượt custom cost trong 2 năm cộng team có khả năng maintain, build. Còn lại, SaaS trước, custom sau khi đã biết rõ mình cần gì.
Anh logistics ở Bình Dương sau khi deploy phần mềm custom đã gọi lại: "Lần đầu tiên mình biết trong kho còn bao nhiêu hàng mà không cần gọi điện hỏi.". Đó là giá trị thật.
→ Quay về cluster: Phần Mềm Custom Cho Doanh Nghiệp Việt — Toàn Bộ Guide
→ Đọc tiếp trong cluster: - Chi Phí Phát Triển Phần Mềm Custom — Bảng Giá Thực Tế 2026 - Cách Chọn Công Ty Phát Triển Phần Mềm — 8 Tiêu Chí - Phần Mềm ERP Cho SME — Odoo vs Custom vs SaaS
→ Áp dụng thực tế: Mình đã tích hợp ZaloCRM vào phần mềm custom cho khách hàng logistics. Xem case study đầy đủ về API integration và workflow automation.
Tác giả: Loc Nguyen Data Team. Tư vấn chuyển đổi số và phát triển phần mềm cho SME Việt. 20+ dự án custom software (2020-2026). Số liệu cost dựa trên thực tế thị trường VN Q1/2026.
Cập nhật lần cuối: 30/04/2026, re-check semi-annually.