Why We Rebuilt InfraHub

Three months after launching InfraHub, we made a difficult decision: to completely rewrite it from scratch. Today, we are launching a new version of InfraHub. Today, InfraHub 2.0 is live. It is faster, more dependable, gives hosts a much better experience, and gives our team a foundation we can confidently build upon.

Why did we do this?

We built InfraHub to make accessing industrial machines easier.

The first version gave us an encouraging start. We finished sixth on Peerlist during launch week, and the response continued after the launch. Feedback from users and the experience of onboarding new vendors showed us where the product’s foundation was getting in the way.

We were not happy with the original host dashboard, and our tightly coupled architecture made new ideas and experiments unnecessarily difficult to build. And, we came to a realisation we probably overbuilt some of the features.

We are glad to say that we addressed the most important limitations of the original architecture. And the result was a faster, more dependable experience with a strong foundation for us to build upon.

Why a complete rewrite?

To be completely honest, the implementations we ended up on, particularly for our core InfraChat and notifications modules were not ideal and more complex than we ever estimated, and were held together by some third-party services. Some of the problems the first version had include:

1. Our architecture did not provide a straightforward path to real-time communication, so InfraChat depended on additional services such as Redis and Pusher.

2. Tightly coupled components made even small changes unnecessarily painful.

3. The lack of end-to-end type safety made development slower and more error-prone.

4. We had overbuilt parts of the product. Teams, for example, was deeply connected to other modules despite seeing limited use.

How we rebuilt it

We took this as an opportunity to reconsider every decision from first principles, starting from our tech stack to page structure, data flow, search visibility and the overall experience.

We chose TanStack Start for the frontend and Convex for the backend. We had already used TanStack Query extensively, and when TanStack Start entered RC, we knew we could seriously consider it. TanStack Start’s explicit approach to routing, data loading, and type safety felt like a natural fit. It gives us greater control over how the application behaves without introducing unnecessary magic.

Convex gave us a simpler path to real-time features and end-to-end type safety. It made connecting the frontend to our backend faster, reduced our reliance on additional services, and substantially lowered the product’s operational complexity.

What users will notice today

Users will notice improved machine and location pages, better discoverability, and a more reliable real-time experience.

For hosts, we completely redesigned the dashboard around a calendar-based slots interface. Creating availability and blocking individual slots is now much easier. Hosts managing multiple organizations can also switch between them more easily.

We also stopped forcing every host through the complexity of Teams. It is now enabled only where needed, and we will expand it in a focused future release when we can give it the experience it deserves.

A better foundation

This new foundation makes developing and shipping features dramatically easier. Each major module now has clearer boundaries, better reusability, and fewer moving pieces. We also made search visibility a first-class consideration throughout the product.

Existing accounts, organizations, machines, and listings have already been migrated, so users do not need to do anything.

Explore the new InfraHub and tell us if anything feels confusing. If you own machines and you would like to make them available through InfraHub, apply to become a host or email us at [email protected]. We usually respond within 24 hours.

This is a new foundation, not a finish line. Keep an eye on our changelog for what comes next.