Capstone: Sales Management

The challenge

Build Sales Management, a business application for products, customers, and orders. The goal is not to reproduce one prescribed screen. It is to demonstrate that you can turn requirements into a cohesive, secure, operable solution.

Continue from the foundation created throughout the modules. Commit in small increments and keep the application runnable at each milestone.

Functional scope

Identity and users

• Email sign-in and one social provider in the lab environment.
• Sign-out and safe session restoration.
• admin, supervisor, and seller profiles.
• Routes and actions also protected by backend rules.

Dashboard

• Total revenue, order count, active customers, and product count.
• Loading, empty, data, and failure states.
• Phone, tablet, and desktop/web layouts.

Products and customers

• List, search, create, edit, and validate.
• Product image upload with progress and failure recovery.
• Paging or incremental loading.
• Updated timestamps for synchronization.

Orders

• Customer and product selection.
• Quantity, unit price, and domain-calculated total.
• Protection against empty orders and invalid quantity.
• Order status and consistent stock updates.

Continuity and notifications

• Local cache for important reads.
• Clear stale-data and pending-operation feedback.
• A documented conflict and reconnection policy.
• Business-event notifications without sensitive payloads.

Expected architecture

lib/
  core/
    environment/
    error/
    network/
    observability/
  features/
    auth/
    dashboard/
    products/
    customers/
    orders/
  main.dart

Each feature should separate domain, data, and presentation when its complexity justifies those boundaries. Do not create empty layers merely to satisfy a diagram; document decisions and exceptions in the README.

Required quality

• dart format and flutter analyze succeed.
• Unit tests cover order and authorization rules.
• Widget tests cover login, product, and failure states.
• At least one integrated journey runs automatically.
• No secret or token appears in code, logs, or source control.
• Firebase rules are tested when Firebase is used.
• CI runs the quality gate and produces an artifact.

Deliverables

1. A repository with understandable commit history.
2. A README covering requirements, setup, environments, and decisions.
3. A small dependency diagram.
4. A runnable application with demonstration data.
5. Test results and known limitations.
6. A short video or image sequence showing the critical journey.

Assessment

Completion path

1. Define the minimum scope and use cases.
2. Build a vertical slice: sign-in, product, order.
3. Add persistence and integrations behind contracts.
4. Cover critical rules with tests.
5. Validate different widths and failure modes.
6. Automate the quality gate.
7. Review security, documentation, and demonstration.

Final reflection

Record three decisions that improved the system and one you would change. Mature engineering is not pretending the first solution was perfect; it is explaining the context, the tradeoff, and the next step.

When the application is runnable, tested, and documented, complete this step. You now have a project that connects Flutter fundamentals to a real software delivery process.

Technical defense

In addition to the demonstration, prepare a 15-minute discussion that answers:

1. Which business rule is protected in the domain, and by which test?
2. Which boundary allows API, persistence, or Firebase to be replaced?
3. How does the interface represent loading, absence, failure, and offline operation?
4. Which sensitive data was deliberately excluded from logs and storage?
5. Which failure can the pipeline stop before delivery?
6. Which decision would you revisit if the product grew tenfold?

Run the gate from a clean checkout and record versions and artifacts:

flutter --version
flutter pub get
dart format --output=none --set-exit-if-changed .
flutter analyze
flutter test --coverage
flutter build <target> --release

Don’t present only “all commands were green.” Explain the evidence produced by each stage and which risk remains outside it. Use the command and concept reference to review the toolchain before the defense.