Building on-chain has its barriers

Once you do “get it”, building is still cumbersome

Developers need tools to access, transform, and serve blockchain data end-to-end with flexibility and control

Enter sim.studio, a developer platform that abstracts the complexities of blockchain data processing, enabling users to build real-time applications that leverage on-chain data more easily

Exposing complete workflow oversight with a modular UI

Powered by proprietary data infrastructure that outperforms competitors by 10x

Enabling devs to build faster and focus on their business goals

With a product this complex, sometimes a real-world example is worth a thousand words. Check out a live example of how we built the modules on sim.explorer using a sim.studio canvas! Below is a step-by-step breakdown of how our product manager set it all up in under an hour—no backend developers needed (yes, really!). Pretty cool, right?

Outcomes since launch

Since its launch, sim.studio has been embraced from small teams to large enterprises. Its modular, scalable architecture simplifies workflows, boosts efficiency, and accelerates innovation in blockchain application development. With over 600 sign-ups and active production use by five organizations, sim.studio is transforming blockchain data processing, making it more accessible and high-performing.

Although still in its early stages, we’re steadily progressing toward our goal of converting developers and organizations into paying customers by delivering a reliable product. Multiple organizations have already found us organically and expressed interest in our paid offering.

Looking ahead, we’re expanding into multi-chain environments, enhancing off-chain data integration, and focusing on key metrics like retention and execution success rates to continually optimize the platform’s impact. We’re also working on delivering a streamlined version of Sim that, while not as feature-rich, covers the majority of everyday use cases—ideally without requiring any coding- for the everyday user.

…so how did we get here?

Understanding what developers are missing

Since we were building an entirely new and fairly niche developer tool, we made a deliberate choice: start by creating something that our power users would truly value, then scale back for broader adoption.

Through conversations with these developers, their challenges became clear. First, they struggled with contextualizing their complex workflows. Second, the sheer overhead of managing infrastructure and multiple vendors was overwhelming.

Examining concrete cases

One of the most exciting things about working in this space is how vast and undefined it is. The possibilities for solving challenges—like helping developers build on top of blockchains—are nearly limitless. The question is: where do you even begin?

We started by diving into real-world use cases, both from our own interests and from conversations with others. We mapped out the requirements for each one and how we’d think about solving it knowing what we know about our backend. What components were essential? Was there a clear order of operations? Did an order of operations even need to exist?

Rethinking how developers build

We replaced cumbersome YAML/JSON setups with a UI-first approach, streamlining onboarding and abstracting iEVM interfaces for seamless updates. As the product evolved, we shifted from a linear workflow to a Directed Acyclic Graph (DAG) model, inspired by Yahoo Pipes, enabling flexible, iterative workflows with multiple-to-multiple connections. This pivotal change improved handling of complex use cases, clarified dependencies, and allowed users to fluidly switch between building pipelines, writing logic, and querying data.

Understanding component relationships

When we expanded to many-to-many connections, we had to set boundaries: which components to prioritize, how they interact, and when to constrain users. For instance, merging code and schema could simplify things but limit flexibility. Ultimately, we chose a decoupled approach, prioritizing flexibility for advanced use cases while constraining users only when necessary to accommodate unpredictable developer needs.

Determining visual efficiency

Building a highly technical product designed for others to create equally complex tools posed a unique challenge: how do we balance the use of code with a graphical interface (GUI)?

A key part of the process was deciding when code would offer more efficiency and when a visual interface would be more effective. Our goal was to create a seamless workflow that leveraged the strengths of both, depending on which added the most value. We initially leaned toward a mostly GUI-centric design. Most components are best represented visually, and adding code editing across the board didn’t seem to offer much extra benefit for power users, especially since one of our main goals was to reduce the need for excessive code. This approach aligned with our core design principle: streamline complexity without sacrificing power.

That being said, there were exceptions. For components like the EVM Lambda, where complexity was inevitable—and sometimes celebrated—we needed to provide users with the flexibility to work with their own code when feasible.

To manage that complexity, we introduced a hybrid approach, offering both a GUI and code editor. We also added a visual overview that sits on the canvas, giving users a clear view of key details for the lambda, helping to make the process more approachable without losing power.

Zooming out and in

