| Đồ Án Flutter: 10 Đề Tài Mẫu + Lộ Trình Làm 4 Tuần & Tiêu Chí Chấm Điểm (2026)

Đồ án Flutter thường không khó vì code. Nó khó vì chọn sai đề tài và không biết tuần nào phải xong việc gì. Rất nhiều nhóm dành ba tuần đầu để dựng giao diện đẹp, rồi tuần cuối mới phát hiện chưa có dữ liệu thật, chưa đăng nhập được, chưa build ra file APK để demo — và phải chạy đua với thời gian trong khi hội đồng thì không chờ ai.

Bài này giải quyết đúng ba việc đó: chọn đề tài, lộ trình bốn tuần, và những gì hội đồng thật sự chấm. Cuối bài có 10 đề tài mẫu đã lọc theo tiêu chí “làm được trong một học kỳ”, bộ câu hỏi bảo vệ hay gặp, và phần trả lời cho các câu hỏi thường gặp.

Đồ án Flutter là gì và khác gì bài tập trên lớp?

Đồ án Flutter là một sản phẩm ứng dụng di động hoàn chỉnh mà bạn tự làm từ đầu tới cuối: tự chia giao diện, tự thiết kế dữ liệu, tự nối với nơi lưu trữ, tự đóng gói và tự trình bày trước hội đồng. Khác biệt cốt lõi so với bài tập là đồ án không có đáp án đúng sẵn.

Bài tập trên lớp có đề bài đóng: “viết màn hình đăng nhập dùng Form và TextFormField”. Cách chấm rõ ràng, và bạn biết mình xong khi nào: khi setState chạy đúng.

Đồ án thì mở. Không ai nói trước app của bạn cần bao nhiêu màn hình, dữ liệu lưu ở đâu, có cần đăng nhập không. Chính phần tự quyết định đó là thứ hội đồng chấm — và cũng là thứ người mới hay làm sai nhất, vì các bạn thường chọn đề tài nghe oai nhưng không ước lượng được khối lượng.

Có một cách nghĩ rất thực dụng: đồ án là lần đầu bạn đóng vai người làm sản phẩm, chứ không phải người làm bài tập. Sản phẩm thì có người dùng, có dữ liệu sai, có lúc mất mạng, có lúc người dùng bấm nút hai lần liên tiếp. Bài tập thì không ai bấm nút hai lần.

Vì sao nên chọn Flutter cho đồ án

Flutter hợp với đồ án ở ba điểm rất cụ thể:

• Một mã nguồn cho nhiều nền tảng. Bạn demo trên điện thoại Android, nhưng vẫn có thể trình bày là chạy được cả iOS và web — điều này ghi điểm trong phần thuyết trình mà không tốn thêm công viết lại.
• Có sẵn hệ sinh thái giao diện. Bạn không phải tự vẽ từng nút; widget có sẵn giúp bạn dồn thời gian cho phần nghiệp vụ, đúng phần hội đồng quan tâm.
• Ra file cài được thật. Flutter build ra APK và cài thẳng lên máy, nên phần demo không phụ thuộc vào mạng hay máy tính của giảng viên.

Nếu bạn còn đang cân nhắc giữa các lựa chọn framework, phần so sánh Flutter và React Native cho người mới sẽ giúp bạn thấy khác biệt về khối lượng công việc trong một học kỳ.

Chọn đề tài đồ án Flutter: 5 tiêu chí lọc

Trước khi nghĩ tới ý tưởng, hãy đặt ra bộ tiêu chí để tự loại. Một đề tài chỉ nên được nhận nếu vượt qua cả năm tiêu chí sau.

1. Ước lượng được trong 4 tuần

Đây là tiêu chí giết nhiều đề tài nhất. “App đặt xe như Grab” nghe hay, nhưng người mới mất ba tuần chỉ để làm bản đồ và định vị thời gian thực. Cách kiểm tra nhanh: bạn có thể mô tả đường đi của dữ liệu trong một câu không? Nếu không mô tả được, đề tài quá lớn.

Quy tắc an toàn cho một học kỳ: đếm số màn hình cần làm. Từ 5 đến 7 màn hình là vừa sức. Trên 10 màn hình gần như chắc chắn không xong, trừ khi bạn đã từng làm app tương tự.

2. Có dữ liệu thật để nói về

