ShinySoftTechnologies
Training

Taught by people who still ship the code

Most technical training is delivered by trainers. This is delivered by the people who wrote the libraries your team already has in its project file, and who spent last week in a production codebase with a deadline attached. The material comes from systems that are running right now — including the parts that went badly the first time.

Book a CallSee the courses
2017
Microsoft MVP, every year since
50M+
Downloads of the libraries we teach
25+
Years shipping the work behind the material
Architecture & delivery

How the team works

The courses that change how a team makes decisions rather than which framework it uses. These travel — they apply the same whether you are on .NET, JVM or Node.

2 days

Architecture That Survives Contact

How to draw boundaries that still make sense in year three — and how to tell, early, when one is in the wrong place.

  • Where to put a boundary, and the far more common case for not adding one
  • Data ownership, consistency and the coupling that hides in a shared database
  • Monolith, modular monolith and services — costs, not ideology
  • Recording decisions so the next team inherits the reasoning, not just the result
  • Reading an existing system for the seams it already has

ForSenior developers, leads, architects

1 day

Sprint Planning & Estimation

Why estimates miss, what to do about it, and how to plan a sprint that still resembles reality on Wednesday of week two.

  • Slicing work so every item is finishable inside one sprint
  • Estimating with ranges and confidence instead of false precision
  • Capacity, carry-over and the arithmetic behind a believable commitment
  • Definition of ready and definition of done, written for your team
  • Running the ceremonies in under an hour without losing the point of them

ForDelivery teams, product owners, scrum masters

1 day

Discovery, Scoping & Roadmapping

Turning a rough idea into something you can cost, sequence and defend to whoever is signing for it.

  • Getting to the real requirement behind the requested feature
  • Technical feasibility and the spike that answers the expensive unknown first
  • Phasing so something valuable ships before the whole thing is finished
  • Build, buy or integrate — decided on total cost rather than instinct
  • Writing the plan so the trade-offs stay visible after you leave the room

ForProduct, delivery leads, anyone who has to commit to a date

1 day

Engineering Standards & Flow

Code review, branching, CI/CD and the tests worth writing — the practices that decide how fast a team can safely move.

  • Code review that catches design problems instead of formatting ones
  • A branching and release model matched to how often you actually ship
  • Pipelines that fail for real reasons, and stay fast enough to be trusted
  • Where tests pay for themselves, and where they quietly do not
  • Making the standard the default path, so it survives the next deadline

ForWhole engineering teams

1 day

Modernization Without a Freeze

The strangler pattern, applied to your system — how to replace a platform while it stays in production and the roadmap keeps moving.

  • Finding the first slice: small, valuable and genuinely separable
  • Running old and new side by side behind the same URLs
  • Shared libraries and multi-targeting as the bridge between the two
  • Sequencing the data layer, which is where these efforts usually stall
  • Making progress legible to the people funding it, sprint by sprint

ForLeads and stakeholders on a legacy platform

Platform & product

What the team builds on

Every course in this track is backed by a library we publish and maintain. When somebody asks the question the documentation does not answer, the answer is in the room rather than in a follow-up email.

2 days

Xamarin → .NET MAUI Intensive

The migration end to end, run against your own solution — including the dependency list that is what actually stalls these ports.

  • What maps across cleanly, and what has no equivalent at all
  • Replacing abandoned plugins with libraries that are already in production
  • Handlers, lifecycle and the platform code that has to be rewritten
  • Background, offline and permission behaviour on real devices
  • Phasing the port so feature delivery does not stop for it

ForMobile teams facing a port

2 days

Bluetooth LE & Background Execution

The subject that costs teams the most time and has the least reliable material written about it. We wrote the libraries the industry uses for this.

  • GATT, central and peripheral roles, and what the specification does not tell you
  • Scanning, pairing, reconnect and the state machine each OS actually runs
  • Staying alive in the background on iOS and Android without being killed
  • Permissions, battery savers and the store review questions that follow
  • Debugging the failures that only appear on hardware, in the field

ForMobile and firmware-adjacent developers

