Learn software by building something that matters.

A practical Python and generative-AI programme where students design, build, test and explain one trustworthy public-information assistant for a real Caribbean context.

Explore the 20 days Meet Nisa

20: learning days
6: capability phases
1: integrated product
14–18: student age range

What makes this programme different

Working evidence is the curriculum

Learn by shipping

Every concept becomes a function, test, interface state, pull request or demonstration.

Build for a real need

The team develops Nisa around public-information journeys for Grenada’s National Insurance Scheme.

Prove, do not perform

A feature is complete when its behaviour, source, safety and explanation can be checked.

Keep people in control

Nisa explains reviewed information. It never decides a person’s case or replaces the institution.

Choose your depth

Everyone starts together. Challenge grows when you are ready.

These are routes, not labels. You may use different routes for different skills, and helping someone else is part of advancing.

1New to coding

Start

Run Python, change a function, understand the data and make one test pass.

Follow the current lesson and ask what each line does.

2Ready to contribute

Build

Own a small product outcome, work on a branch and prove it in the integrated app.

Claim a lab, define acceptance evidence and open a pull request.

3Ready for a challenge

Go deeper

Improve architecture, retrieval, evaluation, accessibility or failure handling.

Choose an extension only after the core behaviour is reliable.

4Curious about professional systems

Look ahead

See how APIs, databases, deployment and governance grow from the same foundations.

Study the trigger for each tool; installation is not required.

A normal learning cycle

1
Open
Recall yesterday’s idea and name today’s product outcome.
2
Learn
Study one concept through a short demonstration and guided practice.
3
Build
Work in pairs on a small issue, switching Driver and Navigator.
4
Check
Run tests, inspect the diff and compare the result with the acceptance evidence.
5
Share
Explain what changed, what remains uncertain and the next smallest action.

Roles rotate; understanding is shared

Product Owner: Keeps the team focused on user value, evidence and agreed priorities.
Scrum Master: Protects the cadence, surfaces blockers and helps the team improve its process.
Technical Lead: Guards shared contracts and integration choices without owning all the code.
UX/UI Lead: Makes every state understandable, accessible and appropriate for the user.
Quality Engineering Lead: Turns risks and requirements into repeatable checks.
DevOps and Release Lead: Keeps branches, checks and releases visible and recoverable.

Progress

Evidence, not public ranking

The programme records attendance, milestones and individual learning privately. The public website shows the shared standard and examples, never personal student records.

Learning evidence: A working function, test result, explanation, reflection or completed practice checkpoint.
Product evidence: An integrated behaviour, source citation, safe failure state, accessibility check or reviewed pull request.
Team evidence: A clear owner, visible blocker, review record, milestone state and next action.
Client evidence: A confirmed fact, accepted milestone, recorded question, demonstration result or documented limitation.
Operational evidence: A sanitised risk, action, recovery check or delivery improvement without personal student information.

Website map