Vision ESG, deciding what not to build

The portfolio page frames Vision ESG’s key decision simply: “the call that mattered most wasn’t the tech stack, it was deciding what not to build in version one.” This piece expands on what that call actually involved.

Vision ESG needed to handle complex environmental, social, and governance datasets, with real-time tracking and reporting, for an audience ranging from ESG specialists to people encountering the discipline for the first time. The instinct on a brief like that is to build toward completeness: cover every dataset type, every report format, every visualization option a specialist might eventually want. That instinct is exactly what would have delayed the platform past the point of being useful to anyone.

Starting from the loop, not the feature list. Before any screen got designed, we asked the same question we ask on every project: what's the one thing a user does here that the whole platform exists to support? For Vision ESG, that loop was narrow and specific: pull in current ESG data, see it represented clearly enough to act on, generate a report that holds up when someone else reads it. Everything else on the original brief, and there was a lot else, got tested against whether it served that loop directly or just made it nicer.

What we actually built first. A dashboard covering the reporting flows and visualizations the client's own early users needed immediately, with the underlying architecture designed for scalability from day one, so the platform could grow into the fuller feature set without a rebuild, rather than trying to arrive there on launch day. Security and data integrity were treated as version-one requirements, not deferred, since a platform handling compliance-relevant data can't afford to bolt that on later. Everything else could wait; that couldn't.

What we deliberately held back. The more specialized visualization types and less common report configurations, ones that would matter to a smaller subset of expert users, went into a clearly scoped version-two list rather than getting built speculatively into version one. This wasn’t a case of quietly dropping features and hoping nobody noticed; each one went onto a document the client could see, with a stated reason it wasn’t in the first release.

Where the version-one line got drawn later than it should have. In practice, the scope crept a little before we committed to that line firmly, a handful of “nice to have, might as well build it now while we’re in there” additions crept into what should have stayed a tight first release. None of them broke anything. What they cost was time: time that delayed the point where real users could start telling us what actually mattered, versus what we’d assumed would.

The actual lesson, generalized. Cutting scope isn't the same as cutting ambition. Vision ESG's platform today handles the fuller feature set the original brief asked for, it just didn't try to arrive there on day one. The version-one line exists to get a real, working thing in front of real users faster, so the harder features get built against actual feedback instead of best guesses about what an expert user might eventually want.