If you own an engineering organisation, you know the cost that never shows up in a report: the hours a developer loses standing up an environment, guessing how to build the project, or waiting two days for a review. On its own each one looks harmless; across a whole team, friction in day-to-day work is one of the most expensive and least measured costs a technology company carries. Good developer experience (DevEx) is, quite simply, the work of removing that friction.
In our experience, DevEx is surprisingly rarely a talent problem. More often it is a matter of tooling, environments and standards that nobody ever treated as a product. We approach it differently: we treat the internal platform and the process as a product whose user is the engineer. And even if you have no platform team in-house, we staff those roles with DevOps and platform engineering skills.
Why does developer experience drive delivery speed and retention?
The reason is straightforward: a productive engineer spends most of their time solving the business problem, not fighting the tooling. When the path from idea to production is short and predictable, the team ships faster, without heroics; when it is full of obstacles, pace drops and your best people start looking around.
Retention is the underrated part here. An experienced developer rarely leaves over a single thing, but small frustrations compound: a flaky build, an environment that only “works on my machine”, a review with no end. Good DevEx is therefore not only a productivity lever; it is a real argument for keeping the people who are the most expensive to replace.
What is platform engineering and an internal developer platform?
Platform engineering is the discipline that takes the repetitive, tedious parts of an engineer’s work and turns them into ready-to-use, self-service capabilities. The result is an internal developer platform (IDP): a layer that lets a developer spin up a new service, environment or pipeline without filing a ticket to another team. This is not about buying a single tool, but about assembling a coherent experience out of pieces you usually already have:
- golden paths, the paved, recommended ways to build and deploy services,
- a service catalog and templates, so a new project starts from sensible defaults,
- self-service for environments, secrets and resources, without manual middlemen,
- an observability layer wired in by default, not bolted on at the end.
A good platform is thin where teams need freedom and opinionated where a standard saves everyone time.
Which developer tools and self-service capabilities give the biggest return?
The fastest payback comes from whatever an engineer does many times a week. So we start with self-service capabilities that take the team out of someone else’s ticket queue:
- spinning up services and environments on demand from predefined templates,
- CI/CD pipelines as a default, rather than configured from scratch in every repository,
- secrets and access management that is secure but does not require asking for every key,
- a single view of service state (logs, metrics, deployments) in one place.
The point is not the number of tools but tying them into one understandable whole. We have seen far more teams suffering from a sprawl of inconsistent tools than from a lack of them, so before adding anything, we look at what can be simplified and unified.
How do documentation and onboarding paths shorten time to first commit?
Onboarding is the most merciless test of developer experience. If a new joiner needs a week to build the project and reach production, that is a signal the whole team feels the friction too, they have just grown used to it. So we treat time to a first meaningful commit as a metric, not folklore.
We favour documentation that lives close to the code: a README that genuinely lets you build the project, documented golden paths, and onboarding checklists kept current by the people who just went through them. Instead of one giant document nobody reads, we design short, task-oriented paths: “how to run it locally”, “how to deploy”, “how to add a new service”.
What does sensible environment provisioning for teams look like?
Environments are where DevEx most often breaks down. The classic “works on my machine” problem comes from environments that are hand-assembled, drifted and impossible to reproduce. We tackle it from the angle of repeatability.
In practice that means infrastructure as code (Terraform, Helm) and containerisation, so an environment can be recreated with a single command rather than from one person’s memory. We add ephemeral environments per pull request and parity across local, test and production, so surprises do not wait until deployment. The outcome is mundane but measurable: less time on “why won’t this come up”, more on actual work.
How do code standards and review practice shape developer experience?
Standards are sometimes mistaken for bureaucracy, when they are precisely the opposite: a well-chosen standard means fewer decisions and fewer arguments in review. When formatting, linting, conventions and quality gates are automated, review stops being a fight about style and starts being about what matters, the logic and the risk.
Review itself is a piece of DevEx that is easy to forget. A pull request left hanging for two days is not just a delay; it is a broken flow and mounting frustration for the author. So we treat it as both a human and a process matter:
- small, reviewable changes instead of unmanageable mega-PRs,
- clear expectations on review turnaround time,
- automating what can be automated (lint, tests, scans), so humans look at meaning,
- a feedback culture where review teaches rather than blocks.
How do you measure developer experience so you are not guessing?
Without measurement, DevEx turns into opinions. We prefer to ground it in signals that combine hard data with what engineers actually feel. We look at flow metrics in the spirit of DORA (deployment frequency, lead time from commit to production, change failure rate, time to restore), and alongside them use lightweight DevEx/SPACE-style surveys, because some friction is only visible from the inside.
The important thing is not to turn metrics into another source of pressure. The numbers should point to bottlenecks, not grade people, and tell you where to strike first and whether the fix worked.
Which DevOps and platform engineering skills do we provide?
This is the crux: you do not need a ready-made platform team in-house to raise developer experience. Even if we did not build your particular platform, we have people who do these things on custom software projects and in our DevOps practice. Among others, we staff roles such as:
- a platform / DevOps engineer building self-service, CI/CD and infrastructure as code,
- an SRE owning observability, reliability and sensible error budgets,
- an architect sorting out golden paths, standards and ownership boundaries,
- a backend / senior developer bringing quality and review practices into the product team itself.
We shape the team around the specific gap, and we verify skills before the start, not “just in case”. We deliver the people who do it, not a deck about how it should be done.
How do we do it at RITS?
We do it as a nearshore partner from Poland, with real experience in DevOps, platform engineering and custom software projects. Instead of starting from tools, we start from where your team loses time, and only then decide what to simplify, automate or standardise:
- we step into the existing process rather than imposing a ready-made template from outside,
- we tie tooling, environments and standards into one coherent, self-service experience,
- we work in a close time zone, so we join your review rhythm and meetings without a long ramp-up,
- we verify skills before the start and match the role to the real need.
Most often we deliver this as team augmentation or a dedicated team, because DevEx is continuous work, not a one-off rollout with an end date.
Where to start with improving developer experience?
Start by measuring the single most painful piece of friction: onboarding, review wait time, or environment setup. One countable thing gives you a baseline and a target, instead of generalities about “engineering culture”. Then close one golden path end to end, and only from there extend the platform to more teams.
If you are weighing whether this is work for a full-time hire, team augmentation or a dedicated team, we covered the differences in our article on IT engagement models.
Want to genuinely improve developer experience: tooling, environments and standards? Let’s talk - we’ll match the skills and the approach to your team.