There are many ubiquitous parts of modern web development, such as identity management, design systems, and internationalization, to name a few. When the time comes to implement these elements, there are many factors to consider:
- Should we build an internal solution or pay for a third-party offering?
- How do we decide which will best suit the needs of our customers, team and business?
- If these needs change, do we have a path forward, or will we be stuck with a brittle system?
In this write-up, I am focusing on paid offerings rather than open-source packages - a topic for another day.
Recently, we decided to migrate our tenancy management system from an “out-of-the-box” offering to a custom solution. We hope that by providing insight into this process, you can learn from our experience and plan a suitable roadmap for your needs, whether for tenancy management, or any other feature where third-party is a consideration.
Which solution is right for us?
To begin, let's discuss some of the pros and cons of using a third-party solution versus a custom implementation.
Third-party
The benefits of outsourcing work are self-evident - it is quick to get up and running, with pre-written documentation, a high-quality user interface, expert support for any issues encountered, and the confidence of using a tried-and-tested solution to your problems. These factors, taken holistically, make onboarding for team members outside of engineering simpler, too.
By way of example, consider the situation where the Product team, in charge of new feature planning and overseeing their development, wanted more control over when new functionality is made available on the application. In such a case a feature flagging platform, where aspects of the application can be enabled or disabled, would be needed. Using a third-party tool to manage these releases would be an undeniably smoother route to this than building it internally.
There are, however, inevitable drawbacks. For instance, the cost of solutions can be steep and, as these systems aren’t custom-built, compromises often must be made in picking one offering over another; frequently, you will need to mediate between the needs of your customers and preferences of the team, such as with the various functionalities offered by competing APIs. While finding an ad-hoc external package that will serve the immediate purpose can be a useful solution for the time being, any minor issues can become grating over time, especially with something like tenancy management, which team members will be interacting with regularly. Additionally, while having specialist external support for a third-party package is at first enticing, the asynchronous nature of this communication can leave the team blocked without a solution while awaiting a response, leaving you in somewhat of a middleman position. Speaking as a team of engineers, relinquishing this control and oversight of a system can be difficult as we like to keep a hands-on approach to resolving issues in our internal systems.
Custom implementation
On the other hand, we have a fully featured internal solution. This gives a lot of freedom to the engineering team, responsible for the development and upkeep of the software, and product teams, allowing for the feature to be as straightforward or as complex as desired, and for you to focus on the most significant ROI aspects for your team and applications. As requirements change, the solution can be modified to suit, including the option to build out from your initial package progressively.
This all sounds great in theory, but there is a reason for the success of third-party offerings. For smaller teams, the development costs of building your own solution can far exceed budgets, both in upfront time for coding and ongoing costs such as infrastructure, resource consumption, and maintenance. Additionally, it can be even harder to justify these costs to the broader business when these are often “solved problems” with well-known and popular offerings on the market.
Why would you, for example, invest in building your task management software when there are so many on the market that would cost a fraction of the time and resources to integrate? Ultimately, despite all the freedoms that a custom build provides, budget and convenience are often dealbreakers for a lot of organizations, especially for business-critical demands.
Is it either or?
Of course, there is a third option for many cases: a hybrid approach. At first glance, this can seem counterproductive. Why would you spend money on a third-party offering and then invest all the resources to develop your own functionality?
For one, many paid services have variable pricing depending on your requirements and you might be able to opt for a lower tier if you are willing to implement part of the solution yourself. This can mean a much shorter development time to implement your own unique requirements while offloading the more standard parts to a third party. Most large-scale offerings in the market have APIs to integrate with and documentation on how to do so, making for a relatively straightforward approach with room for creative liberties.
Indeed, this is how we now handle user management in KOPE, which will take up the remainder of this blog post. We offload the infamously intricate issue of identity management and authentication to a third-party, while handling our unique needs around tenancy membership, user roles and permissions ourselves.
Case study: Tenancy Management
In 2021, when we needed a way to manage our users, both our team and customer base were much smaller, meaning we couldn’t afford the time and resources to build a quality solution. As such, turning to a third-party solution made the most sense.
What we really liked about this was that it allowed KOPE team members other than those with detailed knowledge of the system (i.e. our developers) to be involved in platform management and configuration in these initial stages. This worked well for a time, but as our team grew and our business needs became more complex, we developed a clearer idea of our unique management needs.
While we could add additional information to users and tenants via metadata and custom login flows to support our unique needs, this had diminishing returns. At a certain point, the cost of finding workarounds to support advanced features and use cases, or the complexity of updating metadata for all users and tenants when refactoring related code in our applications, began to outweigh the advantages of offloading this work to an external solution.
Finally, in November 2023, we decided to take what we had learned and build our own solution. We decided that before the new year, we would aim to offboard tenancy management and implement internal infrastructure in its place. This was primarily a decision made for future robustness; developers were restricted in how they could tackle any user-related requirements as what had started as an easy-to-manage solution had grown so complex that meeting the accelerating feature requirements had become intimidating and uncertain. As a result, estimates for development efforts would get inflated, becoming prohibitively expensive.
So, we mapped out the flows in our current solution, our requirements, and what would need to be implemented to ensure a seamless change for our users; if we did our jobs right, no one would even notice that we had changed anything. This presented unique challenges to the team, like migrating all the user data out of the third-party system and providing a redirect during the login flow contingent on the user’s tenancy membership. With some hard work, we delivered on our promise of an improved experience for both our users and a level of confidence in our ability to handle future tenancy and user requirements.
Lessons learnt
First, let's recap why you might want to part ways with your third-party offering. Developer experience is a significant one. As workarounds and edge cases grow, a third-party solution can become bloated and complicated to work with. Additionally, there are future requirements to consider; if you know you will want to implement a user flow that isn’t feasible given your current solution, you need a plan to offboard.
For example, we wanted to support roles for two distinct types of user; tenant users, who belong to one organization and need to manage their own data and projects, and system users, such as KOPE employees who need to configure the platform itself. Our current system could not easily support this requirement, so the need for a migration became apparent.
If offboarding is the right decision, the next question becomes when. Ideally, you would pick a period with lower user activity and less expectation of feature delivery. Trying to transfer your system while planning to launch in a new market and expecting a massive surge of new signups is probably a recipe for disaster.
In our case, we waited until Christmas, when we didn’t have any urgent work in the pipeline and when fewer users would be dependent on the system in case of any problems. This took much of the pressure off and reduced the consequences if a rollback was necessary.
Finally, you need to consider how to offboard. Taking the time to map out your use cases, user flows, and general requirements is essential. During this stage, you can often identify details of the third-party offering that can be safely dropped as they haven’t been utilized and focus the spare resources on the features driving the migration. Creating a proof of concept is also invaluable. It can be hard to account for every contingency, even with thorough planning and discussions, so having something concrete to test, demonstrate, and iterate on, is invaluable. Finally, after you have a working solution, testing and retesting as much as resources will allow is essential. You do not want to proudly proclaim the success of your migration only to find that premium users can no longer log onto your system; the damage to customer and team trust is too risky.
As part of our migration, we wanted to simplify our login flow based on user feedback. Many of our users are only members of one tenant, which is to say they only need to manage the data of a single organization. However, these users were still asked to select their tenant during login. Instead, we wanted the login flow to take these users immediately to their tenant home page and skip this unnecessary step when possible. As such, we had two user flows to account for and test rather than the previous single case. Ensuring application changes do not break either of these flows can be easily overlooked, especially when it is a flow developers see less often, as they will tend to be a member of multiple tenants due to their testing needs. It was important to create plans for testing each path a customer might take, and setting up suitable dummy users and data for these flows. With this process driven approach, we were able to deliver an enhanced tenancy management system, with a simplified and robust login flow for users.
Summary
Offboarding from a third-party solution can be daunting, but with careful planning and rigorous testing, you can deliver something that will delight users, ease technical burdens for developers, and improve the overall functionality of your application and your team. As previously stated, this does not need to be an all-or-nothing approach, and offboarding incrementally, or choosing to implement only some of the third-party solution yourselves, can still provide massive benefits.
For ourselves at KOPE, initially going with a third-party solution for identity and tenancy management allowed us to focus on the highest value features for our users’ needs. As those needs, and our own understanding of our offering, has grown, we have transitioned to a custom tenancy management system, prioritizing a login flow we feel provides the best user experience, with substantial room for future growth in line with our business.
We hope by sharing the experiences of this process, others can also have a satisfying and stress-free experience when changing their approach on a third-party solution.
