"Build vs Buy" on Rails

Decision Making

Colin Loretz

"Build vs Buy" on Rails

by Colin Loretz

In the RailsConf 2022 talk titled "Build vs Buy" on Rails, Colin Loretz explores the increasingly complex decision faced by software teams when determining whether to build features in-house or use third-party services. The theme revolves around the idea that this decision isn't straightforward and requires careful consideration of various factors.

Key Points Discussed:

Conclusions and Takeaways:

The “Build vs Buy” decision is a nuanced one that depends on various organizational factors.
Prioritize building capabilities that are core to the business while leveraging third-party services for non-core functionalities.
Implementing a flexible, Rails-based solution not only improves integration speed but also aligns with team abilities, minimizing risks down the line.

00:00:14.480 Without overthinking it, I want you to raise your hand if you see the young lady in the photo. Now, raise your hand if you see the older woman in the photo. And finally, raise your hand if you don't see either woman or if you see something else. This is an illusion often referred to as an ambiguous figure. It helps illustrate the fact that people perceive things differently depending on various factors, such as their history or context. There are two different truths about this photo based on individual perspectives. Some people initially see the young woman, while others see the older woman. This concept is crucial when we approach and ponder problems, especially since most problems do not have just a single solution. In fact, some problems may even be unsolvable altogether. Instead, we encounter what we call polarities that we must manage rather than solve.

00:01:16.200 Today, we are going to focus on a polarity that many of you have likely encountered in your development careers. This is the question of whether we should build something from scratch or buy a solution. Today, we'll discuss how having Rails in our corner can help us make this decision more effectively compared to other tools or frameworks available. Welcome! My name is Colin Loretz, and I am a software engineer at a company called Orbit. We build software to assist product owners in managing and growing their communities, which involves a lot of third-party API integrations. My experience has primarily revolved around building and consuming APIs. Recently, I've been working with our team to explore how we can create integrations sustainably and provide our customers with more opportunities to import and export data within our service.

00:02:39.239 How many of you have had to make this kind of decision in your company or side projects? It seems like almost everyone has. The 'build versus buy' dilemma is a common topic in business classes and often arises during all-hands meetings or retrospectives. The core question is whether we should build something from scratch, find an off-the-shelf solution that meets our needs, or collaborate with one of the many Software as a Service (SaaS) companies that offer features like documentation, payments, or search capabilities. We should consider various options that lie between these two extremes.

00:03:39.239 For example, when it comes to payments, it's likely that you won't build your own system from the ground up due to the complexity involved. However, for documentation, you could either create a full documentation website yourself or use open-source tools like Swagger to host your documentation on various platforms. Similarly, there are many services available for webhook delivery, integrations, hosting infrastructure, logging, and more. By looking at this process through an 'yes, and...' lens borrowed from the world of improv, we find that we can often choose to do both, such as building certain aspects while buying others. In most cases, your tech team won't be able to build everything themselves, nor will they be able to buy every feature.

00:04:25.800 Sometimes it makes sense to build a feature, while other times it may be more practical to buy it. With integrations, you might want to pursue a combination of both approaches: building some features, buying others, and hiring consultancies to assist with complex integrations. This decision-making can be viewed as a continuum without a single definitive answer. Let's explore a use case related to this build versus buy decision, especially for integrations, before diving into the Rails-specific aspects. Initially, we had five core integrations built into our product, and we needed to consider how we would scale up to the next 15 or 20 integrations that we wanted to add to Orbit.

00:05:23.640 Our goal was to add new integrations sustainably, without burning out our team. Each new integration expands the scope of APIs that we need to monitor, the documentation we need to familiarize ourselves with, and the tools we need to build. This situation presents another polarity, one related to prioritizing the right integrations. When you’re working on a customer-facing product like we are, every client may request different integrations that they currently use in their tech stack. Therefore, how do we balance the decision about which integrations to prioritize and which ones to postpone?