Đồ án dùng dữ liệu giả tự bịa trong lúc bảo vệ rất dễ bị hỏi xoáy: “sao chỉ có 3 sản phẩm?”, “nếu có 10.000 sản phẩm thì sao?”. Hãy chọn đề tài mà bạn có thể lấy dữ liệu thật, dù nhỏ — danh sách quán cafe quanh trường, danh mục giày của một shop, danh sách lớp học của khoa.

3. Demo được trong 60 giây

Hội đồng thường cho bạn vài phút. Nếu app cần mạng ổn định, cần máy chủ riêng, cần đăng nhập hai lớp mới vào được màn hình chính — bạn sẽ mất hết thời gian để chữa cháy. Một đề tài tốt cho phép bạn mở app, bấm ba lần, và đã thấy được giá trị.

4. Có phần “nghiệp vụ” để giải thích

Màn hình đăng nhập và danh sách thì ai cũng có. Điểm khác biệt nằm ở chỗ quy tắc nghiệp vụ: khi huỷ đơn hàng thì tính tiền thế nào, khi hai người cùng đặt một chỗ thì xử lý ra sao, khi hàng hết thì ẩn hay hiện. Đây là chỗ bạn thể hiện mình hiểu bài toán, không chỉ biết code.

5. Không phụ thuộc dịch vụ trả phí hoặc không ổn định

Tránh đề tài bắt buộc dùng API trả tiền, dịch vụ dễ bị khoá, hoặc thứ bạn không kiểm soát được. Nếu cần bản đồ hay thanh toán, hãy thiết kế để có phương án dự phòng — hoặc đơn giản là bỏ tính năng đó ra khỏi phạm vi và nói rõ trong báo cáo.

10 đề tài đồ án Flutter kèm mức độ khó

Danh sách dưới đây đã lọc theo năm tiêu chí trên. Mỗi đề tài ghi rõ cần làm gì, dùng công nghệ nào, chỗ hội đồng hay hỏi, và mức độ khó để bạn tự cân.

1. App quản lý quán cafe

Menu, đặt món, giỏ hàng, quản lý đơn hàng, và trang quản trị để thêm/sửa/xoá sản phẩm. Đây là dạng đề tài được chọn nhiều nhất trong các lớp Flutter ở TPHCM.

Vì sao đáng làm: phần lớn sinh viên chỉ làm giao diện cho khách. Trang quản trị — CRUD sản phẩm, xem danh sách đơn — là phần ít bạn làm nhưng lại đúng vai trò của một sản phẩm thật.

Công nghệ: Flutter, lưu trữ cục bộ hoặc Firebase, quản lý trạng thái cho giỏ hàng.
Hội đồng hay hỏi: giỏ hàng giữ ở đâu khi tắt app? Xoá món khỏi menu thì các đơn cũ bị gì?
Mức độ: thấp — vừa.

2. App bán giày hoặc thời trang

Lọc theo thương hiệu, xem chi tiết, chọn size, thêm vào giỏ, đặt hàng. Điểm khác biệt so với đề tài 1 là bài toán lọc và tìm kiếm trên danh mục lớn.

Hội đồng hay hỏi: lọc nhiều điều kiện cùng lúc thì xử lý ở app hay ở server?
Mức độ: thấp.

3. App điểm danh sinh viên bằng QR

Giảng viên mở một phiên điểm danh, sinh viên quét mã để điểm danh. Đề tài này có phần nghiệp vụ rõ ràng và dễ gây ấn tượng.

Hội đồng hay hỏi: làm sao chống việc sinh viên chụp mã gửi cho bạn khác? Thời gian hiệu lực của phiên là bao lâu?
Mức độ: trung bình. Phần khó là thiết kế phiên điểm danh và chống gian lận.

4. App đọc đơn hàng bằng giọng nói cho tài xế

Danh sách đơn hàng tự đọc lên bằng giọng nói để tài xế không phải nhìn màn hình khi đang lái. Đề tài này lấy trực tiếp từ một bài toán người thật, nên phần thuyết trình rất mạnh.

Công nghệ: Flutter, tổng hợp giọng nói tiếng Việt, có thể kèm phần nhận dạng giọng nói ở bước sau.
Hội đồng hay hỏi: khi app đọc mà tài xế bấm tắt thì xử lý thế nào? Tiếng Việt có dấu đọc đúng không?
Mức độ: trung bình — khó.

5. To-do list điều khiển bằng giọng nói tiếng Việt