2 days

Modern .NET Services & APIs

ASP.NET Core as it is actually built today — hosting, dependency injection, data access and getting it deployed somewhere cheap to run.

  • Hosting, configuration and the middleware pipeline that replaced the old model
  • Dependency injection and lifetimes, including where teams get burned
  • EF Core: the query translation and tracking behaviour that bites in production
  • APIs, authentication and versioning for clients you do not control
  • Containers, health checks and telemetry you can operate at 3am

ForBackend developers moving off .NET Framework

1 day

AI for Engineering Teams

Past the demo. What it takes to put a model in front of your own systems and be able to defend the result afterwards.

  • MCP servers and tools over the APIs and data you already have
  • Retrieval and grounding, and why the answer quality is a data problem
  • Evaluating against real cases from your business before customers do
  • Permissions, tenancy and audit when a model can read production
  • Where the payback is, and the workflows that should stay manual

ForDevelopers and leads with a real AI mandate

Nothing here is fixed. Courses get combined, cut down to the half-day a team actually needs, or built from scratch around a problem you are already stuck on — which is how about half of these came to exist in the first place.

Formats

Built around a delivery week

Nobody can hand you a week of their team's capacity without a reason. So the scheduling bends to you, not the other way around.

On-site

We come to you. Best for the architecture and planning courses, where the arguments worth having tend to start at the whiteboard and continue over lunch.

Remote, split into half-days

Delivered live over your own video platform, usually as half-days across a week or two so nobody loses a full sprint. Sessions are recorded for whoever could not make it.

Private to your team

Every session is a private cohort — no public seats, no other companies in the room. Which is what lets us use your actual code as the material.

Review plus upskilling

A fixed-price package: an architecture and codebase review, then training aimed at exactly what the review turned up. Most teams take this one, and it usually answers questions they had not thought to ask.

How it runs

From a first call to a team that works differently

Four steps, and only one of them is the training itself. The preparation either side is what decides whether any of it survives the following month.

  1. A call about your team

    What they are building, where the friction is, and what has to be different in ninety days. Half an hour, no charge, and it is where we decide whether training is even the right instrument.

  2. We read your code first

    Under NDA if you need one. The examples, the exercises and the awkward questions all come out of your repository, so nobody spends the morning learning a sample app.

  3. Delivered in working blocks

    On-site or remote, in half or full days, scheduled around a sprint rather than through the middle of one. Hands on keyboards throughout.

  4. Written up, then followed up

    You get the material, the recordings and a short write-up of what we saw in the codebase and what we would do about it — then thirty days of direct access while the team applies it.

What you are actually buying

The part that outlasts the week

A course everybody enjoyed and nobody applied is the normal outcome of corporate training. These are the things we do differently to avoid being that.

Taught from production, not from slides

Every course here comes out of systems that are running right now, in businesses with real deadlines. Where a practice has failed us, that goes in too — those are the parts people remember.

Your codebase is the case study

We ask for access before the session and build the examples out of your own repository. A generic demo app teaches a generic lesson, and your team already knows where their real problems are.

Small rooms, hands on keyboards

Capped at around a dozen people, with exercises rather than a lecture. Above that it stops being training and turns into a conference talk nobody can interrupt.

You keep everything

Material, code, recordings and the notes we write on your architecture — yours, with no licence attached. Run it again for the next hire.

A month of follow-up included

Training that ends when the room empties does not change anything. For thirty days afterwards the team can put questions to us directly, while they are trying it for the first time.

We will tell you not to book it

Sometimes the problem is a process or a staffing one and a course would just be an expensive week. We would rather say so on the first call than take the booking.

Where most teams start

A review of the codebase and how the team currently plans and ships, followed by two days aimed squarely at what that review turned up. It costs less than guessing at a curriculum, and it means the first morning opens on a problem everyone in the room already recognises.

What is slowing your team down?

Tell us that, and we will tell you whether a course fixes it — and which one. If the honest answer is that training is not your problem, you will hear that instead.

Book a CallSend a Message