Case study · Cloud platform
Four years on the same platform, still shipping
Doprax runs a cloud platform out of Copenhagen. We have been part of their engineering team since October 2021 — not a project with an end date, but developers embedded in a product that has to stay up while it changes.
Engagement · Ongoing, since 2021
Engineers embedded in a cloud platform team for four years and counting.
- Industry
- Cloud platform & developer tools
- Solution
- Platform engineering
- Engagement model
- Embedded engineers
- Engagement length
- Oct 2021 – ongoing
- Market stage
- Live platform, continuous delivery
- Client
- Doprax, Copenhagen
- Scope
- Staff augmentation & development
- Platform
- Cloud infrastructure
Outcomes
The only metric that matters on an embedded engagement
Capacity is easy to buy. Retained context is what a four-year relationship actually produces.
-
4 yrs
And still shipping together
The engineers who learned the platform in 2021 are still working on it. On an embedded engagement, nothing else says as much.
Engagement start October 2021, ongoing
-
3x
Increase in deployment frequency
Deployment tooling treated as part of the product means changes reach the platform's users more often and with less ceremony.
Compared with the release cadence at the start of the engagement
-
99.9%
Platform availability maintained
Changes delivered incrementally behind the existing interface, so the developers building on the platform never had to plan around us.
Measured across the platform during the engagement
Context
The situation before the engagement
Why platform products are unforgiving about who works on them.
The business
Doprax runs a cloud platform out of Copenhagen: infrastructure and tooling that other developers build their own products on.
The starting point
Platform software is used by developers, which makes it the least forgiving kind there is. Its users notice every regression and depend on its uptime for their own products.
The trigger
Growing a platform needs capacity, but the wrong capacity costs more than it adds: contractors who need managing, or engineers who leave before their platform knowledge is worth anything.
What they wanted
Engineering that behaves like their own team — people who learn the platform deeply, own parts of it, and are still there in a year, because replacing that knowledge costs more than the engineers do.
Constraints
The users are developers, and they notice everything · downtime affects other people's products, not just yours · changes must stay backward-compatible far longer than usual · context takes months to build and minutes to lose.
System
What it runs at today
The engagement as it runs today.
-
4+
Years and counting
Continuous since October 2021, with capacity flexing as the roadmap required
-
1
Process, the client's
Their tools, standards and review cycle, adopted rather than negotiated
-
5.0
Client rating
Rated by the client in a verified review published on Clutch
-
0
Separate reporting line
Our engineers are reviewed by their people and review theirs
The engineering problem
Four things that make platform work different
Building for developers is not building for users with more patience. It is a different discipline.
-
Your users will notice every regression
Consumer software can ship a small regression and fix it quietly. A platform's users are engineers whose own products break, who read changelogs, and who will reconstruct exactly what changed and when.
What we did
Backward compatibility treated as a hard requirement rather than a goal, with changes designed so existing users are never forced to move on our schedule.
-
There is no convenient moment for downtime
Every maintenance window is somebody else's production incident. A platform cannot pause to rebuild itself, which rules out most of the comfortable ways to make a large change.
What we did
Changes delivered incrementally behind the existing interface, with the deployment tooling treated as part of the product because on a platform the release process is part of what customers experience.
-
Context takes months to build and minutes to lose
A platform's complexity is mostly invisible: which assumptions matter, which paths are load-bearing, why something was done a strange way. A rotating team pays this cost repeatedly and never reaches competence.
What we did
The same engineers retained across four years. This is the entire value proposition of the arrangement, and the reason capacity flexes rather than the people changing.
-
Outside engineers usually cost more attention than they save
Capacity that needs briefing, supervision and translation is not capacity. Many augmentation engagements quietly fail because the client's senior people end up managing the supplier.
What we did
We adopted the client's process rather than importing ours, and moved from assigned tasks to owned areas as early as they allowed — so the engagement reduced management load rather than adding to it.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Platform
- Cloud infrastructure
- Containerised services
- Deployment pipeline
The client's platform, which our engineers work inside rather than alongside.
-
Engineering
- Backend services
- APIs
- Backward compatibility
Feature and infrastructure work delivered so that existing users of the platform are never forced to change to accommodate it.
-
Reliability
- Monitoring
- Alerting
- Incident response
The unglamorous engineering that keeps a platform boring in the way its users need it to be.
-
Ways of working
- Client process
- Shared code review
- Joint planning
One team: our engineers in their standups, their review process and their planning, not reporting in from outside.
On an embedded engagement we adopt the client's technology and standards. The value is fluency in their system, not opinions about ours — and a supplier arriving with strong views about the stack is a supplier creating work.
Solutions
What an embedded team actually does here
This is not a project with a deliverable. It is ongoing ownership of parts of a live product.
-
Platform engineering
Feature and infrastructure work on the platform itself, released without disrupting the developers building on top of it.
-
Deployment and tooling
The tooling that makes deployment predictable, because on a platform product the release process is part of the product.
-
Feature development
New capability designed for backward compatibility, so existing users are never forced to change on our schedule.
-
Reliability work
Monitoring, error handling and the unglamorous engineering that keeps a platform boring in the way its users need.
-
Working as one team
Our engineers work in the client's process, their standups and their codebase, reviewed by their people and reviewing theirs.
-
Continuity
The same engineers over years, which is the actual product of a staff augmentation engagement — retained context.
Key capabilities
What it does day to day
What an embedded team does, as distinct from a project team.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Platform engineering | Embedded team | Continuous | Feature and infrastructure work released without disrupting the platform's own users |
| Deployment tooling | Embedded team | Per release | The release process treated as part of the product, because its users experience it |
| Backward compatibility | By design | Every change | New capability delivered without forcing existing users to migrate |
| Reliability work | Continuous | Ongoing | Monitoring, error handling and incident response |
| Ownership | Embedded team | Ongoing | Owned areas of the platform rather than assigned tickets |
| Continuity | By design | Across years | The same engineers, so context accumulates rather than resetting |
Integrations
How the moving parts plug in
How an outside team becomes part of an inside one.
What we bring
- Engineering capacityFlexed with the roadmap
- Platform fluencyBuilt over years, retained
- ContinuityThe same people
The client's process
- Their tools & standardsAdopted, not negotiated
- Shared code reviewBoth directions
- Joint planningOne roadmap, one team
The platform
- Features
- Infrastructure
- Deployment tooling
- Reliability
There is no deliverable at the end of this arrangement and no handover document. The output is a platform that kept shipping for four years with the same people working on it.
Security & data
How we work inside someone else's platform
Embedded engineers have real access to a live system that other businesses depend on, which sets the standard for how that access is handled.
-
Client-controlled access
Access is granted, scoped and revoked by the client through their own systems, exactly as it is for their employees.
-
Reviewed changes
Our engineers' changes go through the client's review process. Nothing reaches their platform without their people seeing it.
-
Production discipline
Deployment follows the client's release process. The platform's users are other businesses, so nothing is shipped informally.
-
Incident participation
Our engineers take part in incident response under the client's process rather than escalating to a separate supplier chain.
The brief
A platform product never has a convenient moment to pause
Platform software is used by other developers, which means it is unforgiving. Its users notice every regression, depend on its uptime for their own products, and do not accept a maintenance window as an explanation.
Doprax needed engineering capacity that behaved like their own team rather than an outside supplier: people who would learn the platform deeply, own parts of it, and still be there in a year — because the cost of replacing that knowledge is higher than the cost of the engineers.
- Engineers embedded in the client's team, not a separate unit
- Deep platform knowledge retained over years
- Changes shipped without disrupting the platform's users
- Capacity that flexes without restarting the relationship
What makes platform work different
- 01The users are developers, and they notice everything
- 02Downtime affects other people's products, not just yours
- 03Changes must be backward-compatible far longer than usual
- 04Context takes months to build and minutes to lose
Process
How a four-year engagement starts
Long engagements are won in the first three months, by whether the outside engineers become useful without becoming a burden.
-
Learning the platform
The first weeks went into understanding the platform and its users properly, rather than producing early output that would need rewriting.
-
Joining the process
We adopted the client's tools, standards and review process rather than importing ours, so there was one way of working, not two.
-
Taking ownership
Moving from assigned tasks to owning areas of the platform, which is where an embedded team starts being worth more than contractors.
-
Scaling the team
Capacity adjusted over the years as the roadmap demanded, without restarting the relationship or losing context each time.
-
Still going
The engagement is ongoing. The engineers who learned the platform in 2021 are still working on it.
Technology
The client's stack, worked in as their own team would
On an embedded engagement we adopt the client's technology and standards. The value is fluency in their system, not opinions about ours.
Platform
- Cloud infrastructure
- Containerised services
- Deployment pipeline
Engineering
- Backend services
- APIs
- Backward compatibility
Reliability
- Monitoring
- Alerting
- Incident response
Ways of working
- Client's process
- Shared code review
- Joint planning
Business impact
What four years has produced
Three things the client gets that a project engagement cannot deliver.
-
Knowledge that compounds
Engineers who understood the platform in year one are considerably more valuable in year four.
-
Capacity without renegotiation
The team grows and shrinks with the roadmap rather than with a contract cycle.
-
One team to manage
Adopting the client's process means the engagement reduces management load instead of creating a supplier to run.
The result
The strongest thing we can show is that it has not ended
Four years in, our engineers are still working on the Doprax platform, in the client's team and their codebase, with the context they built in 2021 still in the room.
The client rated the engagement 5.0 on Clutch and described the team's talent and agility. An ongoing four-year relationship is the part we would ask a prospect to weigh.
- Continuous engagement since October 2021
- Engineers embedded in the client's own team and process
- Platform knowledge retained rather than rebuilt
- 5.0 rating in a verified Clutch review
What makes an embedded engagement work
- 01Adopt the client's process; do not import your own
- 02Spend the first weeks learning, not producing
- 03Move from tasks to owned areas as early as they allow
- 04Keep the same people — retained context is the whole product
Client review
What the client said about the work
Published on Clutch, where the client is verified and we cannot edit or remove what they write.
-
Staff Augmentation
Staff Augmentation & Software Development for a Cloud Platform
Their talent and agility as developers are exceptional.
Hemen Showkati
Co-Founder & CEO, Doprax Oct 2021 – Ongoing
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate