Employable software engineering, taught through live projects
We teach on open tools that run on modest hardware, and we work keyboard first, so accessibility is built in from day one and learners design software everyone can use.
Founded through workshops in Nigeria and now launching with a first cohort in rural Greece, we widen access to digital skills in low resource settings.
Learners ship working software from week one.
Our method is professional practice, taught to industry standard.
From week one, learners build software in a team and ship it together.
One team, one real product, shipped.
How we teachIn real projects, they use test driven development, pairing and real time web development.
TDD without mocks, pairing, continuous integration.
See the dojosOn open tools, we revive end of life computers, so learning holds up on modest hardware.
Ekolite, open source under the MIT licence.
Ekolite on GitHub
Every project does two things at once, because the learning and the impact are one.
A developer
with employable skills that last
A community
with software it keeps and runs
And in the places that need it most, that is how opportunity takes root. The skills and the software stay where they are scarce, and a community comes away more able to build its own future.
Grassroots in Nigeria, launching in rural Greece, and built to cross borders.
Grassroots teaching, learned through real client work.
Our first European cohort, rigorous and agile software engineering, on the border with Bulgaria and Türkiye.
Shared cohorts across the border, then a growing network through the Balkans and Africa.
Ideas
Writing on coding, software engineering, and digital education.
We added the missing check on our API specification, pushed it, and it failed on its first run. Not because anyone had forgotten to regenerate the file, but because the file was never a function of the source. It depended on whose environment last produced it, and only a machine with no environment could ever have noticed.
Most teams have a hidden delay between saying done and being able to ship. The goal is to be technologically ready to release at any moment, even when the feature is half built. Why our deploy workflow ships the commit that was tested rather than the newest one.
If the software worked five minutes ago, only five minutes of change can be to blame, and debugging turns into reading. That is what a green trunk buys. It is bought by agreement, not by tooling, and one of our own checks turns out to be incapable of failing.
Pick what sounds like you
