[PM Talks] The "Build vs. Buy" Dilemma in Software Development

In a thought-provoking interview, we sat down with Eduardo Miller, VP of Engineering at Alliants, to discuss a topic crucial for many SaaS companies: build vs. buy. Eduardo shares his wealth of experience, weighing the factors that influence this important decision.

About Eduardo Miller:

• VP of Engineering at Alliants
• Over 25 years of experience as a software engineering manager and director
• Follow Eduardo Miller on Linkedin

Working as a VP of Engineering, how do you view the relationship between a product manager and an engineering manager?

Collaboration is key. Product managers play a very important role in product management and development, working closely with engineering managers. I feel there are two main scenarios we can typically observe. One is where the product manager has a strong technical background, perhaps coming from development. This qualifies them to make technical decisions, which can be very helpful.

Then, there are product managers who come from the business side—sales, pre-sales, or similar areas. These individuals have a clear understanding of the target market and how the product should work, as they know how users actually use the product.

These two elements—engineering and product—need to work side by side. Traditionally, we say that the product manager brings the 'why': why we need certain features and what needs to be done to get them in place. Meanwhile, the engineering team and engineering managers bring the 'how' and 'when': how to implement it and how long it will take.

In my experience, these two functions are really one—they need to collaborate and bring their combined influence to build a great product. For example, in companies that are engineering-focused, you may find a product that's high-performance and super reliable, but it may lack user-friendliness or feel like it’s trying to do too much. On the other hand, when a product is managed primarily by non-technical product managers, you often see excellent user interfaces and user experiences, but perhaps a lack of robustness or fluidity in certain tasks.

That’s why balance is needed. The 'why' is essential, and knowing what needs to be in the product is crucial, especially for developers who often work in relative isolation, focused on research and development. Product managers bring this market perspective, which is essential for creating a truly great product.

Traditionally, we say that the product manager brings the 'why': why we need certain features and what needs to be done to get them in place. Meanwhile, the engineering team and engineering managers bring the 'how' and 'when': how to implement it and how long it will take.

In your experience, have you worked more with technical product managers or those from non-technical backgrounds? If both, which collaboration did you prefer, and why?

I come from a background where I’ve held both roles over my career. I started at a time when product management wasn’t a defined role, so I did product management myself. After 25+ years of experience, I’ve found the best combination is a product manager from the business side—someone with a strong grasp of the target market, sales, and pre-sales processes, and an understanding of how to add value with each feature or improvement—working closely with a well-defined engineering manager.

I feel it’s crucial to have these different perspectives. When there’s too much technical focus, certain broader aspects can be overlooked. To me, the best product emerges when the product manager isn’t technical enough to make the engineering decisions but focuses instead on the areas engineers might not prioritize. That’s the ideal balance, in my view.

On the build-vs-buy note, what key factors do you consider when deciding whether to build a feature in-house or integrate a third-party solution?

There are many factors to consider with this approach, but I would start with the main two: economic factors and cost efficiency. You need to assess how much the feature or solution will cost and whether it aligns with your core business and skills.

For example, if you have a SaaS platform focused on hospitality, as we do, with a core business in concierge solutions—specifically concierge messaging and upselling—certain functionalities like automation and workflows aren’t core to our business. That’s why we chose to partner with Appmixer for that solution. Similarly, reporting isn’t our core business, so we use an outsourced reporting framework.

Payments are another example. Given the compliance and data security requirements, we opted for an external PCI-compliant solution, which saves us from having to maintain full PCI compliance in-house.

Additionally, outsourcing these non-core functions allows us to leverage advancements in those areas without investing time and resources to build those capabilities ourselves. For instance, every month, we can integrate new connectors and tools into our solution, enhancing the client experience without needing to develop those components in-house. This approach also lets us focus our time and energy on our core features, like concierge messaging and upselling.

When deciding between a third-party solution and building in-house, who typically has the final say? And what is the process for collaboration between you and the product manager in analyzing and determining the best approach?