Once we felt confident in the components we were introducing and how they interacted, our focus shifted to ensuring visual literacy between them. Our users are building their own dynamic, sometimes imperfect products on top of sim, so it became crucial to equip them with the right information to make informed decisions throughout their workflow.

We had to ask ourselves: What controls and levers do users need to see, and when? At what point in their process do users need more detailed insights versus high-level overviews? We realized it wasn’t just about offering the right tools, but about surfacing relevant information at the right moments—whether it’s guiding them through data transformation steps or flagging potential issues with their workflow.

This focus on visual literacy also extended to error handling and feedback. How do we help users troubleshoot in real time? By incorporating clear, actionable insights, users could identify where things went wrong and how to fix them, making their experience more efficient and empowering them to iterate on their products with confidence.

The design challenge(s)

The toughest design challenge with sim.studio was finding the right balance between power and approachability. On one hand, we needed to create a robust, production-grade tool that advanced engineering teams would trust and respect—our primary audience and future paying customers. On the other hand, it had to be approachable enough for crypto enthusiasts who wanted to build something simple, our secondary users who would help draw attention and buzz.

When a team reached the "aha" moment, it felt like unlocking superpowers: they were building faster applications faster, and with fewer resources. Our priority was to drastically reduce the time to “aha” moment. As a designer, the real challenge is reducing that time to "aha" and creating loyal users, rather than seeing early excitement fade because users don’t see long-term value. But getting there wasn’t easy—it took a lot of time and iteration (and still isn’t perfect).

Oftentimes, I found that designing a comfortable and intuitive experience for users really came down to some of the nitty gritty details of making interactions feel seamless, and giving users the right clues and indicators of what actions can or cannot be taken.

Deeper dive: The EVM Lambda

As I mentioned earlier, balancing simplicity and complexity was a recurring challenge throughout this project. Sometimes we got it right, and sometimes we didn’t. A great example of this is the evolution of the EVM Lambda component.

The EVM Lambda, our most powerful feature, functions as the command center, allowing users to set custom triggers, monitor key events, and run external code in response. But at one point, it also became our biggest drop-off point. Users were overwhelmed by the complexity, despite the flexibility it offered.

V1 Initial Thinking

In the first build, we focused heavily on giving power users the functionality they needed. They were able to filter down and add hooks, view their added hooks, and see their code all at once. While they could complete their flows, we noticed a high drop-off rate and constant requests for help. The issue? Initial designs exposed all options to help users orient themselves but often felt overwhelming, especially for new users.

V2 Iterating on early feedback

In the next iterations, we reevaluated focus, flow, and information hierarchy based on feedback we received from our alpha testers. The complexity of the actions coupled with the fact that it’s an entirely new paradigm in the space meant we needed more guard rails for users. Where was there area to improve? What was the right balance between focusing users and giving them flexibility? When do we integrate flows and when do we keep them searate?

V2 output

By centralizing all the "adds" in one place but created a more focused flow for the actual tasks. This not only reduced the visual clutter but also gave us room to provide more onboarding help and guidance. As a result, we saw a lower drop off rate and a higher rate of lambdas tested and executed

V2 Results + Next Steps

Our goal was to reduce the gap between the number of new lambda created without tests and even better, without executions. This indicates to us that users aren’t just creating components and then abandoning them because they don’t know what to do, but rather continuing to complete the flow (test their code and eventually execute it).

We still have work to do in making Lambda (and the product) more user-friendly without sacrificing its power. Our initial focus was on power users, as they provided the strongest signal early on. Now that we’ve equipped them with the tools they need to build their products, our attention shifts to everyday users.

A common challenge with building something so complex and modular is choice paralysis, where users feel uncertain about what to do next. Our next goal is to deliver a streamlined version of Sim that, while not as feature-rich, covers the majority of everyday use cases—ideally without requiring any coding. This will help us make the product truly accessible to everyone. Stay tuned!

V3 Extracting even further

After gathering data on the pain points in the Lambda flow, we identified a key challenge: users often struggled with the question, "What hooks do I add?" Since there were multiple ways to solve a single problem, the answer wasn’t always straightforward. We addressed this in two ways: first, by creating a more intuitive wizard with plain text and action-oriented filters to help users contextualize their flow; and second, by integrating our LLM to provide dynamic feedback and interactive guidance for selecting hooks tailored to specific use cases.