Business case

Modernizing ArcGIS Experience Builder — the case for adoption

Why a portfolio of 19 client-first custom widgets is a faster, lower-risk path to modern ExB capabilities than custom development or new server infrastructure.

Prepared by: TMG / TechMaven Geospatial Audience: Esri buyers & GIS decision-makers Date: July 2026 Companion: Executive summary

1 Problem & current state

ArcGIS Experience Builder is the default web-GIS builder for Esri customers, but each time a team needs a capability that sits outside its box, the same pattern repeats:

  • Custom development per capability. Connecting ExB to DuckDB analytics, an Iceberg/Delta lakehouse, Kafka streams, STAC imagery, Apple IMDF, or AR typically means a bespoke build each time.
  • New server footprint. Most integrations demand middleware — a new service to host, secure, patch, monitor, and budget for, with the operational drag that implies.
  • Data-sovereignty friction. Server-side processing moves sensitive data out of the browser, complicating GDPR/HIPAA/SOC 2, air-gapped, and sovereign-data commitments.
  • Vendor lock-in & standards drift. Bespoke integrations rarely speak OGC/STAC/IMDF/CoT cleanly, so each one becomes a maintenance liability and a portability risk.

The cumulative cost is felt as slow time-to-capability: weeks-to-months of engineering for capabilities that are now table-stakes in the broader data ecosystem.

2 Proposed solution

Adopt a curated portfolio of 19 ExB custom widgets (17 available today, 2 on the roadmap) from TMG, organized into six capability areas. Two architectural decisions define the value:

  • Client-first compute. DuckDB-WASM, Assimp, FFmpeg, GDAL3, MapServer, and SpatiaLite — compiled to WebAssembly — do the processing in the browser. Most widgets need no backend.
  • Standards-first interfaces. OGC API Features, Mapbox Vector Tiles, STAC, IMDF, CoT, GTFS, Iceberg, and Delta keep data and services portable.

The portfolio is not a single product: teams adopt only the widgets that map to their use cases, and because all widgets share a common foundation and follow the standard ExB pattern, they compose cleanly inside one experience.

3 Market & timing

Several converging trends make the timing strong for this kind of portfolio:

  • Cloud-native geospatial is mainstream. Parquet, Iceberg, Delta, and COG on object storage are now the default for analytical and imagery data; STAC is the discovery standard.
  • In-browser analytics is production-ready. DuckDB-WASM and WebAssembly runtimes have crossed the performance threshold for real workloads on real datasets.
  • Data-sovereignty requirements are expanding. Government, healthcare, defense, and regulated industries increasingly require processing to stay client-side or on-prem.
  • Esri continues to open Experience Builder. The custom-widget extension model is mature and supported, making third-party widgets a viable procurement category rather than a hack.

Teams that standardize on a coherent widget portfolio now avoid accumulating bespoke integrations later.

4 Value & benefits

Benefit areaWhat you get
SpeedWeeks-to-months of custom development replaced with drop-in adoption; capabilities live in days.
Cost avoidanceNo new servers to host, secure, patch, or monitor for most widgets; reduced middleware sprawl.
Security & complianceSensitive data stays in the browser — supports GDPR/HIPAA/SOC 2, air-gapped, and sovereign-data postures.
PortabilityOpen standards (OGC, STAC, IMDF, CoT, GTFS, Iceberg, Delta) keep you off proprietary rails.
QualityProduction-hardened flagship (input validation, SQL-injection prevention, error boundaries, tests) — not prototype-grade.
Esri alignmentNative integration with FeatureServers, SceneView, Calcite/Jimu UI, ArcGIS Maps SDK — extends your existing investment.

5 Costs & investment

Costs fall into three categories. Exact figures depend on licensing tier and deployment; treat the ranges below as planning estimates to confirm during procurement.

Cost categoryDescriptionRelative magnitude
Widget licensing / supportPer-widget or portfolio licensing, optional commercial support and SLAs. Widget source is Apache-2.0 / MIT.Low–Medium (TBD with vendor)
Integration effortDeploying widgets into ExB, configuring data sources, training app authors. Lighter than custom dev.Low (days per widget)
Internal operationsFor most widgets, near-zero ongoing ops (no server). A few widgets (e.g., BigQuery & Sheets) include an optional Node.js backend.Very Low
Pricing. Exact pricing is set with TMG per engagement (enterprise and government licensing on request). See contact to request a quote.

6 ROI framing

Return is best framed as cost-and-time avoidance plus risk reduction, rather than a single payback number:

  • Avoided custom development: Each modern capability (analytics, lakehouse, real-time, indoor, AR, earth observation) that would otherwise be a bespoke build is a direct engineering-cost saving.
  • Avoided infrastructure: Eliminating one or more middleware servers saves hosting, security review, patching, and on-call cost — recurring, not one-time.
  • Reduced time-to-capability: Faster delivery of experiences to internal or public users, with the downstream business benefit of sooner adoption.
  • Risk reduction: Production hardening and standards-first interfaces lower security and lock-in risk versus bespoke code.
Illustrative comparison (one capability, e.g. cloud-lakehouse query in ExB):
PathBuild effortServer footprintTime to live
Custom buildWeeks–months of specialist devNew middleware serviceMonths
TMG widget adoptionDays of configurationNone (client-side)Days–weeks

Multiply across the 2–3 capabilities most relevant to your organization to estimate portfolio-level avoidance. These are directional comparisons, not a quoted ROI — confirm with your own build estimates during evaluation.

7 Risks & mitigations

RiskMitigation
Widget maturity varies across the portfolioAdopt the production-hardened widgets first (e.g. DuckDB Advanced Analytics); treat roadmap items (3D Buildings, LLM Chatbot) as future, not current, capability.
Browser compute limits on very large datasetsWidgets stream/filter (bbox, view extent, range requests); validate against your largest realistic datasets in the pilot.
Dependency on third-party services (e.g. Street View/Bing, TiTiler)Where relevant, widgets are configurable (custom TiTiler, custom STAC endpoints); Street View/Oblique uses public provider URLs and documents the constraint.
Vendor continuity / single sourcePermissive Apache-2.0 / MIT licensing means the widget source is yours to maintain; commercial support is additive, not a dependency.
Internal change managementWidgets follow the standard ExB pattern — minimal new tooling for existing ExB app authors.

8 Alternatives considered

AlternativeTrade-off
Custom in-house development per capabilityMaximum control, but highest cost, slowest time-to-capability, and full ops burden. Justified only for differentiating workflows.
Single-vendor proprietary platform swapAvoids some integration work but abandons the Esri investment and introduces lock-in — contrary to most organizations' strategy.
Do nothing / deferNo cost, but capability gap and integration debt continue to grow; competitors and peer agencies modernize faster.
Adopt TMG portfolio (recommended)Lowest combined cost, fastest time-to-capability, preserves Esri investment, open standards avoid lock-in.

9 Recommendation

Adopt the TMG widget portfolio for non-differentiating modern capabilities, and reserve in-house engineering for the workflows that are genuinely differentiating for your organization. Concretely:

  1. Map your top 2–3 use cases to the portfolio (analytics, lakehouse, real-time, indoor 3D, AR, earth observation).
  2. Run a 1–2 widget pilot against your data and an existing ExB app to validate fit, performance, and UX.
  3. Confirm licensing for your deployment model (cloud, Enterprise, air-gapped, sovereign).
  4. Expand adoption to the rest of the portfolio as additional use cases surface, treating the roadmap items as future scope.