Vibe code một CRM hiện nay có thể bắt đầu rất nhanh. Bạn mô tả dashboard, khách hàng, pipeline, Deal, task hay báo cáo doanh số, sau đó AI có thể tạo ra một giao diện khá hoàn chỉnh chỉ trong thời gian ngắn. Có login, có Kanban kéo thả, có form tạo khách hàng, có biểu đồ, thậm chí có thể sinh luôn API và database để demo luồng sử dụng. Vì mọi thứ xuất hiện rất nhanh nên người mới làm rất dễ có cảm giác rằng CRM gần như đã xong.
Nhưng cần nói rõ ngay từ đầu: bài viết này không phải một tài liệu kiến trúc CRM production đầy đủ. Một hệ thống thực tế có thể còn liên quan tới transaction, concurrency, queue, cache, event processing, CI/CD, observability, secrets management, disaster recovery, kiểm thử bảo mật, tối ưu hiệu năng và nhiều lớp kỹ thuật khác tùy quy mô. Ở đây tôi chủ động lược bỏ phần lớn những chi tiết đó và chỉ đi qua một số lớp cơ bản nhất, để người đang tự vibe code hiểu được khoảng cách giữa một ứng dụng chạy được và một CRM đủ tin cậy để doanh nghiệp đưa dữ liệu thật vào sử dụng.
Nói cách khác, nếu bạn đã vibe được một dashboard đẹp, pipeline kéo thả mượt và các form hoạt động đúng như mong muốn thì đó vẫn là một kết quả tốt. Nhưng những gì nhìn thấy trên màn hình chưa nói được nhiều về chất lượng của hệ thống phía sau.
Frontend là phần dễ nhìn thấy nhất, nhưng không phải toàn bộ CRM
Frontend thường là nơi vibe coding tạo cảm giác tiến triển nhanh nhất. Chỉ cần mô tả một pipeline gồm nhiều stage, Deal hiển thị dạng card, phía trên có KPI, bên cạnh có doanh thu dự kiến, thêm bộ lọc, modal và một vài biểu đồ, AI đã có thể tạo ra thứ nhìn khá giống một CRM thương mại. Nếu mục tiêu là làm prototype, thử bố cục hoặc kiểm tra cách người dùng sẽ thao tác thì đây là một lợi ích rất lớn.
Nhưng frontend chủ yếu trả lời câu hỏi người dùng nhìn thấy gì và tương tác với hệ thống như thế nào. Nó chưa giải quyết đầy đủ chuyện dữ liệu được xử lý ra sao khi người dùng bấm nút, hành động đó có hợp lệ không, người dùng có quyền thực hiện hay không, nhiều thay đổi liên quan có được ghi nhận nhất quán hay không và hệ thống sẽ làm gì nếu một bước trong quá trình bị lỗi.
Ngay cả frontend production cũng không đơn giản chỉ là dựng giao diện. Vẫn còn validation, session state, error handling, performance, caching phía client, accessibility và rất nhiều tình huống xảy ra khi mạng chậm hoặc request thất bại. Nhưng vì những thứ này ít trực quan hơn nên chúng thường bị che khuất bởi cảm giác “app đã chạy rồi”.
Backend CRM không chỉ là vài API CRUD
Một backend demo có thể bắt đầu khá đơn giản với những API như tạo khách hàng, sửa Contact, lấy danh sách Deal, cập nhật Task hoặc chuyển stage. AI hiện nay hoàn toàn có thể tạo những phần này rất nhanh. Vấn đề bắt đầu khi nghiệp vụ thật của doanh nghiệp đi vào hệ thống.
Ví dụ một sales chuyển Deal từ “Đang báo giá” sang “Chờ duyệt”. Backend có thể phải kiểm tra người này có quyền thực hiện hành động đó hay không, báo giá hiện tại đã đủ thông tin chưa, mức chiết khấu có vượt quyền phê duyệt của họ không, task kỹ thuật đã hoàn thành chưa và yêu cầu phê duyệt tiếp theo phải chuyển tới ai. Nếu người duyệt từ chối thì Deal quay lại đâu, task nào cần được mở lại, lý do từ chối được lưu thế nào và nếu người dùng bấm hai lần vì mạng chậm thì hệ thống có tạo hai yêu cầu phê duyệt hay không.
Đến đây câu chuyện không còn là một hàm updateDeal() nữa mà đã trở thành business logic. Nếu một hành động thay đổi nhiều dữ liệu cùng lúc thì còn phải nghĩ tới transaction và tính nhất quán dữ liệu. Nếu nó kích hoạt email, notification hoặc tác vụ xử lý phía sau thì có thể xuất hiện background job hay queue. Nếu nhiều người cùng sửa một record thì bắt đầu có bài toán concurrency.
AI có thể viết code cho tất cả những thứ đó nếu được hướng dẫn đúng. Nhưng AI không tự biết doanh nghiệp của bạn đang vận hành thế nào. Nó không biết ai được duyệt giá, Deal nào bắt buộc qua kỹ thuật, trường hợp nào được phép bỏ qua một stage hay khi thắng Deal thì dữ liệu phải chuyển sang bộ phận nào. Nếu những điều này không được định nghĩa rõ, AI rất dễ tạo ra một logic có vẻ hợp lý nhưng không đúng nghiệp vụ.
Data model mới là nơi CRM bắt đầu trở thành một hệ thống
Một trong những phần quan trọng nhất của CRM lại gần như không xuất hiện trên ảnh chụp màn hình: cách dữ liệu được mô hình hóa. Company, Contact, Deal, Quote, Task, Project, User, Team, File hay Activity không chỉ là một loạt bảng database được tạo ra để đủ màn hình.
Cần xác định quan hệ giữa chúng, vòng đời của từng loại dữ liệu, dữ liệu nào phải giữ lịch sử, dữ liệu nào có thể xóa, dữ liệu nào chỉ nên chuyển trạng thái và chuyện gì xảy ra với các dữ liệu liên quan khi một record thay đổi. Một Contact chẳng hạn có thể đang làm ở công ty A, vài năm sau chuyển sang công ty B nhưng doanh nghiệp vẫn cần giữ lịch sử quan hệ cũ. Contact đó có thể tham gia nhiều Deal ở nhiều thời điểm khác nhau, mỗi Deal có nhiều Quote revision và mỗi Quote lại có các dòng sản phẩm, file và approval riêng.
Nếu data model ban đầu được thiết kế quá đơn giản thì vài tháng đầu CRM vẫn có thể chạy rất đẹp. Vấn đề chỉ xuất hiện khi dữ liệu bắt đầu tích lũy và doanh nghiệp muốn mở rộng hệ thống. Khi đó sửa một button sai thường khá dễ, còn sửa một data model sai sau khi đã chứa dữ liệu production lại là câu chuyện hoàn toàn khác.
Có màn hình login chưa có nghĩa là hệ thống đã bảo mật
Login thường là thứ tạo cảm giác một phần mềm đã khá hoàn chỉnh. Người dùng nhập email và password, hệ thống xác thực thành công rồi mở dashboard. Nhưng authentication mới chỉ trả lời câu hỏi người này là ai. CRM còn phải trả lời câu hỏi khó hơn rất nhiều: người này được phép nhìn và làm những gì?
Một sales có được xem Deal của sales khác không? Trưởng phòng được xem toàn bộ team nhưng có quyền sửa báo giá hay không? Nhân viên kỹ thuật có được nhìn giá bán không? Sales Admin có thể chỉnh dữ liệu nhưng có được cấp quyền cho tài khoản khác không? Nếu nhân viên nghỉ việc thì các session đang tồn tại trên điện thoại và laptop phải được thu hồi thế nào? Một API mà frontend đã ẩn nút đi có thực sự từ chối request nếu người dùng cố gọi trực tiếp hay không?
Phía dưới đó còn là cách hash mật khẩu, quản lý access token và refresh token, secret, rate limiting, file upload, HTTPS, firewall, database access và dependency vulnerabilities. Đây là lý do một CRM được bảo mật tốt và một CRM có lỗ hổng nghiêm trọng hoàn toàn có thể nhìn giống nhau khi chỉ xem giao diện. Security gần như không thể đánh giá bằng việc bấm thử vài màn hình.
Code chạy trên laptop chưa phải một môi trường production
Trong lúc vibe code, ứng dụng thường chạy ở môi trường phát triển. Frontend một port, backend một port, database local hoặc một dịch vụ cloud nào đó, sau đó người dùng mở trình duyệt và thử. Với prototype thì như vậy hoàn toàn bình thường.
Nhưng khi doanh nghiệp sử dụng thật, phần mềm phải sống trong một môi trường khác. Ứng dụng chạy trên VPS, cloud hay server tại công ty? Domain được trỏ thế nào? HTTPS được cấp và gia hạn ra sao? Database có bị expose trực tiếp ra Internet không? File được lưu ở đâu? Log giữ trong bao lâu? Service chết có tự khởi động lại không? Server đầy ổ cứng thì ai biết? Bản cập nhật mới được deploy thế nào để tránh làm gián đoạn hệ thống?
Docker thường xuất hiện ở giai đoạn này vì nó giúp đóng gói môi trường triển khai tương đối nhất quán, nhưng có Dockerfile hoặc docker-compose.yml không đồng nghĩa infrastructure đã được thiết kế đúng. Container vẫn có thể mở sai port, secret vẫn có thể nằm trong source code, volume vẫn có thể cấu hình sai và database vẫn có thể bị public ra ngoài. Ở hệ thống lớn hơn còn có thể xuất hiện load balancing, orchestration, autoscaling, centralized logging hay nhiều lớp khác, nhưng ngay cả ở quy mô SME thì deployment vẫn là một phần engineering riêng chứ không đơn giản là đưa source code lên server.
Backup không phải chỉ là có một file sao lưu
CRM giữ lịch sử khách hàng, Deal, báo giá, công việc và những dữ liệu có thể tích lũy trong nhiều năm. Vì vậy khi bắt đầu đưa dữ liệu thật vào, câu hỏi không nên chỉ là “có backup không?” mà phải là nếu server gặp sự cố hôm nay thì hệ thống phục hồi bằng cách nào.
Backup nằm ở đâu, có nằm chung trên server chính không, bao lâu chạy một lần, giữ lại bao nhiêu phiên bản, file đính kèm có được sao lưu cùng database hay không và bản backup gần nhất đã từng được thử restore chưa đều là những câu hỏi quan trọng. Một hệ thống có thể báo backup thành công mỗi đêm nhưng đến ngày thực sự cần phục hồi mới phát hiện bản sao đó không sử dụng được.
Khi yêu cầu cao hơn còn phải tính tới RPO, RTO, off-site backup và disaster recovery. Những thứ này gần như không tạo ra khác biệt nào trên giao diện CRM, nhưng khi có sự cố chúng quyết định doanh nghiệp chỉ gián đoạn trong một khoảng thời gian ngắn hay mất luôn một phần lịch sử dữ liệu.
Audit, logging và observability không đẹp nhưng rất cần khi có chuyện
Giả sử chiều hôm qua một báo giá là 500 triệu nhưng sáng nay còn 450 triệu. Câu hỏi đầu tiên của quản lý thường không phải giao diện CRM có đẹp không mà là ai đã sửa, sửa lúc nào và trước đó giá trị là bao nhiêu. Đây là một trong những lý do hệ thống doanh nghiệp cần audit log.
Logging lại phục vụ một mục đích khác. Khi API lỗi, background job ngừng chạy hoặc một request mất bất thường nhiều thời gian, đội kỹ thuật cần có đủ thông tin để tìm nguyên nhân. Ở hệ thống phức tạp hơn còn có metrics, tracing, alerting và observability để theo dõi tình trạng tổng thể.
Không phải CRM nào cũng cần cùng một mức độ đầu tư cho những thành phần này, nhưng nguyên tắc giống nhau: khi hệ thống đã trở thành công cụ vận hành, người chịu trách nhiệm kỹ thuật phải có khả năng biết chuyện gì đang xảy ra bên trong nó. Chỉ kiểm tra một vài happy path chạy được là chưa đủ để đánh giá chất lượng production.
CRM còn phải sống được sau phiên bản đầu tiên
Prototype thường được làm để chứng minh một ý tưởng hoặc một flow. Phần mềm doanh nghiệp thì phải sống cùng sự thay đổi của doanh nghiệp. Hôm nay CRM chỉ có Customer và Deal, vài tháng sau cần thêm Team, tiếp theo là nhiều pipeline, Quote, approval, Project hoặc thay đổi một quan hệ dữ liệu đã tồn tại từ trước.
Trong lúc đó database đã có dữ liệu thật. Lúc này không thể sửa schema rồi reset database như lúc thử nghiệm. Cần migration, phải kiểm tra dữ liệu cũ có còn tương thích hay không, cần biết bản deploy mới có thể rollback thế nào và phải tránh trường hợp code mới hoạt động với một database chưa được nâng cấp đúng cách.
Một hệ thống doanh nghiệp gần như chắc chắn sẽ thay đổi, nên kiến trúc tốt không chỉ giải quyết câu hỏi hôm nay có chạy được không, mà còn phải nghĩ tới chuyện ngày mai sửa tiếp có còn kiểm soát được không.
Một người test được không có nghĩa 20 người dùng cũng được
Một prototype thường được chính người tạo ra thử nghiệm. Chỉ có một tài khoản, vài chục record và phần lớn thao tác diễn ra theo đúng thứ tự đã hình dung. Khi đưa 20 hoặc 50 người vào, hàng loạt tình huống khác mới bắt đầu xuất hiện.
Hai người có thể cùng chỉnh một Deal, một người bấm submit hai lần vì mạng chậm, cùng một tài khoản đăng nhập trên nhiều thiết bị, manager cần bulk update hàng trăm record, một user upload file rất lớn hoặc notification phải được gửi đúng người trong đúng thời điểm. Đó là lúc những vấn đề như concurrency, idempotency, locking, connection management và performance bắt đầu có ý nghĩa thực tế.
Không phải CRM nhỏ nào cũng cần một kiến trúc phức tạp. Điều quan trọng là hệ thống phải được thiết kế phù hợp với số lượng người dùng, lượng dữ liệu và cách nó thực sự được vận hành, thay vì chỉ dựa trên việc một người test thấy mọi thứ chạy ổn.
Vậy vibe code CRM tới đâu là hợp lý?
Không nên nói vibe coding chỉ làm được frontend, vì điều đó không chính xác. Một người có nền tảng kỹ thuật tốt hoàn toàn có thể dùng AI để viết backend, dựng database, Docker, test và nhiều phần sâu hơn. Ngược lại, một người không có nền tảng engineering có thể tạo ra rất nhiều code nhưng lại khó đánh giá code đó có đúng hay không.
Vấn đề vì vậy không nằm ở chuyện AI có viết được hay không, mà nằm ở khả năng đánh giá thứ AI đã viết ra. Nếu bạn dùng vibe coding để thử ý tưởng, dựng giao diện, hình dung workflow hay làm prototype thì đây là một ứng dụng rất hợp lý. Bạn có thể thử nhiều phương án với chi phí thấp và mô tả cho đội kỹ thuật chính xác hơn sản phẩm mình muốn xây.
Nhưng từ lúc hệ thống bắt đầu chứa dữ liệu khách hàng thật, có nhiều tài khoản nhân viên, phân quyền theo vai trò, được mở ra Internet, tích hợp với các hệ thống khác và trở thành công cụ doanh nghiệp phụ thuộc vào mỗi ngày thì mức độ trách nhiệm đã hoàn toàn thay đổi. Lúc này câu hỏi quan trọng không còn là “AI có code được phần này không?” mà là “ai có đủ chuyên môn để xác nhận phần này được thiết kế đúng?”
Prototype bạn đã vibe ra vẫn có giá trị
Nếu bạn đã dành thời gian tạo một CRM có giao diện và flow tương đối rõ thì prototype đó không phải thứ vô ích. Ngược lại, nó có thể giúp đội kỹ thuật hiểu sản phẩm nhanh hơn rất nhiều so với việc chỉ mô tả bằng lời. Những màn hình, luồng thao tác và cách bạn hình dung Contact, Deal hay pipeline đều là đầu vào có giá trị.
Phần cần đánh giá tiếp nằm ở những thứ phía dưới: data model có phản ánh đúng nghiệp vụ không, business logic đã đủ rõ chưa, backend đang được tổ chức thế nào, quyền truy cập có thực sự được kiểm tra ở server hay không, authentication có phù hợp production không, dữ liệu và file được backup thế nào, infrastructure nên được tổ chức ra sao và cấu trúc hiện tại có còn phát triển được khi yêu cầu thay đổi.
Có phần code có thể giữ lại, có phần cần refactor và cũng có phần nên viết lại nếu nền tảng ban đầu không phù hợp. Biết phần nào nên giữ, phần nào nên sửa và phần nào không nên tiếp tục sử dụng cũng là một phần của software engineering.
Đây là giai đoạn SYP có thể tiếp quản
SYP không nhìn một prototype vibe-coded rồi chỉ đơn giản làm lại giao diện cho đẹp hơn. Phần quan trọng hơn là đánh giá hệ thống từ phía sau: cấu trúc dữ liệu, business logic, backend, authentication, authorization, security, môi trường triển khai, backup và khả năng mở rộng về sau.
Nếu prototype hiện tại có những phần đủ tốt thì hoàn toàn có thể tiếp tục sử dụng. Nếu một số lớp cần refactor hoặc thiết kế lại trước khi đưa dữ liệu thật vào thì phải xác định rõ ngay từ đầu. Mục tiêu không phải viết lại nhiều code nhất mà là đưa hệ thống về một cấu trúc đủ rõ ràng để tiếp tục phát triển, bảo trì và chịu trách nhiệm khi vận hành thực tế.
Đây chính là khác biệt giữa làm cho một ứng dụng chạy được và xây một hệ thống mà doanh nghiệp có thể phụ thuộc vào.
Vibe coding làm prototype dễ hơn, không làm software engineering biến mất
AI đã rút ngắn rất mạnh khoảng cách từ một ý tưởng tới một sản phẩm có thể tương tác. Một người không chuyên cũng có thể dựng giao diện, thử workflow và kiểm chứng ý tưởng nhanh hơn rất nhiều so với trước đây. Điều đó là một bước tiến tốt vì nó giúp doanh nghiệp làm rõ yêu cầu trước khi đầu tư sâu hơn vào phát triển phần mềm.
Nhưng việc tạo code trở nên dễ hơn không làm các vấn đề nền tảng biến mất. Data model vẫn phải đúng, quyền truy cập vẫn phải được kiểm soát, security vẫn phải được kiểm tra, backup vẫn phải phục hồi được, hạ tầng vẫn phải vận hành ổn định và database vẫn phải nâng cấp được khi hệ thống thay đổi.
Vì vậy nếu bạn đang vibe code một CRM, cứ tiếp tục dùng nó để dựng prototype, thử flow và làm rõ ý tưởng của mình. Chỉ cần phân biệt rõ hai cột mốc: “ứng dụng đã chạy được” và “hệ thống đã sẵn sàng để doanh nghiệp sử dụng thật”.
Khoảng cách giữa hai cột mốc đó chính là phần việc của software engineering.