00:06:13.380 Moreover, it's crucial to keep our code base straightforward. We must consider how to introduce new code, whether through building integrations ourselves or opting for purchased solutions, without ending up with a complex, tangled codebase that becomes difficult for new developers to navigate. Just as importantly, we need to ensure that the integrations we implement don't cause us to lose sleep at night. For anyone who has integrated with an API, you understand the worry of possible failures or downtime that could disrupt our services. Ensuring that our systems function as we expect is essential.

00:07:02.799 When embarking on the journey of building APIs, these considerations multiply quickly. Authentication, maintenance, potential changes in documentation, and other issues must be assessed for each integration we develop. As we begin outlining the features necessary for our integration as a service, we find that every integration necessitates comprehensive consideration to ensure it aligns with our operational standards. Therefore, it's essential to think critically about how we can reach decisions swiftly and effectively when considering integrations, whether building from scratch or buying ready-made solutions.

00:07:52.799 The first step is to collect inputs from the team. It's crucial to understand what previous experiences the team has had with building versus buying, and if there’s an inclination toward one route over the other. Have we bought something in the past that was successful, or did we encounter setbacks? This stage involves evaluating the 'DNA' of the team. Some teams suffer from 'Not Invented Here Syndrome,' resulting in a propensity to build everything from scratch, which can hinder flexibility in delivering practical solutions. Balancing the choice between building and buying effectively plays a significant role in our decision-making.

00:08:52.300 Discovery and research are also important. Understanding not only what your team has accomplished but also what others have done within your technology framework or industry can inform your decisions. It’s important to remember that just because you want to build a solution doesn’t mean you need to reinvent everything from scratch. A notable blog from a consultancy called Blended Edge offers valuable insights into integration considerations. They don't provide code but feature informative posts that delve into the many challenges of integrating with APIs, resonating well with anyone who has navigated this space.

00:09:59.700 We must also weigh the various trade-offs involved in the decision-making process. For instance, consider the size of your team: if you are the only developer and a co-founder, it may be unwise to attempt building everything in-house. This highlights how you can leverage third-party solutions. Additionally, consider the size and stage of your company. Understanding product-market fit is essential. If you are still gauging customer interest, it doesn’t make sense to spend countless hours crafting a perfect technology solution that may not receive traction from users. Instead, the focus should be on understanding the customer demand and quickly adapting as necessary.

00:10:40.620 The considerations continue: if you are bootstrapped, you might have more time than cash, while a funded startup might experience the opposite. A major red flag is when startups become overly reliant on an approach that could lead to constant pivots without validating product-market fit. Engineering culture and past experiences matter when deciding if we should build or buy. Have we been successful in shipping new Greenfield projects or are we better at incremental improvements by integrating third-party technologies? Alongside that, understanding technology risk—such as trying out new tools—is vital because you don't want to waste resources on unfamiliar technologies that might not align with your project.

00:11:34.800 Ultimately, we should also assess the costs involved. There are hard costs related to time and effort, as purchases often have financial implications while considering opportunity costs. If you allocate resources toward building one feature, it may take away time from working on other equally crucial projects. Key questions to ponder during this evaluation include: is this feature integral to what we offer our customers, or is it merely table stakes? For instance, while every company may need to send emails to customers, it might not be wise to reinvent that capability unless email communication is part of the core service.

00:12:17.520 What is our proficiency? What has been completed in the past, and what opportunities exist if we buy a service instead? It’s essential to gather perspectives from across the team—this process does not solely rest with engineers. Looking specifically at our experience, we leaned toward building because it allowed us to maintain full ownership of the customer experience and data flow. By doing so, we positioned ourselves to not only create the integrations we needed but also leverage our experience into future developments. This is similar to working out at the gym—building muscles that prepare us to take on more complex integration tasks efficiently.