The beauty of this collaboration is that there’s no final word; it’s a shared decision, reached by consensus, so we can move forward with execution. In practice, the product manager typically analyzes the solution from a cost, time-to-market, and value-add perspective—essentially, they bring the ‘why’ and ‘what’ we’re gaining from either building or buying a solution. They argue for buying from a business standpoint, focusing on added value and alignment with business goals.

On the other hand, the engineering manager validates technical factors like reliability, scalability, robustness, API standardization, and ease of troubleshooting. They also ensure compliance if any standards are involved, considering all technical aspects that make the choice viable from a technical perspective.

This approach makes the decision easier because each role brings their expertise—business from the product manager and technical insight from the engineering manager—so we can make a well-rounded choice that’s supported on both fronts.

Do you find that developers often lean toward building features in-house, thinking, ‘we can build it,’ while product managers tend to prioritize faster, cost-effective solutions with a shorter time to market? Would you agree with this tendency, and how do you navigate these differing perspectives?

I’ll give you the best short answer: It depends, my friend, it depends.

There’s no single right or wrong answer. Yes, developers often have a passion for building everything with the latest tools, which is why it’s essential to involve a non-technical product manager to maintain focus on priorities and make balanced choices. Developers, as you said, tend to focus on building, while product managers prioritize speed and efficiency.

The goal is to achieve a balance between product managers and engineering managers so that decisions are made collaboratively. Sometimes, even if you decide to buy a solution, it’s worth taking extra time to find the right one, rather than just any option. In our case, we evaluated several workflow solutions before choosing Appmixer, as it provided the reliability, confidence, and robustness we needed, along with flexibility, ease of learning, and the time-to-market advantage we sought.

Ultimately, there’s no single factor—it’s always about finding the right balance.

Can you share specific experiences where you and the product manager decided whether to build a solution in-house or use a third-party option? What were the biggest challenges?

I have experience in contact-centered markets as well, having worked for many years with software companies building suites for contact centers, including voice, video, and messaging. One instance I can recall is when we chose to build an in-house solution. In the contact center environment, you have inbound and outbound calls, the famous dialers, and even video calls.

We reached a point where we needed an algorithm to calculate the number of calls required to keep agents as busy as possible, minimizing idle time. Although some companies offered algorithms or scripting options, none could meet our market differentiation needs. We wanted to achieve a 2% idle time, while typical solutions only managed 5-10%, depending on the operational type (like telesales or debt collection).

Since we already had the necessary in-house skills, we decided to build a custom dialing algorithm using AI and machine learning for our specific model. This not only gave us a competitive edge but also added intellectual property to the company.

In the same company, we faced a different challenge with IVRs (interactive voice responses) and chatbots, used for services like 0800 numbers. Each client had different requirements, languages, and workflows. Building a tool to manage the dialogue flow for every client’s specific IVR or chatbot needs wasn’t part of our core business, so we opted to buy a solution that allowed for flexible dialogue flows. This decision prioritized time-to-market and let us focus on integrating with platforms like WeChat, Telegram, Facebook, and WhatsApp, which aligned with our business goals.

At Alliants, we chose Appmixer for automation flows for similar reasons. Building flows in-house wasn’t our core focus, and the time-to-market benefit was crucial. We refer to it as ‘drawing flows,’ given how user-friendly it is. Users can create their own scenarios by dragging and dropping components to build custom flows.

For example, different hotels can set up custom email flows post-check-in, tailored to each hotel's preferences. During the holiday season, they can use pre-set flows to send special information to guests. This flexibility and convenience add value, and the time-to-market advantage is phenomenal.

Could you share any specific results or examples of when these decisions went well—and perhaps when they didn’t? For instance, were there cases where you initially underestimated the development time, then switched to an existing solution and saw significant time savings?

Absolutely, I’ve seen many cases like that. One practical example comes to mind from a previous company in the contact center market. Reporting tools were a major topic, and the decision—made solely by the engineering manager—was to build a reporting tool from scratch. After two years, involving three developers (one backend and two frontend) working for over two and a half years, they ended up creating a very complex reporting tool. It was highly flexible but required a specialist to set up even simple reports.

