Hex rewrites its analytics platform around code—and closes a $100 million round

Private beta, not a forced migration

Hex 4.0 is in private beta. The company’s October 27 technical introduction says broader access will roll out over subsequent weeks and existing projects will continue to work. That qualification belongs at the beginning of the story: this is an announced new architecture, not a claim that every customer can already use it or must immediately migrate.

Alongside the version announcement, Hex said it had closed a $100 million financing at a $1.2 billion valuation, identifying Peak XV and 137 Ventures as leading the round. The financing announcement provides the commercial context for a substantial rewrite. The product is best examined through its documented design changes, with vendor performance claims kept distinct from independent results.

The artefact becomes code

The technical introduction describes projects whose core logic and visualizations are backed by code files rather than a YAML specification. It also describes moving work between Hex and outside agents, including turning an external artefact into a Hex application and editing an existing project elsewhere. These are company-described capabilities, not workflows tested by Foundra.

The architectural distinction is between teaching an agent to operate a proprietary interface and giving it an artefact it can work on directly. A code file is more readily inspected and changed outside the original application. That can widen where analytical work happens without requiring the enterprise to endorse every tool as its only workspace.

Portability still leaves a semantic question. Two readable calculations can define the same business metric differently. Code exposes a definition; it does not resolve which definition the organization intends. The rewrite therefore changes the material teams can review, rather than eliminating the need for a shared understanding of the question.

Inspection moves into the application

Hex says the new interface lets a user inspect a displayed number’s logic and data sources, backed by a dependency graph. That is a more specific proposition than displaying an AI-written summary beside a chart. It aims to make the path to the result part of the product surface.

The introduction also describes the notebook as a collaboration surface for humans and agents. That shifts part of its purpose from authoring every line to navigating and reviewing generated work. It is a distinct design problem: an editor can be comfortable for writing code while offering little help to someone trying to understand code they did not write.

A dependency graph can answer where a number came from while leaving open whether the calculation is appropriate. A reviewer may find that the code ran correctly but used the wrong population or an unsuitable definition. The value of inspection is that the dispute can be located; a visible lineage should not be interpreted as a guarantee that every analytical choice is sound.

Execution is a second, separate redesign

The company describes parallel execution of independent queries, results appearing as their steps finish, and input changes rerunning only affected dependencies. Its claims of faster applications are vendor observations, not independently established benchmarks. No numerical performance gain is asserted here.

Those mechanisms address different sources of waiting. Parallelism can help when work does not depend on an earlier result. Streaming can make partial output available before the whole application finishes. Dependency-aware reruns can avoid repeating unaffected work. None means that every query becomes faster, especially when the bottleneck lies in an external data system.

For an interactive analysis, the distinction between total runtime and time to a useful result matters. A user may value seeing one relevant table earlier even if the complete application finishes at the same time. Conversely, a partial display can be confusing if its relationship to unfinished calculations is unclear. These are engineering implications of the described design, not measurements of Hex 4.0.

What changes first for an existing customer

The immediate boundary is access. With private beta and a forthcoming migration workflow, an existing customer has a period in which the old project and proposed new architecture must be understood separately. The useful next evidence is how a representative project moves across that boundary, preserving its definitions and making its dependencies inspectable. The rewrite’s interest lies in those concrete transitions—not in assuming an announced version is already a universal replacement.