Why Discovery Matters

For this episode of the Ellipsis Drive podcast, we sat down with Dan Pilone, CEO of Element 84, a geospatial engineering firm known for guiding organizations through some of their toughest technical decisions. Dan has seen the buy vs build dilemma unfold from every angle, from teams eager to build everything themselves to organizations convinced that an off-the-shelf tool can seamlessly solve all of their problems.

This article continues our ongoing exploration into how organizations design their geospatial stacks in a world where expectations are rising, data volumes are exploding, and AI is reshaping what's possible. But before choosing to buy, build, or take a hybrid path, Dan argues that one step is non-negotiable: discovery. 

Dan emphasized the limits of surface-level conversations: “You can only get so much from a business development call… discovery is where we really understand what they’re trying to do.”

Discovery isn’t just a formality. It’s the phase that reveals what problems truly need solving, where value lives, and which constraints (technical, financial, or organizational) will shape the right path forward. Skipping this could lead to costly mistakes.

Where Are You on the Spectrum? (And How Discovery Reveals That)

One of Dan’s most powerful observations is that customers often self-diagnose. “Clients often come in convinced they know what they need, but those assumptions frequently collapse under scrutiny.

Through its discovery workshops, Element 84 helps teams unearth what’s really going on with a team’s spatial data. In doing so, they regularly encounter two themes:

• Over-confidence in custom build
  Many organizations lean toward building from scratch, believing it gives them ideal control or IP. But Dan warns: “A straight build from scratch is almost never the right solution… even if you don’t go with us, please don’t build it from scratch.”
• Misplaced uniqueness
  Teams often feel their requirements are entirely bespoke. Dan pushed back: “Your needs will feel unique, but many are not.” What feels like a custom use case often fits into a broader pattern, especially when good discovery happens.

So, discovery surfaces the real tradeoffs: what you can handle internally vs. what is better built or bought externally. 

AI’s Influence on the Build Equation

AI is not just a new toy in Dan’s view. It’s reshaping how we think about building geospatial infrastructure. He describes AI as a “deep horizontal,” very much like geospatial. They are not the full story, but increasingly essential to the mission success of many businesses.

Because of AI, the build conversation has changed. It’s no longer purely about writing services or data pipelines. Now teams are asking: “When should we orchestrate models vs write traditional software?” “How do we integrate APIs, handle data pipelines, or maintain orchestration layers?” “How do we plan for infrastructure that can evolve as foundation models improve?”

Dan also highlights a simple but powerful use case: natural-language geocoding. “Being able to say ‘the suburbs of Boston except the airport’ and have that translate … that is huge.”

But there’s a reality check: “Foundation models aren’t great yet, but they’re going to be great.”

That means building for AI isn’t about short-term hype, it's about future-proofing, and discovery is more critical than ever.

A Case Study: When Discovery Reshapes the Plan

During the conversation, Dan shared a clear example of how discovery can completely change a project’s direction.

A client preparing to launch a new Earth Observation instrument came in with a straightforward request: Build the backend infrastructure. But because the satellite hadn’t launched yet, there was no real data to work with. Instead of jumping into development, Element 84 used discovery to step back.

The key takeaway was that the team didn’t actually need infrastructure yet, they needed to understand their future users.

Dan explained: “We helped them create synthetic products to understand how customers wanted to use the data… before instruments were even on orbit.”

Discovery revealed:

• What workflows mattered to customers
• How data would be used downstream
• Which components needed to be custom, and which didn’t

The same pattern shows up often. Teams think they “just need a STAC catalog,” but as Dan put it: “It’s tempting to think that way, but the space is much bigger.”

This case study shows how discovery prevents premature building, and keeps teams focused on solving the right problem.

Conclusion: Build Smart, Not Hard

After speaking with Dan Pilone, one message stands out: good geospatial engineering isn’t about choosing ‘build’ or ‘buy’, it’s about understanding yourself first. Discovery gives teams the clarity to avoid the obvious wrong paths, see the real shape of their problem, and invest effort where it actually moves the needle.

As Dan put it, “There’s no one right answer. But there are certainly many wrong ones.”

In a landscape where AI is accelerating expectations, data volumes are exploding, and every organization sits somewhere else on the build–buy spectrum, discovery is what keeps decisions grounded.

Whether you ultimately build, buy, or blend the two, the goal remains the same: solve the right problem, at the right time, with the right level of investment.

That’s how teams build smarter, not harder.

To learn more about natural language geocoding and Element 84’s approach to the discovery process, you can reach their team directly here. 

Liked what you read?

Subscribe to our monthly newsletter to receive the latest blogs, news and updates.

Join the Community