Thêm việc bằng cách nói thay vì gõ. Đề tài nhỏ nhưng chạm đúng một vấn đề hẹp và giải quyết bằng công nghệ thật.

Hội đồng hay hỏi: nhận dạng sai thì người dùng sửa thế nào? Có xử lý được giọng vùng miền không?
Mức độ: trung bình.

6. App học từ vựng có nhắc lại theo khoảng thời gian

Một đề tài mà phần nghiệp vụ khó hơn phần giao diện, rất tốt để lấy điểm. Bạn cần cài đặt thuật toán nhắc lại cách quãng, và thống kê tiến độ học.

Hội đồng hay hỏi: dữ liệu học của một người có lớn không? Nếu người dùng đổi giờ hệ thống thì sao?
Mức độ: trung bình.

7. App quản lý chi tiêu cá nhân

Nhập khoản chi, phân loại, xem biểu đồ theo tháng. Đề tài quen thuộc nhưng vẫn cho điểm nếu bạn làm tốt phần thống kê và biểu diễn dữ liệu.

Hội đồng hay hỏi: biểu đồ tính lại mỗi lần mở app hay tính dần rồi lưu? Dữ liệu nhiều năm thì sao?
Mức độ: thấp.

8. App đặt sân thể thao theo khung giờ

Đây là bài toán chống trùng lịch — cùng một sân, hai người không được đặt cùng khung giờ. Phần này rất đáng làm vì nó buộc bạn phải suy nghĩ về tính đúng đắn của dữ liệu.

Hội đồng hay hỏi: nếu hai người đặt cùng lúc thì ai thắng? Bạn chặn ở app hay ở server?
Mức độ: trung bình.

9. App tin tức hoặc tổng hợp nội dung theo chủ đề

Lấy dữ liệu từ một nguồn bên ngoài, phân loại theo chủ đề, lưu lại bài đã đọc. Đề tài này dạy bạn đúng kỹ năng mà đồ án nào cũng cần: gọi API và xử lý dữ liệu trả về.

Hội đồng hay hỏi: mất mạng thì app hiển thị gì? Dữ liệu cũ được lưu lại bao lâu?
Mức độ: thấp — trung bình.

10. App quản lý lớp học cho giảng viên

Quản lý danh sách sinh viên, bài tập, điểm số; sinh viên xem điểm và nộp bài. Quy mô lớn hơn các đề tài trên, nên chỉ chọn nếu nhóm bạn có 4 người và đã quen Flutter.

Hội đồng hay hỏi: phân quyền giảng viên và sinh viên nằm ở đâu? Sinh viên có sửa được điểm của mình không?
Mức độ: khó.

Cách chọn đề tài không bị trùng với nhóm khác

Trùng đề tài là chuyện rất hay gặp, và cách xử lý không phải là đổi ý tưởng hoàn toàn — vì như vậy bạn sẽ mất thời gian quý ở giai đoạn đầu.

Thay vào đó, hãy đổi phạm vi và đối tượng. Bốn cách cụ thể:

• Đổi đối tượng dùng. Cùng là app quản lý quán cafe, nhóm bạn làm cho quán take-away (không có chỗ ngồi, cần in phiếu nhanh) sẽ khác hẳn quán có phục vụ tại bàn.
• Đổi ràng buộc kỹ thuật. Nhóm khác làm phiên bản cần mạng; bạn làm phiên bản chạy được khi mất mạng, đồng bộ lại khi có mạng. Đây là điểm khác biệt lớn về kỹ thuật, không phải chỉ đổi tên.
• Đổi phần khó. Nếu nhóm khác tập trung vào giao diện đẹp, bạn tập trung vào bảng thống kê hoặc phân quyền.
• Đổi nền tảng demo. Cùng chung mã nguồn nhưng bạn nhấn mạnh phần chạy trên nhiều nền tảng và có phần cấu hình riêng cho từng nền tảng.

Một mẹo nhỏ nhưng hiệu quả: ghi rõ phạm vi không làm trong báo cáo. Nếu bạn ghi “phiên bản này không xử lý thanh toán trực tuyến, chúng tôi thiết kế để bổ sung sau”, hội đồng thấy bạn biết giới hạn của mình — đó là điểm cộng, không phải điểm trừ.

Lộ trình làm đồ án Flutter trong 4 tuần

