Build dApps without hidden dependencies

Making smart choices when building your dApp

When you start building a dApp, you’ll have many choices about the services you use and the providers you work with. When it comes to RPC services, reliability and speed are usually top of mind. But dependencies are another critical factor that’s easy to overlook when you’re just getting started.

Let’s talk about what dependencies are, where to look for them, and how to ship dApps that will work with any infrastructure provider.

Understanding dependencies in dApp development

A dependency is created when your dApp only works with specific providers or third-party, closed-source software. 

For example, suppose your dApp reacts to specific on-chain events using webhooks. A webhook is an automated message sent from one service to another. You might use a webhook to notify your dApp when an event triggers.

While this approach saves you the work of setting up your own geyser stream, it introduces a dependency. You now rely on that external service to:

• Stay affordable
• Maintain the same quality of service
• Stay online indefinitely

If the quality of service degrades or goes offline, or if you want to switch to a different provider, you can’t easily migrate without rebuilding parts of your dApp. In an emergency, this lack of flexibility quickly becomes a problem.

Spotting hidden dependencies

Dependencies can come from the most unexpected places. They can appear when:

• You build on closed-source software
• You sign long-term contracts
• Your validator host doesn’t have strict key separation
• The ecosystem you build on has the majority of its stake on a single cloud service provider

Your product could also depend on other dApps. For example, if your dApp relies on an API from another closed-source dApp – one you can’t host yourself – you trust that team to host and maintain their service indefinitely.

These dependencies aren’t always obvious. Sometimes they’re well hidden and only reveal themselves when it’s too late. This can lead to a lot of frustration and a lot of extra effort to resolve the issue. You could face outages, performance issues, or even be forced to redesign parts of your application because something broke that’s out of your control.

How to avoid getting locked in by a dependency

Read your contracts and the terms & conditions of any provider you’ll rely on 

You won’t find any vendor lock-ins here, and if you ever see a “12-month contract,” it didn’t come from us. We want you to be our customer because we’re helping you build something amazing, not because you signed an agreement 10 months ago. A lot can happen in a year!

Choose to build with open source as much as possible

At Triton One, we believe that sharing knowledge and open-sourcing our products moves the entire ecosystem forward. Solana itself is open source. Anyone can read, contribute to, and build on its code.

Open source reduces dependencies because it ensures:

• Anyone can run the software we use for our services
• The source code is publicly available for review and improvement
• Customers can host the software themselves or ask competitors to run it

The best advice on this topic that I can give any starting team, in any stage of development, is to ask yourself at every step:

What happens if this service no longer works or disappears?

If no other providers can provide the exact same service, if you’re locked into a long-term contract, or if you can’t host it yourself, it’s worth reconsidering that dependency.

By taking dependencies seriously from day one, you’ll build a more resilient dApp that can survive changes in pricing, availability, and provider reliability. In the long run, avoiding unnecessary dependencies can save you time, effort, and frustration.