Build vs. Buy: The Platform Dell Couldn't Buy

Meet Dell, one of the largest technology companies in the world, with over 100,000 employees and hardware running in businesses everywhere, from storage systems like PowerScale to the servers and laptops on every office floor. Underneath the scale, Dell's situation looks like any engineering company's: products to build, customers to support, and support teams whose speed decides whether those customers stay.

Behind those products sits a global support and engineering organization that needs to replicate, debug, and validate customer environments every single day. To do that, they needed a piece of software that nobody sells.

When a Dell customer reports a problem, a support engineer needs a test lab that matches that customer's setup. How quickly they can get one often decides whether the case is resolved the same day or over several days.

For years, that was a bottleneck. Labs lived on workstations under desks and on shared servers, and only a handful of senior specialists could configure a fresh one to match a specific customer. Everyone else had to ask one of them.

JL, a Senior Principal Engineer at Dell, was tasked with making labs self-service, so that any engineer could replicate a customer's environment in minutes. Dell had already tried twice: both earlier versions of the tool worked, but they demanded specialist steps and cost skilled engineers time they should have spent solving customer problems. The third version, Dynamic Lab, would be as easy to open and use as any website.

Self-service infrastructure provisioning is a category you can buy. What Dell needed was not.

To be useful to a support engineer on a live case, Dynamic Lab had to stand up a PowerScale cluster on a specific product version, with the backend networks and configuration matching what a particular customer was running. That meant the application had to know things only Dell knows, and connect to systems only Dell operates:

• Dell's products, down to individual versions and cluster topologies
• Dell's existing automation, the Jenkins and Ansible jobs the team had already built and refined
• Dell's Python backend services for VM scanning and data collection, written long before the app existed
• Dell's hypervisor estate, running on internal ESXi, vCenter, vSAN, and NSX
• Dell's identity system, with Okta SSO for 6,000 potential users
• Dell's access path, with an embedded Guacamole-based SSH client so engineers reach provisioned VMs from the browser

A general-purpose provisioning product could have delivered a fraction of that and asked Dell to adapt its process to the rest. That pattern is how companies accumulate SaaS sprawl: a portfolio of near-fit products, each covering a fraction of a need and each adding a renewal to manage. For a tool meant to remove a bottleneck for 6,000 engineers, adapting the process was the bottleneck.

So the real choice was never build or buy. It was build it, or keep routing six thousand engineers through a handful of specialists. For how to run this decision on your own tools, see our build vs. buy framework for internal software, and for the buy side of the same decision, see how the World Bank replaced the Tableau dashboards it used to buy.

That choice had historically been a bad one, which is why the bottleneck had survived so long.

Everything behind the tool already existed. The services that gather the data and build the labs were Dell's own, written by JL's team. What was missing was an interface anyone could use, and the conventional way to build one meant a second technology stack to maintain, a separate skill set to keep on the team, and another set of dependencies to take through Dell's procurement process.

JL spent six months evaluating those options, and half a year of a senior engineer's time produced no viable path. His own earlier attempts at an interface had been, in his words, "hacked-together HTML" that "looked like garbage and were tough to use as an end user." That standard would not hold under the Dell brand. This was the old equation: buying meant a product that could not reach Dell's systems, and building meant either a team Dell was not going to staff, or a result that looked like garbage.

JL started prototyping Dynamic Lab in Reflex and had a working demo within a week. Every backend service he had already written, including the VM scanners, the Jenkins and Ansible coordination, and the data collection logic, could be reused directly. No rewrite. No separate frontend team. No new toolchain.

The engineer who understood the problem was the engineer who shipped the solution. No outsourcing, no second team to brief, no handoff between the people who knew the infrastructure and the people who could build a UI.

Today, any Dell support engineer, not just a handful of specialists, can pick a product, pick a version, and have a complete working copy of a customer's setup ready to troubleshoot in a few minutes.

Dynamic Lab is still in production beta, and already more than 200 Dell engineers use it every day, keeping roughly 2,000 live test setups running at once, all on equipment Dell already owns, with no outside vendor involved. Next comes the rest of the rollout: the more than 6,000 engineers the old process, waiting on a handful of specialists, was holding up.

What started as one senior engineer fixing his own team's bottleneck is now how Dell's entire support and engineering organization gets customer problems solved: software Dell built once and owns outright.

This section is written for your technical team. In short: nothing Dell already had needed to be replaced.

Dell owns the application, so there is no vendor lock-in and no roadmap but Dell's. JL is extending it with:

1. Taking Dynamic Lab beyond Dell's own facilities, so it can also run inside customer and partner environments
2. Letting the people who create lab templates add the files they need themselves, directly through the app
3. Scaling the platform from hundreds of engineers to thousands

The first item says the most. A tool built to solve an internal bottleneck is now being extended toward customer and partner environments. It is not a purchase Dell avoided. It is a capability Dell has.