Lộ trình dưới đây giả định nhóm 3–4 người, mỗi người dành khoảng 15 giờ mỗi tuần. Nếu bạn làm một mình, hãy chọn đề tài mức độ thấp hoặc thấp — vừa và giữ nguyên mốc thời gian.

Tuần 1 — Chốt phạm vi và dựng khung chạy được

Mục tiêu cuối tuần 1 không phải là giao diện đẹp. Mục tiêu là: app chạy trên máy thật, có điều hướng giữa các màn hình, và màn hình đầu tiên hiển thị dữ liệu mẫu.

Việc cần xong:

• Chốt đề tài, viết ra danh sách màn hình và danh sách dữ liệu cần có.
• Dựng cấu trúc thư mục cho gọn ngay từ đầu — xem cấu trúc thư mục một dự án Flutter để không phải sửa lại ở tuần 3.
• Tạo repository dùng chung, mời cả nhóm, và bắt buộc mọi người chạy được project trên máy mình trước khi viết dòng code nào.
• Dựng điều hướng và một màn hình danh sách hard-code dữ liệu.

Nếu hết tuần 1 mà chưa ai ngoài bạn chạy được project, hãy dừng lại và sửa việc đó ngay. Đây là khoản nợ lớn nhất trong các đồ án nhóm.

Tuần 2 — Dữ liệu thật và trạng thái

Tuần này là tuần quyết định. Bạn nối app với nguồn dữ liệu thật và bắt đầu quản lý trạng thái tử tế.

• Thiết kế dữ liệu: có những bảng/collection nào, quan hệ ra sao.
• Nối dữ liệu: dùng API có sẵn hoặc dựng nhanh một backend. Nếu chưa từng gọi API, hãy làm phần kết nối API REST trong Flutter trước, rồi mới áp vào đồ án.
• Xử lý bốn trạng thái cho mọi màn hình có dữ liệu: đang tải, có dữ liệu, rỗng, lỗi. Đây là chi tiết nhỏ mà hội đồng hay hỏi và cũng là chi tiết làm app trông chuyên nghiệp.
• Quản lý trạng thái theo cách quản lý state trong Flutter — chọn một cách và dùng nhất quán, đừng trộn ba cách trong cùng dự án.

Cuối tuần 2, luồng chính của app phải chạy được từ đầu tới cuối bằng dữ liệu thật, dù giao diện còn xấu.

Tuần 3 — Hoàn thiện nghiệp vụ và các trường hợp biên

Đây là tuần bạn lấy điểm khác biệt. Đừng dùng nó để đổi màu nút.

• Cài đặt quy tắc nghiệp vụ đã ghi ở tuần 1: huỷ đơn, chống trùng lịch, phân quyền, tính tổng.
• Xử lý các trường hợp biên: mất mạng giữa lúc gửi, người dùng bấm liên tiếp hai lần, dữ liệu trống, số quá lớn.
• Lưu dữ liệu cục bộ cho những gì cần dùng khi mất mạng — xem lưu dữ liệu local trong Flutter.
• Nếu cần đăng nhập, làm phần xác thực với Firebase hoặc cơ chế xác thực của riêng bạn.
• Build thử APK ngay trong tuần này, đừng để tuần 4. Xem trước hướng dẫn build APK để biết những lỗi thường gặp khi ký và đóng gói.

Cuối tuần 3, app phải cài được lên máy thật và chạy đủ luồng để demo.

Tuần 4 — Báo cáo, demo và tập bảo vệ

Tuần cuối không phải để thêm tính năng. Thêm tính năng ở tuần 4 là cách phổ biến nhất để hỏng cả đồ án.

• Viết báo cáo: bài toán, phạm vi, thiết kế, công nghệ, khó khăn và cách xử lý, hướng phát triển.
• Chuẩn bị kịch bản demo theo đúng 60–90 giây, tập trước ít nhất ba lần trên máy thật.
• Chuẩn bị dữ liệu demo sẵn trong app, đừng nhập lúc đứng trước hội đồng.
• Tập trả lời các câu hỏi trong mục tiếp theo.
• Đóng băng phiên bản: gắn tag final trong Git và không sửa gì thêm sau buổi demo.

Chia việc nhóm và dùng Git cho đồ án

Phần này ít được dạy nhưng gây ra nhiều điểm trừ nhất. Nguyên tắc quan trọng nhất: chia theo chiều dọc, không chia theo chiều ngang.

Chia theo chiều ngang là “bạn A làm giao diện, bạn B làm dữ liệu, bạn C làm báo cáo”. Cách này nghe hợp lý nhưng tạo ra điểm nghẽn: B phải chờ A xong giao diện mới biết cần dữ liệu gì, C không có gì để viết cho tới tuần 4.

Chia theo chiều dọc nghĩa là mỗi người sở hữu trọn một tính năng từ màn hình tới dữ liệu. Ví dụ trong app quản lý quán cafe: một bạn làm trọn luồng “quản lý sản phẩm” (màn hình danh sách, form thêm/sửa, xoá, nối dữ liệu), một bạn làm trọn luồng “đặt món và giỏ hàng”, một bạn làm luồng “xem đơn hàng”. Báo cáo và slide chia đều cho cả nhóm.

Vài quy tắc Git nên áp dụng ngay từ tuần 1:

• Mỗi người có một thiết lập môi trường giống nhau, ghi lại trong README.
• Không ai đẩy thẳng lên nhánh chính. Mỗi tính năng làm trên một nhánh riêng rồi mở pull request.
• Đẩy code lên mỗi ngày, kể cả khi chưa xong. Mất một ngày code của người khác là rủi ro không đáng có.
• Ghi lại file pubspec.yaml và pubspec.lock khi có thay đổi gói. Không đồng bộ phiên bản gói là nguyên nhân số một của lỗi “máy tôi chạy được, máy bạn không”.

Tiêu chí hội đồng chấm điểm

Thang điểm mỗi trường mỗi khác, nhưng trọng số thường giống nhau. Hiểu trọng số giúp bạn phân bổ thời gian đúng chỗ.

Tiêu chí	Thường chiếm	Cách lấy điểm
Đúng yêu cầu và phạm vi hợp lý	20–25%	Phạm vi nhỏ mà xong, hơn phạm vi lớn mà dở
Chất lượng kỹ thuật	25–30%	Cấu trúc rõ, xử lý được lỗi và trạng thái rỗng
Tính đúng đắn của nghiệp vụ	15–20%	Xử lý được các trường hợp biên, quy tắc rõ ràng
Báo cáo và trình bày	15–20%	Báo cáo đọc được, demo mạch lạc, không đọc slide
Tính thực tế và khả năng phát triển	10–15%	Có người dùng mục tiêu rõ, có hướng phát triển cụ thể

Đọc bảng này sẽ thấy một điều: giao diện đẹp không phải tiêu chí đứng đầu. Nhiều nhóm dồn 60% thời gian cho phần ít điểm nhất.

Cũng cần nói trước về điểm “AI làm hộ”. Hội đồng ngày càng quen với việc sinh viên dùng công cụ hỗ trợ. Dùng thì không sai, nhưng bạn phải giải thích được đoạn code của mình — kể cả đoạn bạn nhờ sinh tự động. Nếu không giải thích được, phần kỹ thuật coi như mất. Cách an toàn là chỉ để công cụ viết những đoạn bạn đã hiểu và ghi chú lại lý do chọn cách làm đó.

Bộ câu hỏi hội đồng hay hỏi và cách trả lời

Dưới đây là những câu đã xuất hiện nhiều lần trong các buổi bảo vệ. Chuẩn bị trước một câu trả lời ngắn cho mỗi câu, đừng học thuộc.

“Vì sao chọn Flutter mà không chọn native?”
Trả lời bằng chi phí và phạm vi, không bằng cảm tính: một mã nguồn cho hai nền tảng, thời gian học thấp hơn, và với quy mô của đồ án thì hiệu năng không phải điểm nghẽn.

“Dữ liệu lưu ở đâu? Nếu mất mạng thì sao?”
Đây là câu quan trọng nhất vì nó kiểm tra bạn có thiết kế hay chỉ ghép màn hình. Hãy trả lời rõ: dữ liệu nào lưu cục bộ, dữ liệu nào cần mạng, và app hiển thị gì khi mất mạng.

“Điểm khác biệt của đồ án này với app có sẵn là gì?”
Đừng nói “app em đẹp hơn”. Nói về một quyết định thiết kế cụ thể: đối tượng người dùng hẹp hơn, hoặc xử lý được tình huống mà app hiện có chưa xử lý.

