# Unpopular opinion: build the foundation first, not what customers ask for

> Most fleets run servers from two or more vendors, and each vendor's tools stop at its own hardware. Why we started with one model of every server, before any feature.

- URL: https://blog.asama.ai/blog/unpopular-opinion---do-not-build-what-customers-want/
- Author: Manish Gautam
- Published: 2024-11-29
- Tags: Company

We did not start with the features customers asked for. We started with the foundation every one of those features stands on: one model of every server in the fleet, whoever made it.

## Why we ignored Pareto

The problem of plenty is a good problem to have. Every startup learns the Pareto rule early: find the 20% of problems that cause 80% of the mayhem, and fix those first. Simply put, choose the work with the most impact.

Or is it?

Imagine you are a real estate developer. Which part of the building excites your customers most? The clubhouse, the balcony view, maybe the interiors. Growth gurus will tell you to build what customers want. But the first thing a buyer wants is a house that lasts, and nobody says it out loud. No good builder asks customers whether they would like a building that stays up. At least I hope not. It is implied.

So, however bright the customer's eyes get about the balcony or the interiors, the builder builds the foundation first. Without it, nothing sells, however impressive the features. That is the choice we made.

## Every fleet is a mixed fleet

Almost no infrastructure team relies on a single hardware provider. Nearly every team we have worked with or talked to runs at least two server vendors, usually by design: dual sourcing is basic supply-chain risk management, and many teams go further with a multi-vendor policy. The few that buy from one supplier tend to pay for it at the negotiating table. A mixed fleet is the normal case: different BMCs, different firmware tools and different names for the same sensor.

## Vendor tools stop at their own hardware

Each vendor gives you two kinds of tool. The BMC console on every server (iDRAC, iLO, XClarity Controller) manages one machine at a time. The vendor's fleet manager (OpenManage Enterprise, OneView, XClarity Administrator) does manage hundreds of machines at once, power actions and firmware baselines included, but only that vendor's hardware. White-box and ODM servers often ship a BMC with a Redfish API and no fleet tool at all.

So no vendor tool sees the whole fleet, and none of them connects a slow workload to the BIOS setting or firmware level behind it.

## Corporate IT is served. The infra team is not.

Two teams feel this differently. Corporate IT, which runs laptops, office networks and back offices such as call centres and warehouses, buys an IT asset management (ITAM) or data centre infrastructure management (DCIM) tool and is mostly served: ITAM tracks what you own, and DCIM tracks space, power and cooling.

The infrastructure team, which runs production, is not. Neither tool tells it why a server is slow, so the team goes into a loop: it wrestles with vendor consoles, writes scripts to fill the gaps, the scripts break when the fleet changes, and the struggle starts again.

## What we are building first

The foundation: deep visibility across the whole fleet, every server in one model, whoever made it. Everything we build after it stands on it, the same way the clubhouse needs the building.

**Update, October 2026.** That foundation, one normalised model of every server down to BIOS settings, firmware levels and PCIe links, is now generally available. Detection built on it has been validated, and investigation and remediation are expanding on top of it. To see it on your own hardware, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.

**Read next:** [How we named Asama: Sanskrit for "without an equal"](https://blog.asama.ai/blog/how-did-we-name-our-start-up---asamaai)