00:13:59.220 Moreover, our prior experience from the first five integrations served as a significant advantage, giving us a valuable head start in our development process. Additionally, we are also exploring the idea of open API connectors that could benefit both us and other developers in the future. However, a strong pro—potentially a double-edged sword—is that having a dedicated integration team will result in better integrations. Conversely, if we lack the resources, time, or funding to maintain such a team, it could become a challenging aspect of our operational requirements.

00:14:33.540 On the downside, there are longer startups associated with building integrations, meaning potentially more code maintenance. We also face the risk of implementing new technologies. Therefore, organizations like Blended Edge emphasize the necessity of integrating a building culture into your organization. Building should not just mean doing everything, but it involves making strategic decisions about what precisely to build and ensuring your team is focused to succeed at those integrations.

00:15:14.460 When we discuss the buy side, we notice several advantages. Typically, platforms pride themselves on faster implementation and reduced resource demands, yielding appealing pros for consideration. However, we are aware of the challenges as integrations can often feel more like icebergs—appearing manageable on the surface, yet hiding complexities underneath. For example, as we looked into integration platforms as a service, we discovered opportunities that allowed us to utilize less code and maintain a broader connector library. However, drawbacks include potential hard-coded logic that may not fit specific business needs, leading to limitations. Pricing issues and vendor lock-in should also be assessed carefully.

00:16:27.799 Another critical red flag is that purchasing a solution requires the team to adapt to vendor-specific tooling or languages. Consequently, even if you’re leveraging a drag-and-drop interface to make programming seamless, it can quickly become niche. Finally, we should acknowledge that when you buy, you might rent capabilities instead of owning them. Similar to renting versus buying a home, renting may be more sensible for those frequently relocating, while buying might be advisable for stability.

00:17:05.640 Blended Edge encourages organizations to consider whether building a feature provides competitive advantage before proceeding with the buy option. Ultimately, reflecting on the entire business rationale surrounding whether to build or buy led our engineering team to concentrate on the established languages and frameworks we had in place. We made our decision having already established a robust process in Ruby, across our teams, which made it feasible to build integrations efficiently and effectively.

00:18:00.479 This work culminated in an internal project we named 'Constellation.' The aim behind Constellation is that it connects our API connectors seamlessly—allowing Orbit to communicate effectively with external services like Slack and Twitter. Utilizing pure Ruby as the primary coding structure allows us to enhance our integration capabilities. We now leverage Sidekiq Enterprise for job processing, enabling us to maintain compliance with rate limits placed by APIs we engage, ensuring stability and reliability across connected services.

00:19:03.679 Our processes involve creating ETL (Extract, Transform, Load) pipelines that facilitate smooth data transitions from our source systems and allow us to load this information effectively into our Orbit platform. The workflow uses the Kiba gem, which simplifies the construction of ETL pipelines through a declarative approach. At this juncture, we’ve integrated two new dependencies within Orbit, focused on maintaining our original simplicity intent along the way—ensuring that as we grow through the development of 10 additional integrations, we simplify rather than complicate our codebase.

00:20:04.260 For internal packaging and tooling, we leveraged Shopify's Packwerk, which elegantly allowed us to sequester all components specific to Constellation. This structure helps maintain clarity in our Orbit code base while organizing integrations effectively within their respective packages. We can define public and private methods easily while ensuring testing processes are intact. Testing Constellation enables us to assure the reliability of our API connectors, allowing regression checks and thus ensuring any changes within integrated APIs won’t disrupt our operational functionality.

00:21:02.940 An exciting outcome of our development is the creation of a Rails generator for Constellation. Generating the scaffolding for new integrations can now be accomplished through a single command. For example, we enter 'HubSpot' and set the key desired models and automatically generate all the scaffolding needed for a new developer to get started on that integration. This encapsulated understanding gives us a streamlined approach to onboarding new integrations, building on the techniques we have cultivated through developing our existing integration processes. In hindsight, this is a vital improvement that emphasizes leveraging established technologies.