“Nếu có 10.000 bản ghi thì màn hình danh sách của em thế nào?”
Họ đang kiểm tra kiến thức về danh sách lớn. Trả lời bằng cơ chế tải theo trang và chỉ dựng những phần tử đang hiển thị, chứ không tải hết một lần.

“Phần nào em tự làm, phần nào em tham khảo?”
Trả lời thật. Ai cũng dùng tài liệu và công cụ. Điều hội đồng cần biết là bạn hiểu phần của mình.

“Nếu có thêm hai tuần, em làm gì?”
Hãy có câu trả lời sẵn và nó phải cụ thể: một tính năng, một vấn đề kỹ thuật, hoặc một phần kiểm thử — không phải “làm đẹp giao diện”.

Chuẩn bị demo và báo cáo

Ba lỗi demo phổ biến nhất, và cách phòng:

Demo phụ thuộc mạng. Hãy quay một video demo dự phòng trước buổi bảo vệ. Video này cứu bạn khi mạng hỏng, máy hết pin, hoặc app bị treo ngay lúc quan trọng.

Dữ liệu demo trống hoặc lộn xộn. Chuẩn bị sẵn dữ liệu để app trông như đang chạy thật. Một danh sách có ba mục trông như bản thử; một danh sách có mười lăm mục trông như sản phẩm.

Kể lể kỹ thuật thay vì kể câu chuyện người dùng. Hội đồng không cần biết bạn dùng ChangeNotifier hay Stream. Họ cần thấy: người dùng là ai, họ gặp khó khăn gì, app của bạn giải quyết thế nào. Mở đầu bằng câu chuyện, rồi mới nói tới kỹ thuật khi được hỏi.

Về báo cáo, một điều nhỏ nhưng đáng làm: viết báo cáo rải ra trong bốn tuần, không dồn vào tuần cuối. Mỗi tuần ghi lại 10–15 dòng về việc đã làm và vấn đề đã gặp. Đến tuần 4 bạn chỉ cần ghép lại — và phần “khó khăn và cách xử lý”, thứ mà hội đồng đánh giá cao nhất, sẽ có sẵn nội dung thật thay vì vài câu chung chung.

Học Flutter đa nền tảng để tự làm đồ án

Điều đáng nói là phần khó của đồ án hầu như không nằm ở đề tài. Nó nằm ở những kỹ năng nền mà không đề tài nào dạy riêng: chia cấu trúc dự án cho gọn, quản lý trạng thái nhất quán, gọi API và xử lý lỗi, đóng gói ứng dụng để cài lên máy thật, và làm việc nhóm trên cùng một mã nguồn. Những thứ này giống nhau ở mọi đề tài — học một lần là dùng được cho cả đồ án lẫn công việc sau này.

Nếu bạn muốn đi theo một lộ trình có người sửa bài thay vì tự mò, trung tâm Hướng Nghiệp Dữ Liệu có:

• Khóa học lập trình mobile app full stack — lộ trình 3 cấp độ 28 · 28 · 53 buổi, từ Dart và giao diện cho tới back-end, real-time và phát hành ứng dụng.
• Khóa học lập trình Flutter đa nền tảng full stack — đi sâu vào Flutter, đúng phần bạn cần cho đồ án.
• Lộ trình học lập trình mobile từ số 0 — nếu bạn chưa biết bắt đầu từ đâu và muốn xem toàn cảnh trước khi đăng ký.
• Fullstack là gì? — nếu bạn đang cân nhắc làm đồ án theo hướng có cả phần server.

Một gợi ý thực tế: nhiều bạn chọn đồ án xong mới đi học, và thường chọn đề tài quá lớn vì lúc đó chưa biết khối lượng thật của từng phần. Nếu bắt đầu học trước một học kỳ, bạn sẽ chọn đề tài sát sức hơn — và tự làm được phần khó thay vì né nó.

Kết luận

Đồ án Flutter thành công hay không phụ thuộc vào ba quyết định ở tuần đầu tiên, không phải vào việc bạn viết code giỏi tới đâu:

1. Chọn đề tài vừa sức và ước lượng được trong 4 tuần. Thà làm một app 6 màn hình thật hoàn chỉnh hơn một app 15 màn hình dở dang.
2. Đặt mốc thời gian và tôn trọng nó. Cuối tuần 2 phải có dữ liệu thật; cuối tuần 3 phải build được APK; tuần 4 không thêm tính năng.
3. Chia việc theo chiều dọc và dùng Git ngay từ ngày đầu. Đây là phần không tốn nhiều thời gian nhưng quyết định nhóm bạn có cháy hay không.

Và một điều nữa: hội đồng không tìm kiếm sản phẩm hoàn hảo. Họ tìm kiếm một sinh viên hiểu rõ thứ mình làm — biết vì sao chọn cách này, biết giới hạn ở đâu, biết nếu có thêm thời gian thì làm gì tiếp. Đó là thứ bạn chuẩn bị được từ tuần đầu, không phải tuần cuối.

Câu hỏi thường gặp

Đồ án Flutter là gì?

Là một ứng dụng di động hoàn chỉnh do sinh viên tự làm từ đầu tới cuối bằng Flutter: tự chọn đề tài, chia giao diện, thiết kế dữ liệu, nối với nơi lưu trữ, đóng gói thành file cài được, và bảo vệ trước hội đồng. Khác bài tập ở chỗ đề bài mở và không có đáp án sẵn.

Làm đồ án Flutter mất bao lâu?

Với một học kỳ bốn tuần, nhóm 3–4 người mỗi người khoảng 15 giờ mỗi tuần, bạn làm được một app 5–7 màn hình có dữ liệu thật. Làm một mình thì nên chọn đề tài mức độ thấp và giữ phạm vi thật nhỏ.

Đề tài đồ án Flutter nào dễ làm nhất?

Những đề tài có luồng dữ liệu đơn giản và không cần đồng bộ thời gian thực: app quản lý chi tiêu, app bán giày, app quản lý quán cafe. Ngược lại, các đề tài cần bản đồ, định vị thời gian thực hoặc thanh toán thật thường vượt sức trong một học kỳ.

Có cần biết lập trình trước khi làm đồ án Flutter không?

Cần biết những thứ cơ bản: biến, hàm, điều kiện, vòng lặp, và hiểu một chút về lập trình hướng đối tượng. Không cần biết trước Flutter hay Dart — hai thứ đó học được trong lúc làm. Nhưng nếu chưa từng viết dòng code nào, hãy học trước một học kỳ thay vì vừa học vừa làm đồ án.

Đồ án Flutter có dùng được AI hỗ trợ không?

Dùng thì không sai, và hội đồng ngày càng quen với việc này. Điều bắt buộc là bạn phải giải thích được đoạn code của mình, kể cả đoạn nhờ công cụ viết. Cách an toàn là chỉ để công cụ viết những phần bạn đã hiểu và ghi chú lại lý do chọn cách làm đó.

Làm đồ án một mình hay theo nhóm tốt hơn?

Làm một mình dễ kiểm soát chất lượng nhưng dễ hụt tiến độ ở tuần 3. Làm nhóm nhanh hơn nhưng chỉ khi chia việc theo chiều dọc — mỗi người sở hữu trọn một tính năng từ giao diện tới dữ liệu. Chia theo chiều ngang, tức mỗi người một tầng, gần như luôn tạo ra điểm nghẽn.

Hội đồng chấm điểm giao diện đẹp hay tính năng?

Tính năng và tính đúng đắn của nghiệp vụ chiếm trọng số lớn hơn. Tổng các tiêu chí về yêu cầu, kỹ thuật và nghiệp vụ thường chiếm 60–75% điểm, còn phần trình bày và tính thực tế khoảng 25–35%. Giao diện đẹp giúp phần demo dễ hiểu hơn, nhưng không bù được cho nghiệp vụ sai.

Nên chọn đề tài trùng với nhóm khác không?

Không nên trùng hoàn toàn, nhưng cũng đừng đổi ý tưởng chỉ vì trùng chủ đề — bạn sẽ mất thời gian quý ở giai đoạn đầu. Hãy đổi phạm vi: đổi đối tượng người dùng, đổi ràng buộc kỹ thuật (ví dụ phiên bản chạy được khi mất mạng), hoặc đổi phần khó mà bạn tập trung vào.

Sau đồ án nên làm gì tiếp?

Hãy đưa đồ án vào hồ sơ cá nhân và phát hành thử lên Google Play nếu có thể. Một app đã ra ngoài, dù ít người tải, là bằng chứng bạn từng đi hết vòng đời sản phẩm — điều nhà tuyển dụng kiểm tra đầu tiên. Nếu muốn đi xa hơn, xem lộ trình học lập trình mobile để biết phần nào cần học tiếp.