After three years and significant investment, we discovered through usage tracking that only about 3% of users were actually using it. It was just too complicated to set up basic reports like pie charts or connect calls. Worse, this lack of user adoption created a problem for the company, as we were falling short in reporting functionality. They even had to assign a support person and a pre-sales team member to build reports for clients because the tool was so inaccessible.

Finally, the product manager raised the question: ‘Why are we building a reporting tool when our core business is contact centers? We connect people via voice, video, and messaging—reporting is important but not our primary focus.’ So, we explored alternatives, leveraging my experience with other frameworks. We identified three solutions and, within three months, replaced our complex tool with a purchased reporting solution that was far more advanced.

This new tool had drag-and-drop functionality, pre-made templates, and was white-labeled, allowing clients to build reports themselves easily. Adoption skyrocketed—over 60% of clients were actively creating reports. In hindsight, we could have solved the issue three years earlier by choosing a ready-made solution focused on reporting, instead of diverting resources from our core business.

In hindsight, we could have solved the issue three years earlier by choosing a ready-made solution focused on reporting, instead of diverting resources from our core business.

That's a great example! Have you experienced any other similar situations?

Sure, I have a recent example. At Alliants, we handle a lot of integrations, particularly with aggregating data from various property management systems for hotels, service order systems, spa systems, and so on. We bring everything into a single screen for the concierge, giving them a complete view of the guest.

Some integrations, however, fall outside our core business. For example, our white-label mobile app (which we brand according to the hotel) includes a service feature that allows guests to book transportation, like a car from the airport to the hotel. This integration is complex because it requires connecting with local car services across different countries—France, the UK, Slovakia, Poland, Norway, the US, and others. Building hundreds of integrations for various car companies would be costly and time-consuming, so we use Appmixer to handle this.

When a guest checks in, a flow detects the check-in, and if the guest has accepted the transportation offer, it automates the notification to the car service. The beauty of this setup is its flexibility: if the car company doesn’t have a system, the flow sends an SMS or WhatsApp message to the driver. For companies with an automated system, we simply replace the SMS component with an API call. The result is the same, but the integration adapts to each provider’s needs.

What’s more, these changes can be implemented in minutes as part of our deployment model. This decision to use Appmixer was based on factors we’ve discussed: it’s not our core business, it’s cost-effective, and it shortens time-to-market. The setup is simple, reusable, and doesn’t require specialized developers—our deployment team can simply add the components, and it all works seamlessly. This is a recent example where we chose to buy rather than build for automation needs.

Building hundreds of integrations for various car companies would be costly and time-consuming, so we use Appmixer to handle this.

Have you ever decided to buy a solution, only to later realize it would’ve been better to build it in-house?

Yes, this has happened. In the contact center, we once decided to buy a PBX (telephony) software that was lesser-known but closed-source, which introduced a vendor lock-in risk. For five or six years, everything went smoothly—until the vendor went out of business. Suddenly, we were left with a VoIP PBX solution from a company that no longer existed.

Long story short, we opted not to build from scratch but instead used a well-known, open-source PBX with API capabilities. We developed our own customized version integrated with our contact center solution. Although it required a significant investment, it became a key differentiator by integrating with our predictive dialing algorithm, adding unique value to our product.

This experience taught us the importance of carefully evaluating vendors to avoid lock-in risks that might later require costly pivots.

What other risks do you see with relying on external vendors beyond vendor lock-in, and how do you mitigate them?

Risks exist everywhere, right? The key is to manage them. In my example, we were in a time when we hadn’t fully considered those risks. Today, though, most solutions are SaaS, which is a significant advantage compared to 10-15 years ago. So, don’t assume there’s no risk—this is business, after all. The goal is to be committed, strategic, and proactive in managing and mitigating risks.

From a business perspective, start by doing your homework thoroughly and choosing your vendor wisely based on the right criteria, not personal connections. It’s essential to balance your decision and select the best product, not just the easiest choice. Also, I recommend opting for subscription models rather than one-time licenses. Subscriptions often include updates, which means you get advancements that help your company stay current.

Incorporating SaaS solutions, flexible contracts, and API-driven systems are advantageous, as they keep your options open. In our company, we currently operate hybrid environments, but prioritize API-first and flexible contract options. Managing the vendor relationship is also critical—maintain regular contact, keep an eye on their technological and financial status, and stay updated on any advancements.

