KENYA · GUIDE 0630 · EDITION 4.2
Coding clubs in Kenya: Risks and Launch Plan
Set the conditions for a safe commercial test
- Unsuitable online interactions
- Copy-paste learning
A club looks productive but teaches little when every child reproduces the same demonstration and cannot explain why their program behaves differently after a small change.
A risk list is useful only when it changes a decision. For each risk, write the observable warning, who checks it and the response before the next commitment. Do not treat a reserve of money as permission to continue unsafe or unauthorized work.
Use a small, measurable pilot
Run one session creating a small interactive program with a clear learning objective.
The pilot scope is: Run coding clubs around age-appropriate projects, available devices, learner starting points, safeguarding arrangements, and a clear balance between guided work and independent problem solving.
| Gate | Evidence before continuing |
|---|---|
| Scope agreed | Run coding clubs around age-appropriate projects, available devices, learner starting points, safeguarding arrangements, and a clear balance between guided work and independent problem solving. |
| Output acceptable | Ask learners to explain and change their own project, checking what happens when an input changes rather than accepting a copied working program as learning evidence. |
| Costs recorded | Include facilitator preparation, device access, software setup, safe learning accounts, materials, supervision, and time helping learners diagnose errors without taking over their projects entirely. |
| Buyer response recorded | Keep project intentions, learner explanations, debugging attempts, prompts, collaboration observations, account barriers, and independent changes that indicate what the next club activity should reinforce. |
Stage the launch around prerequisites
First confirm the buyer specification and activity requirements. Then compare suppliers, establish suitable facilities and prepare the operating record. Run the bounded trial when those prerequisites are in place. Review actual costs, quality failures and cash collected before increasing the commitment.
This sequence is not a promise that the complete business cycle fits into 30 days. Growing periods, qualifications, approvals, seasonal access and customer buying cycles can require longer. Revise the schedule when a prerequisite changes rather than skipping it to meet a launch date.
Choose continue, revise, pause or stop
Continue only when the scoped result is accepted and direct costs and payment timing are workable. Revise one part of the offer if the problem is identifiable and affordable to test again. Pause when required information, permission, skills or resources are missing. Stop the affected work when safety, consent or lawful authority is uncertain.
Keep a maximum test loss and unpaid-balance limit suited to your actual funds. A successful single delivery is useful evidence, but it does not establish year-round demand or justify committing every available resource.
Tie launch milestones to observable checks
| Risk signal | Evidence to inspect | Response to test |
|---|---|---|
| Score never resets | Inspect green-flag stack. | Place set score zero in startup. |
| One click adds many | Check duplicate scripts/forever loop. | Keep one click event increment. |
| Project lost | Check saved file path. | Reopen local copy before departure. |
Outstanding go / hold conditions
- No club delivered, child data collected or project tested on actual devices.
Assign an owner, evidence reference and review date to each unresolved condition. Do not give every milestone a fixed calendar date when it depends on a crop, production, approval or competence cycle. Run only a suitable limited trial, reconcile accepted output and actual cash, and record whether the evidence supports holding, revising, proceeding within the limit or stopping.