DA10: Capstone: three automations for Sharma Textiles
Demo, self-review and case study
🎯You'll be able to
Demonstrate the three automations, including a failure and recovery, self-assess against the marking guides and write an honest case study.
🏠The everyday picture
After building a house, the builder walks the owners round: this switch is the geyser, this valve stops the water, here are the warranties. The walkthrough is part of the job, not an extra.
📘What it really is
- Demo (a recorded video of 10 to 15 minutes is enough):
- the business problem each project solves, in one sentence;
- a live run of each project, including one failure and how it's handled;
- where the alerts go and what the runbook says;
-
the results in numbers.
-
Self-review against the rubric: for each area, write "met", "partly" or "not yet", with evidence (a test result, a screenshot, a link). Be honest; a clear "not yet" with a plan is more useful than a vague "met".
-
Handover pack: scopes, mapping tables, API cards, credentials list (names only, never the secrets), runbook, data map and catalogue entries.
-
Case studies: one per project, with problem, design, result in numbers and what you'd change (DA9). Remove personal data.
- Next steps: list what you'd build next, such as refunds or AI-assisted routing, so the client sees the road ahead.
📝A worked example
A learner's self-review, in part:
| Area | Rating | Evidence |
|---|---|---|
| Works | Met | 10/10 payment tests, 28/30 emails routed correctly, tidy-up matched manual check |
| Reliable | Met | Error workflow alert with owner; health check fired in test |
| Connected | Partly | Courier API card done; CRM scopes not yet reduced from defaults |
| Handover | Met | Pack in shared folder; runbook used by a friend to fix a 401 |
The "Partly" led to one more fix before the demo: the CRM connection's scopes were reduced to the three the workflows use.
🌍Where it's used
- Client handovers and sign-off meetings.
- Job interviews, where a short demo of a working project stands out.
- Internal reviews before an automation is trusted with real money or data.
📝Case scenario
In a demo, a learner shows only successful runs. The reviewer asks, "What happens when it fails?" and the learner isn't sure. For the next demo they include a forced 401, show the alert reaching the owner, follow the runbook to fix it and retry. The reviewer's confidence rises, because the failure handling is what the business will depend on.
🖱️Try it
Record your demo, complete the rubric self-review with evidence, assemble the handover pack, and write three case studies. Ask someone who hasn't seen the project to fix a test failure using only your runbook.
⚠️Common mistakes
- A demo with no failure. Sign: the reviewer can't see how problems are handled. Fix: show test 9 of Project 1 live.
- Presenting test figures as business results. Sign: "saves Sharma Textiles 10 hours a week". Fix: say these are results on synthetic test data and estimate real benefits separately.
🛠️For your project
This is the capstone. Save your self-check with links to the repository, the output of all three test files and your demo recording.
✅Quick check
Why should a demo include a failure?
Show the answer
Because the business depends on how failures are handled, not just on successful runs.
What makes a rubric self-review useful?
Show the answer
Honest ratings with evidence for each area, and a plan for anything not yet met.