For example, we learned the hard way when a vendor went out of business, and we didn’t realize it until a support request went unanswered. If possible, have a contingency plan to transition to another vendor if needed. In general, flexible contracts, API integration, and active relationship management are key to maintaining long-term business resilience.

In your experience, have you actually prepared for extreme scenarios where a vendor might fail? Have there been cases where you had a clear backup plan in place, knowing exactly what steps to take if things went wrong with a vendor?

That’s an interesting question. After learning the hard way from the PBX example I mentioned earlier, I haven’t faced another situation where a vendor went bust. We did have instances where a vendor was acquired by another company, which is quite common. In those cases, the transition to the new company was smooth, and our relationship with the vendor continued without disruption.

In scenarios like that, the vendor’s communication is essential. Being kept informed builds trust, which is crucial in any business relationship. Knowing about changes in advance allows us to prepare, rather than being caught off-guard. So, while I haven’t had to deal with a vendor going under since that initial experience, I would attribute that to both the lesson learned and a bit of luck.

When a third-party vendor you use is acquired, have services generally continued smoothly, or have you had to migrate due to shutdowns? Was communication typically sufficient to manage any transitions?

Usually, we’re informed in advance when a change is coming, or we receive a notification after an acquisition that services will continue as normal, often with a commitment to maintain them for several years. In my experience, acquisitions haven’t been problematic in 99% of cases, as it’s typically in the acquiring company’s interest to keep services running smoothly.

For instance, our reporting tool was originally developed by a Ukrainian company, which was later acquired by a Latvian firm. Some of the developers even transitioned to Latvia, and the product continued without issue for around seven years. Eventually, they offered a transition to a new version that combined elements from both companies’ products, but it was well-planned and smooth.

In general, transitions like these tend to be managed to keep clients on board. The situations I’ve encountered involved moving to equivalent or better products with ample time to adapt. Other than my initial experience, I haven’t seen downsides—it’s just a reality of business. It’s wise to prepare for such transitions, but they’re usually manageable and a standard part of the business environment. After all, even your own company might someday be acquired, putting you on the other side of this process.

Looking forward, how do you see the build-versus-buy decision evolving in SaaS? Do you anticipate a shift toward more custom builds, or do you think companies will lean more into deeper partnerships with third-party vendors, integrating microservices to create new solutions?

The software industry is still relatively young, starting around 1942 to 1950, so we’re less experienced compared to others. However, we’re reaching a maturity stage similar to industries like automotive and construction, where partnerships are essential.

Think of it like building a house—you hire a construction company, but they don’t make the bricks, windows, or frames; they source and assemble them. Similarly, automotive companies focus on their core areas—some prioritize engines, others design—while sourcing parts like seats, electronics, and dashboards from partners.

I see a similar path for the software industry as it matures. Companies will focus on their core competencies and source surrounding modules from trusted vendors. Already, we see SaaS products relying on outsourced infrastructure like servers and networking as the foundation. This trend will likely extend to non-core modules within software solutions, where businesses will buy what they need and integrate it.

So, the future looks like a hybrid model: companies will build their core modules while buying other components to round out their solutions, forming natural relationships with vendors. Open source could play a role, but it won’t cover everything. Ultimately, this hybrid approach will allow for more flexibility, added value, and robust solutions delivered as a service.

Closing remarks

In this engaging conversation, Eduardo Miller emphasizes the intricacies involved in the build vs. buy decision, highlighting the importance of collaboration, market efficiency, and strategic partnerships. He underscores the need for a balance between harnessing internal capabilities and leveraging external partnerships, always keeping in mind the core business objectives and cost efficiency. Each decision, nuanced by factors like time to market, technical expertise, and vendor reliability, plays a crucial role in shaping a company's strategic roadmap.

If you want to suggest questions and topics for our next episodes, feel free to share your ideas below!

You’ve just read an interview from our podcast, where we speak with product leaders who share their experiences. Follow us on Spotify or YouTube for more episodes.