It’s a tale as old as tech: Do I build it in-house or do I invest in a ready-made product? There are dozens of articles scattered around the web which can help you answer this question. But self-sovereign identity (SSI) is a unique market with unique requirements. Here we seek to provide a comprehensive analysis of the advantages of building versus buying.
The classic question
There is a single question that can go a very long way in helping determine whether you should build a solution in-house or buy a product to solve your need:
If you were developing a web app, you wouldn’t consider building your own RDBMS, front-end framework, or hosting service. Likewise, to add payments functionality, you would probably use a service from experts like Stripe in order to reliably process payments and ensure PCI compliance.
If you’re a bank, on the other hand, payments is probably your bread and butter. You’ll either partner with someone like Stripe for their expertise in API/cloud development or hire a team and build it all yourself.
Common build vs buy considerations
At face value, the decision to build or buy seems like a relatively straightforward one; how much will it cost you to build and maintain an in-house system, and what’s the sticker price for the ready-built solution? But there are non-obvious and often hard-to-quantify considerations that you need to make sure to fully consider.
Reasons to buy
Reasons to build
A ready-made product should work off the shelf. Some products work better than others…but in principle, this is true.
If you’re building something in-house and you run into a roadblock, where will you turn? Consultants? Expensive. Forums? Unreliable, slow. Figure it out? Expensive (because it’s slow). The support that comes with a product, especially in an industry as nascent as self-sovereign identity, is extremely valuable.
When a vendor makes an update to a product you’re using, you inherit those features effortlessly. The product improves itself over time because there is a dedicated team working on it. Because of the nature of economies of scale, this always results in a premium product.
Open source reference implementations are meant to be a reference but are not ultimately meant to be a scalable solution. If you use a vendor, you’ll likely need to pay them more money as you scale; so they’re incentivized to ensure their product is scalable!
It’ll always be lower-cost to buy than to build because the development costs of the product can be amortized across all their customers. If you build it in-house, you bear the brunt of 100% of the costs.
When you build the technology yourself, you have total ownership and control over the software. You’re not restricted by other software licenses, and you have full ability to change the codebase to accommodate your needs. You control where the data is hosted and don’t need to rely on legal agreements to control how it’s handled.
Although it will be much more expensive and time consuming to build in-house, your team will build up an expertise. If this expertise is strategically important for your organization, this is an important consideration. You’ll need to make sure to retain the knowledgeable employees, however; I’ve seen key employees leave and wipe out their company’s SSI knowledge base.
If your use case is uncommon or extraordinarily unique, you may be forced to build in-house. Ready-built platforms like Trinsic are built to accommodate all of the most common use cases, but there is a “long tail” of cases that aren’t economical for a vendor to cover. For these, you will likely need to go deep into the low level SDKs and build something custom.
Depending on the pricing model of the vendor you’re working with, it’s possible that it will be costlier at scale to use a vendor. For example, if a vendor charges per-issuance and your use case requires issuing millions of credentials, then you’ll either need to negotiate special pricing with the vendor or build your own solution to make it economical. This is rare, so it is a companion point to the “long-tail use case” point.
Traditionally, enterprises would build in-house to avoid being locked in to a specific software vendor. Luckily, SSI protocols are open source and based on standards which means that Trinsic can’t lock you in even if we wanted to! So the value of this point is reduced in the context of self-sovereign identity.
Self-sovereign identity is unique
In addition to the common considerations above, SSI has some unique properties that you should be aware of.
- Rapidly-moving space: The open source and standards work in the SSI community are moving at the speed of light. If you opt to build yourself, you’ll need at least two full-time engineers working solely on SSI just for your system to tread water; one to stay abreast of the evolving work going on at DIF, ToIP, Hyperledger, Sovrin, W3C, etc. and one to implement and maintain your software in response to those changes. You’ll bear 100% of the cost of these engineers. And the interoperability devil is in the details—with a vengeance.
- Identity is high-stakes: Many verifiable credentials use cases involve high-value, highly-regulated data. Identity breaches are costly, making key storage, wallet management (especially in the cloud), and other architectural considerations crucially important. Are you a world-class expert in securing these components? Even if you have the know-how, do you have the engineering capacity for the build-out and maintenance? Once it’s secured, how will it scale?
Self-sovereign identity is who we are. It’s what we eat, breathe, and sleep, so you don’t have to. Our expert engineering team ensures the most recent standards and protocols are implemented in our platform, so you never have to worry about interoperability or standards compliance. We spread the cost of these engineers across our hundreds of customers, meaning you get best-in-class solutions and maintenance for a fraction of the cost. Additionally, we’ve invested hundreds of thousands of dollars into our cloud platform with the best experts in the world for SSI security. We’ve learned the lessons and hit the roadblocks already so that you don’t have to.
Get the best of both worlds
Actually, you don’t need to ask a binary question like “build vs buy.” By buying a developer tool like the Trinsic platform, you avoid reinventing the wheel and get the peace of mind that comes with knowing experts have taken care of the hardest security problems and low-level protocols. This allows your development team the freedom to focus on what they’re best at: building the solutions that will add value to your organization.
With Trinsic’s fully-loaded package of 3 APIs, a front-end Studio, robust documentation, and SDKs in popular languages, your team is equipped with the flexibility and functionality needed to build something extraordinary.
- Trinsic Studio: An easy-to-use web interface for managing credential exchange with no code. Also serves as the mechanism to acquire API keys and manage billing for paid plans. Try it for yourself completely free, and issue a credential in less than 5 minutes!
- Provider API: Our newest API enables developers to programmatically provision issuer and verifier cloud agents. Learn more about the provider API in the recent launch announcement.
- Credentials API: Our core API enables developers to have a turnkey way to issue, verify, and manage verifiable credentials on any Hyperledger Indy network. Check out our documentation or one of our reference applications to get started.
- Wallet API: An API for creating and managing cloud wallets on behalf of credential holders. It’s the backend of our Mobile SDK, which you can read more about in our recent post about building your own SSI wallets. Get started with the API by checking out the documentation.
At Trinsic, we’re specialists in the standards and protocols that power verifiable credentials exchange. If you’re still unsure about whether building or buying is right for your organization, give our platform a try for free! Head to studio.trinsic.id and create an account. Use the API directly at docs.trinsic.id and, as always, please reach out if you have any questions.