Corporate training
Corporate Training for Engineering and Business Teams
Training is the service that ends with your own people doing the work — writing the code, running the deployment, spotting the phishing email — rather than calling us back to do it for them. The capability stays in the team after the engagement closes.
We run instructor-led sessions for teams that already exist and already have a codebase. Three subject tracks, three delivery formats, and exercises written against a stack that resembles the one your engineers open every morning.
At a glance
- Cohorts of roughly six to twelve people
- Sessions of two to three hours, with a break
- Formats: intensive workshop, weekly series, or new-hire onboarding curriculum
- Delivered remotely over video by default, with recordings
- You keep the exercise repository, notes and recordings
Subject tracks
What we teach
Three tracks, drawn from the work we do for clients rather than from a catalogue. A programme usually takes one track and goes deep, though a longer engagement can move from one to the next.
Full-stack and mobile development
Backend work in Laravel and Node.js, frontend work in React, Next.js, Vue and Angular, mobile work in React Native and Flutter, and the parts between them that trip teams up: database modelling and query performance, API design and versioning, authentication and authorisation, background jobs and queues, store release and update flows for mobile builds, and writing tests that are worth the time they cost to maintain.
Cloud computing
How AWS, Google Cloud and Azure are actually put together for a working application: networking and access control, managed databases, object storage, containers, CI/CD pipelines, environment promotion, monitoring and log aggregation, and reading a cloud bill closely enough to explain why it moved.
Cyber-security awareness
Phishing and pretexting, password and passkey hygiene, multi-factor authentication, safe handling of customer data, device and travel practice, and how to report a suspected incident quickly and without embarrassment. Delivered for the whole company, with a deeper session for engineers on secure coding.
These tracks are not exam preparation. A certification syllabus is written to be examinable, which means it covers services and options your team may never open, and skips the local detail that decides whether a change ships safely. Ours follow the work in front of your engineers. If the goal is a certificate on a tender document, buy the exam guide and spend the training budget elsewhere — we will say so rather than sell around it.
Delivery formats
Three shapes a programme can take
Short intensive workshop
Two to five consecutive days, cleared in the calendar, aimed at one subject the team needs quickly — a framework the company has decided to adopt, or a cloud migration already scheduled. The intensity is the point: people hold context across a whole exercise instead of losing it between weeks.
The cost is real, though. Nobody ships during a workshop week, and a five-day firehose fades unless the team applies it soon afterwards. Book one when the applying work starts within a fortnight.
Ongoing weekly sessions
One session a week over six to twelve weeks, each two to three hours, with an exercise to finish before the next. This suits teams that cannot stop delivery, and it produces better retention, because the gap between sessions is where people try the idea on real work and arrive with real questions.
It needs a manager willing to defend the slot. A weekly series that keeps getting moved for releases stops being training and becomes a calendar invitation nobody opens.
Onboarding curriculum for new hires
A structured first-weeks path we build once and your team reruns for every joiner: an ordered reading list through your repositories, a local environment set up from scratch, a sequence of small real tasks in increasing difficulty, and a written explanation of the decisions a newcomer would otherwise have to reverse-engineer.
We can deliver the first cohort live and hand the curriculum over, so your senior engineers stop repeating the same fortnight of explanation for every hire.
Choosing between them
The three differ less in what gets taught than in what each one asks of you. Read the last column first, because that is the one a programme usually fails on.
| Format | Elapsed time | Fits when | Asks of you |
|---|---|---|---|
| Intensive workshop | Two to five days | The decision is made and the applying work is imminent | The cohort's delivery time in one unbroken block |
| Weekly series | Six to twelve weeks | Delivery cannot pause and the knowledge has to stick | A slot somebody defends, and a few hours each between sessions |
| Onboarding curriculum | Built once, rerun by you | Hiring is continuous and seniors are the bottleneck | Repository access, and one senior engineer's time while it is written |
Worked example
What an eight-week series looks like from the inside
Formats are easier to choose once you can picture one running. This is the shape a weekly full-stack series usually takes for a cohort of eight, with a session of two to three hours each week and one exercise between sessions.
Weeks 1–2 — read the code together
We start inside the team's own repository, reading its conventions out loud and tracing one request from route to response. The first exercise is small and deliberately winnable, because week one is where a cohort decides whether it is safe to admit not knowing something.
Weeks 3–4 — the core topic
The subject the programme was bought for, taught against a real example the team nominated during the assessment — a page everyone agrees is too slow, or an integration nobody wants to touch. Each exercise ends with something they could open a pull request for.
Weeks 5–6 — the awkward middle
Failure paths, retries, concurrency, the record that arrives in the wrong order. This is where questions stop being general and start being about your system, and where the syllabus gets adjusted most — the plan usually loses a topic here and gains a different one.
Weeks 7–8 — hand it back
The cohort presents its own solutions instead of watching ours, and the last session turns what they agreed into a written convention their code review can enforce. The entry task is repeated here, unannounced, so the before-and-after comparison is like for like.
The proportions move with the track. A cloud series spends more of its middle on environments and less on application code. A security-awareness programme is far shorter and carries no between-session exercise, because the audience is the whole company rather than a cohort with a repository. What stays fixed is the first session and the last, since both ends of the before-and-after check depend on them.
The failure mode is attendance, not difficulty. A cohort that loses half its people to a release in week four rarely recovers, because the exercises build on each other and everyone who missed a week arrives at the next one needing it explained again. We ask for a named sponsor who confirms the roster the week before, and we would rather move a session than run it for half a room.
Method
Exercises on your stack, not a slide deck
A generic course teaches a generic application. The team follows along, the sample project works, and then everyone returns to a codebase that looks nothing like it — different framework version, different folder conventions, an authentication layer somebody wrote years ago and nobody has touched since, and a deployment pipeline with three manual steps.
The test of an exercise is whether it survives the walk back to the real codebase. If the team has to translate the example before they can use it, most of them will not.
So we build the exercises against your stack. Where a client is comfortable sharing the repository under an NDA, we write tasks against a sanitised branch of it, so the naming, the conventions and the awkward corners are the ones the team already knows. Where sharing is not possible, we reconstruct a close analogue from the assessment: same framework versions, same database engine, same deployment target, same broad domain model.
The practical difference is that questions get specific. Instead of asking how queues work in principle, someone asks why the existing job retries three times and then vanishes — and that question gets answered on screen, in front of the whole cohort, which is worth more than an hour of prepared material.
Before we teach
Assessing the level before writing the syllabus
Teams are rarely uniform. A group of eight developers often contains two people who could teach part of the material, four who are steady but have never touched the specific topic, and two who are newer than the hiring manager realises. A syllabus pitched at the average bores the first pair and loses the last.
So we assess first. That is a short written skills questionnaire for each participant, a conversation with the engineering lead about what the team is expected to build next, and a read through a representative part of the codebase where access allows.
The output is a syllabus with a stated starting assumption, a list of topics deliberately excluded, and optional stretch exercises for the people who finish early. We would rather tell you at this stage that the group is split too widely for one cohort, and propose two, than discover it in session three.
What you supply
- A named sponsor who owns attendance and can protect the slot.
- An access decision before the syllabus is written — repository under NDA, or a clear no, so we know which exercises to build.
- One problem the team finds genuinely hard right now. It becomes the spine of the middle sessions.
- Working environments on participant machines, or an hour before session one to fix them. Setup trouble eats a first session faster than anything else.
- Someone who can say what better would look like, so there is a measure agreed before the first session rather than a verdict invented after the last.
Logistics
Cohort size, session length and time zones
Keeping the cohort small enough to be hands-on
We aim for six to twelve participants. Below six, the discussion thins out and the exercises lose the comparison of approaches that makes them useful. Above twelve, the instructor can no longer look at everyone in the session, and hands-on quietly turns into a lecture with an audience.
Larger departments are better served by two cohorts, which also lets us pitch each one correctly. Security-awareness sessions are the exception: those are deliberately run for large groups, because the content is discussion and scenario rather than screen-sharing.
Remote delivery across time zones
Sessions run over video with screen sharing in both directions, so an instructor can watch a participant work and correct in the moment. Our working hours are Mon–Fri, 09:00–19:00 IST (UTC+5:30), which gives 4+ hours of live overlap with US Eastern; full overlap with UK and EU mornings. In practice:
- UK, Ireland and mainland Europe — a live morning session, comfortably inside our day.
- US East Coast and eastern Canada — an early-morning slot their time, running at the very end of ours.
- UAE, India and Singapore — a mid-day or afternoon window with room on either side.
- Australia — their afternoon against our morning, which works but is a narrower window than it looks.
- New Zealand — tighter still: only the first hours of our day land before their working day ends.
- US West Coast — the awkward one, and usually the recorded route with a live question hour.
Where a team is split across too many zones for one live slot, we run the session twice, or record one and hold a live question hour for the others. Recordings are the fallback, not the plan — a cohort that only ever watches is a cohort nobody can see getting stuck.
Deliverables
What the team keeps afterwards
Training that leaves nothing behind is training that has to be bought again. Every programme hands over a set of durable artefacts:
- A Git repository of exercises, each with a starting branch, a worked solution branch and notes on why the solution is shaped that way.
- Session recordings, so anyone who missed a week or joins the company later can catch up unaided.
- Written notes and reference sheets per topic, kept short enough to be read again rather than archived.
- A question log — every question asked in the room with its answer, which is usually the document the team reopens most.
- Where relevant, a checklist or convention document the team agreed during the sessions, ready to adopt into code review.
The material is yours. Use it internally, rerun it for new joiners, and edit it as your stack moves on. The one thing worth diarising is a review of the exercise repository after a major framework upgrade — solution branches age exactly as fast as the code they were written against.
Everyone, not only engineers
Why security awareness targets the whole company
Security-awareness training is the one track we ask you not to restrict to the engineering team. The credentials an attacker most wants are rarely a developer's. They want the finance mailbox that can change bank details, the support account that can read customer records, the recruiter who opens every attachment by job description, and the executive whose travel schedule is public.
So the session is written for a mixed room and assumes no technical background: how a convincing request for an urgent payment is constructed, why a code sent by text is weaker than an authenticator app or a passkey, what a look-alike domain does to a link you were about to trust, which data genuinely must not leave a company system, and what to do in the first ten minutes after clicking something you should not have.
The damaging part is rarely the click. It is the four hours of silence afterwards, because the person who clicked was afraid of looking foolish. We train for reporting without blame, and we ask leadership to sit in the same session as everyone else — a rule that does more for the culture than the slide explaining it.
One thing we will not do is run a simulated phishing campaign against your staff as part of the training. Where those are used to catch people out rather than to teach them, they buy a statistic at the cost of the reporting culture the session exists to build.
Afterwards
Measuring whether the training worked
Exercise completion
Which exercises the cohort finished unaided, and where people got stuck. Recorded per session, not guessed at the end.
A before and after check
The same short practical task set at the start and again at the end, so improvement is observed rather than self-reported.
Signals in your own tooling
Agreed with you beforehand: review comments on the trained topic, test coverage on new work, or how often a deployment needs a senior engineer.
Reporting rate, for security
For awareness training, a rising number of reported suspicious messages is the healthy signal. Treat a fall in reports as a warning, not a win.
We set these measures with you before the first session, because a measure chosen afterwards tends to be the one that flatters the result. Satisfaction scores collected on the last day tell you whether people enjoyed the sessions, which is worth knowing and is not the same question.
Two honest caveats. The before-and-after check only reads cleanly when the same people sit both ends of it, so a cohort that changed halfway through gives a softer answer. And the tooling signals are influenced by everything else happening that quarter — a hiring round, a reorganisation, a quiet month — which is why we agree what would count as a fair comparison at the same time as the measure itself.
Honest scoping
When training is the wrong purchase
Training moves a capability into your team permanently, and it takes time to do that. It is the wrong instrument in at least three situations, and we will say so before quoting rather than after.
When the deadline is closer than the learning curve
If a platform has to ship in six weeks and nobody in the team has used the technology, teaching them will not save the date. Have us build it as a custom software engagement, or bring in contract engineers, and schedule the training for after launch, when there is a real system to learn on and a reason to care.
When the skill is needed once and never again
A one-off migration, a single integration with an awkward third-party API, a compliance-driven change with no sequel — none of these justify building durable in-house knowledge. That is a consulting engagement, with a handover document at the end.
When the gap is seniority rather than knowledge
Judgement about architecture, trade-offs and what not to build comes from years of consequences, and no course transfers it in eight weeks. If the team needs someone to make those calls, the answer is a hire — training the people around that hire is what makes it pay off.
There is a fourth case we cannot fix at all. Where a team is not learning because it has no time to practise, no room to make a mistake, or no interest in the direction the company has chosen, a syllabus is the wrong tool. Sessions run, attendance holds, nothing changes. That conversation belongs with the engineering lead before a quote is written, and we would rather have it than take the booking.
How training is priced
Training is quoted per engagement, in US dollars. The assessment that produces the syllabus is a defined first step, quoted separately and credited against the programme if you go ahead. There is no per-participant surcharge, and the artefacts listed above are included rather than sold separately.
Four things move the number:
- Track and depth — how far past the fundamentals the syllabus has to go.
- Number of sessions and cohorts — two cohorts of eight cost more than one of twelve, and are usually worth it.
- Bespoke exercise material — writing tasks against your codebase is normally the largest part of the preparation.
- Curriculum handover — an onboarding path your team reruns without us has to be documented to stand up with no instructor present.
All prices in US dollars (USD). We can invoice in GBP, EUR, AUD or INR on request.
Corporate Training — FAQs
Ping us about your team
Tell us what your team needs to learn
Send us the team size, the track you have in mind and what they are expected to build next. We will come back with a proposed syllabus, a format recommendation and a quote — or with a straight answer that training is not what you need here.
Related services
Web Development
Fast, scalable websites and web apps to develop web application solutions with Laravel, React and modern stacks.
Mobile App Development
Native and cross-platform iOS & Android apps built by the best app developers, with React Native and Flutter.
Custom Software
Custom software development for bespoke CRM, ERP and SaaS platforms, engineered around your exact workflow.