Làm website bán hàng thường được khách mở bằng câu: “Anh cần trang trưng sản phẩm, có giỏ hàng là đủ.” Nghe khá gọn. Ngày 23/8/2026, gói VPS KVM 1 của Hostinger niêm yết 167.900 VND mỗi tháng khi trả trước 24 tháng, gồm 1 vCPU, 4 GB RAM và 50 GB NVMe. Riêng một khoản vận hành đã có kỳ hạn, cấu hình và giá gia hạn cần nói rõ.
Phạm vi đã đổi. Sau buổi họp đầu, giỏ hàng thường kéo theo tồn kho, thanh toán, vận chuyển, mã giảm giá và người trực khi đơn lỗi. Chúng tôi từng làm backend C# nên nhìn đề bài này như một hệ thống giao dịch nhỏ, chứ không coi đó là vài màn hình đẹp ghép lại.
Một yêu cầu web shop thường lớn dần sau buổi họp đầu
Trang sản phẩm tĩnh chỉ hiển thị nội dung, còn web shop phải nhớ món nào còn hàng, ai vừa thanh toán và đơn đang nằm ở đâu. Làm website bán hàng đã thành phần việc khác. Nếu chưa tách luồng, dev dễ báo giá cho giao diện rồi làm miễn phí phần vận hành.
Từ trang sản phẩm phát sinh tồn kho, thanh toán, vận chuyển và khuyến mãi
Hãy lấy cửa hàng ốp lưng làm ví dụ. Một mẫu dành cho 4 đời iPhone và có 6 màu tạo ra 24 biến thể. WooCommerce gọi cấu trúc này là Variable Product. Mỗi biến thể có SKU, giá, ảnh và số tồn riêng; SKU là mã kho giúp nhân viên nhận đúng món.
Khi ốp xanh cho iPhone 15 hết hàng, hệ thống phải khóa đúng biến thể đó, còn 23 lựa chọn khác vẫn bán và không bị trừ nhầm kho, vì một cột Quantity chung sẽ làm hỏng đơn. Khách muốn hình dung dự án rộng hơn. Họ có thể xem thêm, rồi đối chiếu từng hạng mục với yêu cầu của mình.
Thanh toán có hai đường phản hồi. VNPAY dùng Return URL đưa khách về trang kết quả, còn IPN URL báo trạng thái cho máy chủ, vì vậy mạng của khách đứt sau lúc ngân hàng trừ tiền thì IPN vẫn cập nhật đơn. Chữ ký dùng HMACSHA512. Số tiền phải nhân với 100, còn mức giao dịch tối thiểu là 5.000 VND.
API tạo đơn của GHN nhận cân nặng, địa chỉ và số điện thoại; header bắt buộc có Token cùng ShopId, nghĩa là backend phải gửi đúng dữ liệu sang hãng vận chuyển và nhận callback khi trạng thái đổi. Thiếu bước này. Nhân viên nhập lại bằng tay.
Những đầu việc ngoài code như nội dung, vận hành và hỗ trợ người dùng
Một cửa hàng có 600 mã hàng cần ảnh, mô tả, giá, SKU và số tồn trước khi nhập. Dev viết chức năng import CSV, còn chủ shop làm sạch dữ liệu nguồn. Hai việc thường bị gom thành câu “đăng sản phẩm giúp anh”. Tách ngay.
- Nội dung: ai viết mô tả và xác nhận giá.
- Vận hành: ai duyệt đơn, sửa tồn và đóng mã giảm giá.
- Hỗ trợ: kênh nào nhận lỗi thanh toán, trực giờ nào.
- Đối soát: người nào so tiền với đơn.
- Gia hạn: tên miền, máy chủ và email đứng tên ai.
Chúng tôi yêu cầu chạy thử 10 đơn. Gồm 3 đơn COD, 3 đơn trực tuyến, 2 đơn dùng mã giảm và 2 đơn hủy. Con số nhỏ, song đủ lộ nhiều lỗi vận hành. Dev cần trả lại danh sách người chịu trách nhiệm khi khách nói “bên em cứ làm luôn”.
Làm website bán hàng cần khoanh phạm vi kỹ thuật
Khi làm website bán hàng, phạm vi kỹ thuật biến cuộc nói chuyện thành thứ kiểm được. Người mới đọc cũng hiểu trang nào xuất hiện, dữ liệu đi đâu và thế nào mới hoàn thành. Ghi thành điều khoản.
Viết rõ chức năng, tích hợp, dữ liệu bàn giao và tiêu chí nghiệm thu
Bản phạm vi tốt đi theo luồng người dùng. Khách chọn biến thể, hệ thống giữ giá, tạo mã đơn, chuyển sang VNPAY rồi nhận IPN để đổi trạng thái. Mỗi động từ tương ứng một phần code. Bạn có thể dùng checklist tạo website bán hàng để rà ban đầu, sau đó bổ sung tiêu chí riêng.
Tiêu chí nghiệm thu cần đo được. Chẳng hạn, mã giảm 10% chỉ áp cho nhóm SKU đã chọn; lần dùng thứ hai phải bị từ chối rõ. Đơn VNPAY chỉ chuyển sang “đã thanh toán” sau IPN hợp lệ, không dựa vào trang cảm ơn.
Bộ Core Web Vitals hiện dùng ba ngưỡng tốt tại phân vị 75: LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1. LCP đo lúc nội dung lớn hiện ra, INP đo độ trễ sau thao tác, còn CLS phản ánh mức giao diện bị nhảy. Khi gắn chatbot, dev phải đo lại; một tình huống web chậm sau tích hợp AI được phân tích để tham khảo tại đây.
Tách phần có thể dùng dịch vụ sẵn khỏi phần thật sự cần code riêng
WooCommerce đã quản lý tồn theo biến thể; GHN có API tạo và theo dõi đơn; VNPAY lo bước xác thực ngân hàng. Dev vẫn viết lớp kết nối, log lỗi và cơ chế thử lại. Ba phần ấy thuộc dự án. Dịch vụ sẵn chỉ giảm phần phải tự bảo trì.
Code riêng hợp lý khi quy tắc giá kết hợp đời máy, hạng thành viên và số lượng mua. Plugin giảm giá chung thường không hiểu đủ ba điều kiện. Chúng tôi viết test cho từng nhánh trước khi sửa giao diện quản trị.
Với dự án ASP.NET Core mới trong tháng 8/2026, .NET 10 là bản LTS được Microsoft hỗ trợ đến tháng 11/2028. .NET 8 kết thúc hỗ trợ ngày 10/11/2026. Mốc này ảnh hưởng lịch nâng cấp. Hợp đồng bảo trì cần ghi phiên bản đích.
ASP.NET Core có middleware Rate Limiting với bốn kiểu: Fixed Window, Sliding Window, Token Bucket và Concurrency. Chúng giới hạn yêu cầu theo thời gian hoặc số tác vụ chạy cùng lúc. Hãy áp dụng cho endpoint mã giảm giá, đăng nhập và tải thử trước ngày mở bán.
Lúc nào freelance nên kéo thêm đội chuyên môn?
Freelance làm website bán hàng xử lý được danh mục gọn, một cổng thanh toán và quy trình giao hàng rõ. Rủi ro tăng mạnh khi đơn đi qua nhiều hệ thống hoặc cửa hàng đòi hỗ trợ liên tục. Lúc ấy, gọi thêm người. Quyết định này bảo vệ cả khách lẫn người nhận dự án.
Dự án có nhiều hệ thống liên thông hoặc yêu cầu vận hành liên tục
Giả sử shop ốp lưng bán tại quầy, trên web và qua sàn. Cùng một SKU có ba nơi trừ tồn. POS cập nhật chậm 5 phút thì website vẫn nhận đơn cho món vừa bán hết. Bài toán đã thành đồng bộ dữ liệu, hàng đợi và xử lý xung đột.
Hãy gọi thêm backend khi có từ 3 hệ thống cùng sửa một loại dữ liệu, như POS, website và hãng vận chuyển cùng tác động lên trạng thái đơn. DevOps cần vào khi khách yêu cầu trực 24/7, cảnh báo và khôi phục sau sự cố. Một người vừa code vừa giữ điện thoại cả đêm sẽ bỏ sót.
Khách đôi khi muốn một đầu mối nhận giao diện, backend, hạ tầng và bảo trì. Khi đó, bạn hãy so phạm vi của MONA Media thiết kế web với dự toán freelance. Đặt hai danh sách chức năng cạnh nhau. Khách sẽ thấy khoản nào là code ban đầu, khoản nào là vận hành dài hạn.
Phân vai rõ giữa người giới thiệu, người phát triển và đơn vị chịu SLA
Người giới thiệu xác nhận bối cảnh. Dev chịu code, test, tài liệu và lỗi trong phạm vi. Đơn vị chịu SLA phải có ca trực, cảnh báo cùng quyền máy chủ. SLA là cam kết thời gian phản hồi, không phải lời hứa “có lỗi gọi em”.
Một mức mẫu cho sự cố P1 là phản hồi trong 30 phút và có phương án tạm trong 4 giờ, chẳng hạn khi toàn bộ checkout ngừng hoạt động hoặc dữ liệu đơn bị ghi sai. Hai bên thương lượng con số này. Không có chuẩn chung cho mọi shop.
GitHub Environments hỗ trợ required reviewers, giới hạn nhánh triển khai và giữ environment secrets đến khi bước phê duyệt hoàn tất, nhờ vậy giảm chuyện một người tự đẩy code lên production. Người chịu SLA vẫn cần quyền xem log. Họ phải quay lại được bản cũ.
Nhận đúng dự án giúp giữ uy tín nghề
Uy tín của freelance làm website bán hàng thường hỏng ở dự án nhận quá rộng. Chúng tôi chấm dự án qua ba trục: rủi ro giao dịch, thời gian trực và năng lực đang có. Chấm trước khi báo giá. Cảm giác tự tin không lấp được khoảng trống về bảo mật hoặc vận hành.
Dùng ma trận rủi ro, thời gian và năng lực để quyết định nhận hay chuyển
Ma trận buộc dev viết lý do nhận, ghép đội hoặc chuyển dự án, để quyết định không bị kéo theo giá trị hợp đồng. Dùng bốn tình huống sau.
| Tình trạng dự án | Quyết định nghề |
|---|---|
| Dưới 100 SKU, một kho, giá đơn giản | Nhận trọn gói nếu đã có mẫu checkout và bài test. |
| Hai cổng thanh toán, đồng bộ POS và sàn | Ghép thêm backend; dành riêng thời gian đối soát. |
| Trực 24/7, đơn ảnh hưởng nhiều chi nhánh | Chuyển cho đội có giám sát hạ tầng và ca trực thật. |
| Chưa có SKU, ảnh hoặc chính sách đổi trả | Chỉ nhận giai đoạn phân tích; chưa chốt ngày mở bán. |
Gói KVM 1 nêu ở đầu bài có giá gia hạn 279.900 VND mỗi tháng sau kỳ ưu đãi 24 tháng, theo bảng giá kiểm ngày 23/8/2026. Khoản này lặp hàng tháng và phải có người thanh toán. Hãy đưa nó vào ma trận.
Chúng tôi giữ một nguyên tắc: dev chưa từng xử lý webhook thanh toán thì đừng lấy cửa hàng đang chạy doanh thu làm nơi học lần đầu, hãy làm sandbox, viết log và diễn tập callback trùng trước. Nhận đúng phần. Cách ấy giữ quan hệ lâu hơn một báo giá gom hết.
Bàn giao minh bạch để khách không phụ thuộc vào một cá nhân
Bàn giao phải dùng được. Khách cần tài khoản tổ chức của repository, quyền tên miền, máy chủ, bản sao dữ liệu và lịch gia hạn. Dev giữ vai trò cộng tác viên sau khi chuyển quyền. Người kế tiếp sẽ vào việc mà không phải xin từng mật khẩu.
Một buổi bàn giao kéo dài khoảng 60 đến 90 phút, trong đó chúng tôi chạy năm thao tác: triển khai bản mới, quay lại bản cũ, phục hồi dữ liệu thử, đổi khóa API sandbox và xem log. Đội tiếp quản phải lặp lại được. Nếu chưa, tài liệu vẫn thiếu.
Đừng gửi secrets trong repository. GitHub Environments tách bí mật theo môi trường; file mẫu chỉ giữ tên biến như ConnectionStrings__ShopDb hoặc Vnpay__HashSecret. Hai bên đổi khóa thật trong 24 giờ. Chủ shop cũng dùng cách kiểm tra chứng chỉ SSL để biết tên miền đang được bảo vệ và ngày hết hạn nằm ở đâu.
Website còn sống sau ngày nghiệm thu. Nền tảng, nội dung và cách bán đều đổi, còn bài về cách phát triển website sau bàn giao giúp chủ shop tách nâng cấp khỏi sửa lỗi bảo hành. Tách riêng hai ngân sách. Ghi từ hợp đồng đầu.
Freelance không cần nhận hết mới chứng minh được năng lực. Hãy nhận phần đo được, gọi thêm người ở chỗ có SLA hoặc nhiều hệ thống liên thông, rồi bàn giao để khách sở hữu tài sản số. Cách làm website bán hàng này giữ lợi ích của khách và tên nghề của bạn.
Nếu dự toán chưa ghi người xử lý IPN, dữ liệu bàn giao và chi phí sau 24 tháng, hãy dừng báo giá để bổ sung ba dòng đó. Một buổi rà kỹ hôm nay rẻ hơn nhiều đêm sửa đơn sai sau khi mở bán.