00:22:06.660 Reflecting on our decision, we have made a substantial shift—going from zero integrations to five within the first year, and then adding five additional integrations in just the last month and a half. The rate at which we can integrate new systems is increasing, and despite this expansion, we remain committed to considering which integrations are genuinely necessary and beneficial. Just because we can build integrations more rapidly doesn't mean we should do so without thoughtful consideration of their viability and impact.

00:22:51.960 Our team has enthusiastically rallied around this common challenge, now unified by our commitment to solving integration issues. By strengthening our integration capabilities, we can confidently engage with new integration requests without the vague uncertainty that may have previously lingered. That confidence enables us to act rather than react. However, we must remain cognizant of the potential future challenges that might arise. If, six months from now, we determine we made a mistake in our approach, we need to assess pathways toward either integrating a buying component or realigning our focus.

00:23:43.260 In considering how to navigate future integration demands, keep in mind several factors. Whether it's documentation, payments, or other integrations, avoid spending 'innovation tokens' all in one place. Search for balance and choose technologies that are proven and predictable over shouting for excitement through new technologies every time. Opt for options with which your team is comfortable and adept—nothing should be surprising in Ruby. Designing clean interfaces is essential, as it allows integration as a service to scale up or down and seamlessly transition between built and bought functionalities.

00:24:45.240 By standing on the shoulders of giants, seek out available gems and technologies that have delivered results and reliability. Leveraging established frameworks rather than starting from scratch will bolster your project’s success rates. Lastly, don't forget that a hybrid 'Why not both?' strategy can benefit from gems that provide pro features. Utilize open-source innovations to build on top of existing foundations without the burden of coding everything in your system. This blend cultivates a robust approach for accomplishing complex integration functions while maximizing developer productivity.

00:25:43.440 We have about five minutes remaining for questions or any additional thoughts that bubble up as we conclude. As a good example to frame our inquiries, consider how often, with your experience, have we transitioned from 'build' to 'buy' or vice versa? Typically, small teams without significant funding can find value in the services provided. Startups often benefit from leveraging free credits and tutorials available in the industry, even though when the real world starts to engage, expenses may ramp up. However, opting to maintain a service may still be worthwhile even as costs emerge—running your own service incurs expenses, time, and necessitates skilled engineers.

00:26:38.880 Another vital consideration is team dynamics. If you end up relying on a third party, there is the risk of unpredictability if they face issues. Thus, it poses significant questions about how to manage customer expectations if those issues arise. This consideration should encompass the organization's appetite for risk and how errors or setbacks might be communicated while honoring service-level agreements with customers. Overall, it becomes a matter of identifying scenarios in which you can mitigate risk effectively through clear communication and collective understanding throughout the organization.

00:27:54.960 When discussing flags that indicate challenges between building and buying, note that it can be tempting to build due to the sound of cost savings. But it's essential to evaluate whether your engineering resources align efficiently with goals. In environments where projects may linger indefinitely, scope down your objectives to better focus on deliverables. Ensure your team emphasizes clarity around expectations, defined boundaries, and fosters a culture of execution where integration and discovery are prioritized. Make sure that risk is managed and approaching the 'build vs buy' conversation means not compromising on professional delivery.

00:28:49.920 Ultimately, recognizing the need for alignment between business goals and the technology team's aspirations can help bridge potential discord. Engineers often perceive building as the easier route, whereas business stakeholders might lean towards purchasing to minimize risk. Teams should engage in honest conversations around cost, risk, timelines, and try to find a shared vision. By doing so, they will cultivate a balanced approach that serves the needs of both sides of the table while enabling effective communication. As a result, consensus around whether to build or buy will streamline decision-making moving forward.

00:29:34.560 Thank you all for your engagement and for the insightful questions raised today. I hope our conversation provokes deeper conversations within your respective teams regarding how to navigate the build versus buy landscape. It has been a pleasure sharing our experiences, and I encourage you all to think creatively about future integration possibilities.

RailsConf 2022