One learning path, four stages of developer training
Most training catalogues are a pile of unrelated courses. Ours is a single path with four stages — here is the reasoning behind that structure and how to find your place on it.
Ask a team what training they need and you usually get a list of technologies. Ask them six months later what changed, and the honest answer is often "not much". The course was fine. It just did not connect to anything before or after it.
That is the problem our catalogue is built around. Instead of a pile of unrelated courses, we run one learning path with four stages. Every course sits at a stage, and every stage assumes the one before it.
Stage 1 — Foundation
The ground every developer stands on: servers, git, containers, modern PHP.
This is the stage teams are most tempted to skip, and the one that costs them later. A developer who is uneasy on the command line, who treats git as a mysterious ritual, or who has never built a container image will hit a ceiling no framework course can lift. Foundation is unglamorous and it pays for itself faster than anything else we teach.
Stage 2 — Practitioner
Ship real products the production-quality way: web, mobile, APIs, and AI-augmented work.
Here the questions change from "how does this work" to "how do we ship this without regretting it". Laravel and Livewire, Flutter, API design and security, and working alongside AI tooling rather than around it. The output of this stage is software other people depend on.
Stage 3 — Professional
Run serious systems: central identity, observability, and agent infrastructure.
Shipping is not the same as operating. This stage is about the systems that only reveal themselves once real users arrive — single sign-on and access control, knowing what your application is doing in production, and the infrastructure that supports AI agents in a real environment.
Stage 4 — Architect
Make design decisions you can defend — with and without AI at your side.
The last stage is about judgement. Not which framework, but which trade-off, and being able to explain the choice to a room that will live with it for years.
Finding your stage
A useful test: the stage you belong in is the one where the material is slightly uncomfortable. If a syllabus reads as obvious, go up. If it reads as alien, go down one and come back. Teams often split across two stages, and that is fine — people learn faster next to peers at the same level than in a room pitched at an average nobody occupies.
Scheduling, format and pricing are decided per run, because a public class and an in-house team engagement are genuinely different things. Browse the catalogue at Trainings, or write to [email protected] and tell us where your team is stuck.