One of the most common responses we hear in early conversations is simple:" We already have a developer we like.” It’s a fair statement. Long-term relationships matter. Trust matters. Past success matters. But when it comes to scaling onsite energy across a portfolio, loyalty alone is not a strategy.
There’s a reason buyers default to the developer they’ve worked with before. It reduces friction. It avoids restarting procurement conversations. It feels faster than running a competitive process. For a single project, that instinct often works. But portfolios behave differently than individual sites.
A developer that performs well on one building may not be the best fit across dozens of assets.
Developers are rarely opportunity-constrained. They’re execution-constrained. When portfolios scale, engagement quality can vary significantly.
Without competition, it’s difficult to know whether pricing reflects market conditions or internal benchmarks.
Over time, projects evolve. Assumptions change. Without standardized comparisons, it becomes harder to evaluate whether terms are improving — or eroding. None of this implies bad intent. It’s simply how markets behave without transparency.
Running a competitive process doesn’t mean abandoning trusted partners. In many cases, incumbent developers continue to win projects. The difference is that:
Competition strengthens good relationships. It doesn’t undermine them.
Institutional portfolios operate under increasing governance standards. LPs, boards, and procurement teams expect:
A single-vendor approach may feel efficient, but it often creates audit risk and internal skepticism. Structured competition turns procurement from a subjective choice into a defensible decision.
The real risk isn’t running a competitive process. It’s assuming one partner can optimize every site, every structure, and every market over time. Markets shift. Incentives change. Storage economics evolve. Regional dynamics vary. Without periodic competition, portfolios lose optionality.
In many portfolios, the story goes like this: A strong initial project gets built. The same developer is invited to replicate it elsewhere. Momentum slows. Economics vary. Internal confidence declines. When those same portfolios introduce structured competition:
The process creates leverage, not friction.
The question isn’t "Should we replace our developer?" It’s: “How do we ensure every project is market-validated and portfolio-optimized?”
Those are different questions, and only one of them scales. If you already have a developer relationship, that’s a great starting point. The next step is ensuring every project across your portfolio is competitive, transparent, and repeatable.