Sherpa
← Blog
Blog

The most expensive part of a cloud project happens before any work starts

Zohair Nasimi
AWSFinOpscloud consultingcloud assessmentdiscovery

The most expensive hour in a cloud engagement is usually the first one — the one where nobody fixes anything.

Discovery: the phase nobody prices

Every cloud assessment, modernization, or “can you take a look at our setup” starts the same way: someone has to figure out what’s actually going on inside an environment they’ve never seen. Which services, which accounts, which regions. What’s misconfigured, what’s overspending, what’s fragile. That’s discovery — and it’s where the time and money leak before a single improvement ships.

Recently someone reached out mid data-modernization, urgently needing hands-on Amazon Redshift expertise for an architectural assessment. The ask sounded purely technical: “Do you have a Redshift SME?” But the first call wasn’t about Redshift at all. It was archaeology — question after question, reverse-engineering what the real problem even was before help could begin.

That’s the pattern in almost every engagement. The setting changes — Redshift here, a security review there, a cost spike somewhere else — but the first step is always the same slow, manual excavation.

Why discovery is so expensive

Three reasons:

  • It’s serial and human. One expert, one conversation, one question at a time.
  • It’s reconstructed from memory. The customer describes their environment; the consultant builds a mental model from words, not data. Gaps and assumptions creep in.
  • It’s redone every time. Each new engagement, each new expert, starts the excavation over.

By the time discovery is “done,” days are gone and the real work hasn’t started. And because it’s built on description rather than ground truth, the resulting plan is only as accurate as the conversation was complete.

What a grounded report actually contains

When we say “a report grounded in your real AWS environment,” here’s what that means in practice. It isn’t a questionnaire, and it isn’t a dashboard screenshot. It’s the actual state of the environment, pulled from the source:

  • Cost, broken down to the resources and services driving spend — not “your bill went up,” but which line items moved and why.
  • Security findings mapped to those same resources — the misconfigurations and exposures sitting on the systems that matter most.
  • Inventory and architecture — what’s actually running, across accounts and regions, including the untagged, the forgotten, and the drifted.
  • The cross-domain view — the part a call can never give you: which security risk sits on the resource driving your top cost line, which idle infrastructure is quietly billing you, how one change ripples across domains.

That last point is the whole game. Discovery on a call is single-threaded — you learn about cost, then separately about security, then separately about what’s running, and nobody connects them. A grounded report connects them by default, because it’s built from the environment itself, not from a sequence of questions.

The same engagement, two ways

Picture the same request — “we’re modernizing our data platform, can you help?” — run both ways.

The old way: a call. The expert asks what services you use, how your accounts are structured, where the pain is. You answer from memory. They build a mental model, spot the gaps, ask more questions. A day or two later there’s a rough picture — accurate to the extent your description was complete — and only then does a plan start to form.

The grounded way: you generate a report from your environment and send it first. The expert opens it, sees the real architecture, the real cost drivers, the real risks, and the connections between them. There’s no warm-up. The first conversation is already about the solution, because the problem is already on the table — evidenced, not described.

Same expert, same expertise. The difference is that one of them spends the first two days surveying and the other spends them solving.

What changes when discovery is grounded

Flip the order and the whole engagement changes shape:

  • Faster — the slowest phase already happened.
  • Cheaper — no billed hours spent excavating.
  • More accurate — the plan is built on data, not recollection.

“We need someone to come figure out our problem” becomes “here’s exactly what’s going on — help us fix it.” That’s a better starting line for everyone: the customer gets to value sooner, and the expert spends their time solving instead of surveying.

Are you paying the discovery tax?

You don’t have to hire a consultant to feel this. The discovery tax shows up any time expertise meets an unfamiliar environment — including inside your own company. A few signs you’re paying it:

  • Every new engineer spends their first weeks reconstructing “how things actually work here.”
  • Answering a leadership question — “what’s driving the cost spike?”, “are we exposed here?” — means pinging three people and waiting.
  • Your architecture diagram is out of date the day after it’s drawn.
  • The one person who really understands the environment is a bottleneck for everyone else.

Each of those is the same friction: knowledge trapped in people and conversations instead of surfaced from the environment.

The bigger idea

Discovery friction isn’t a Redshift problem or a consulting problem. It’s a cloud problem. Any time expertise meets an unfamiliar environment, someone pays for the excavation first. The fix isn’t a better questionnaire — it’s a grounding layer that lets the environment describe itself, continuously, from ground truth.

That’s the shift worth watching: not replacing the expert, but deleting the archaeology so the expert can start already knowing.

FAQ

What is “discovery” in a cloud engagement? The initial phase where a consultant or team figures out what’s actually in an environment and what’s wrong, before proposing or building anything.

Why is discovery so expensive? It’s manual, serial, reconstructed from conversation rather than data, and repeated at the start of every engagement.

How does a grounded report reduce the cost? It surfaces the real state of the environment from data up front — cost, security, and inventory, connected across domains — so experts skip the excavation and start on the actual problem: faster, cheaper, and more accurately.

Is this only for consultants? No. Any team facing an unfamiliar or drifted environment pays the discovery tax — including internal engineering and platform teams answering their own questions.

Hero image brief: abstract, house aesthetic (navy #0d253b, green #24F398 accents) — a cloud environment resolving from fog into a clean, labeled diagram. Alt: “A cloud environment resolving from fog into a clear, labeled diagram.”

Produced: 2026-07-07

See what Sherpa finds in your AWS.