Since 2015, Plaid has helped developers connect users to banking information using an SDK (software development kit) called Plaid Link. As Plaid describes it in its SDK documentation, “The Plaid Link SDK is a quick and secure way to link bank accounts to Plaid in your … app.” Up until recently, the catch was that each time developers updated their application, they had to manually apply their changes across all of their platforms, whether Android, iOS or web.
Last year, the company decided there had to be a better, more user-friendly way and began releasing an overhauled version of the SDK to parts of its user base, beginning in February, that enabled developers to update once and apply it across the various supported application development platforms.
It took a go-slow approach because even though the changes were designed to improve the developer experience, they were significant enough that they wanted to be sure they weren’t breaking anything before they rolled them out to the entire user base. This kind of rolling release is common among developers, especially when they’ve made substantial changes.
Even as this SDK overhaul was going on, the company faced other challenges. In January 2020, Plaid announced it had been purchased by Visa for $5.3 billion, but the deal ran into insurmountable regulatory issues and was finally scuttled at the beginning of this year.
Today, as the company is shooting for 100% distribution of the updated Plaid Link, we spoke to Will Kiefer, principal engineer and architectural lead at the company, to discuss why his team went about overhauling the SDK and what startups can learn from Plaid’s journey.
Creating a simpler workflow
Kiefer says that the goal was to simplify developer interactions to make it easier for them to take advantage of updates to the SDK itself while simplifying updates for applications based on Plaid Link. That involved taking SDKs built for each environment — iOS, Android or the web — and combining them into a single portal.
This would not only help the developer users — it would also make life easier for Plaid, which would no longer have to update three separate tool sets. “The problem was that we had these three SDKs, and they had all the logic in them for these [three] user flows. So anytime we wanted to edit it, adjust it or create something new we had to, like our customers, go and update that [across all three SDKs],” Kiefer explained.
The company wanted to change that both for themselves and their users. The net effect of that was taking any burden off of the user and following a given workflow that would go into effect whenever it was needed. If you were an iOS developer, it would take you on that workflow automatically without having to explicitly bring up the iOS SDK, making sure it was up-to-date and then updating the application connecting to Plaid Link.
As Kiefer said, moving these operations to the back end in this fashion wasn’t particularly unusual. It’s something that Facebook, YouTube and Instagram have been doing for some time, but the difference here was that it was applying a novel data structure, which was connected to a graph database on the back end that would drive the correct workflow.
And because it was shifted in this way, Plaid could update the SDK without having the user download a new SDK to take advantage of each change, greatly simplifying the user experience and shifting it to what he calls “user flow as a service.”
“Our SDK for all these customers is just this little portal into our user flow as a service, so they don’t have to update it [manually.] They can be on their own schedule and can do their own thing and we can continually revise the experience without forcing everybody to update [the SDK] every time.”
Putting it all together
Kiefer offered an example: Say you have a payment app like Venmo and Plaid improves the search functionality in the SDK. Previously, you would have to download the SDK, then update it and recompile your program to get access to the new search feature.
“Say we figure out a way to make search better … when someone’s connecting their account, we can just launch that change on our back end, and you use Venmo in the morning … and now you have a better search experience. So there really is no involvement from a user or developer, and the SDK is just a little portal that [suddenly] connects to our [improved] search [tool],” he said.
Beyond the purely practical benefits of this new approach for Plaid and the developer users, there is also a data angle here because Plaid can see what’s happening in these user experience flows across all its customers. “We have all the data we need to know that a particular customer is not converting well or maybe they didn’t integrate our SDK correctly or maybe there’s some improvement we could make for this particular customer [based on this data].”
Plaid took this one step further by adding alerts based on the customer or the products they are using. “We have all these alerts now, and we can slice and dice the data of what’s happening in these flows all on our end, and be more proactive around doing fixes for the customers or finding things that are wrong earlier without customers having to tell us,” he said.
One of the advantages to all of this, and a lesson that other startups could take from this experience, is that even though they released it slowly, this revamped platform approach essentially gives the company a way to roll out other services in the future.
“The next wave of the suite of products we’re going to be launching in 2022 are essentially all built on this. So the platform [has been] done, even if we’re slowly approaching 100%, and that means that all the new features that our teams are developing are built fully on this [new platform],” Kiefer said.
Powered by WPeMatico
