In the API economy, the decision to outsource or build and maintain software tools is more nuanced than ever. We recently talked to two tech leaders from top marketplaces. Bob Whitney is the Director of Engineering of Grailed, a peer-to-peer mens fashion marketplace, founded in 2013. Dan Davis is the former CTO (now advisor) of Madeira Madeira, the largest home improvement/home decor marketplace in Latin America, “the Wayfair of Brazil”.
Both Bob and Dan are hands-on tech leaders: building teams, coaching, and, of course, making tech stack decisions. Read on to learn about factors, pitfalls, and opportunities they consider when making software decisions.
Build or buy: it’s a point-of-time decision
Dan recalls a new hire coming into his previous company. It was 2009, they were large and profitable, so the first question the person asked was why they were not on AWS. One little fact they forgot? AWS did not exist when the company was founded in 2001. At that time, building was the only option. Ultimately, however, servers were not their business, which reinforced the never easy decision to switch over (aka buy). Dan’s overall position: understand your business and your core domain, and how it changes over time.
Bob agrees: staying focused on your core competency as a business is critical. All that matters is how quickly they can respond to competition and take a prominent position on the market: at different times, this may mean different decisions for your stack.
Questions to ask, nuances to consider
1. Is it adding a competitive advantage?
Because marketplaces are so competitive, Bob’s first consideration for every stack decision is whether it will add a competitive advantage.
Bob takes the example of managed hosting: not only doesn’t he want his existing team to spend time doing low-level optimizations on servers, but in order to build, he would need to find enough people with the right competencies at the right level; their salaries and maintaining the entire operation can get very expensive.
“Try not to get caught up and be the expert in every technical competency that’s out there, as attractive as that might be. It’s just not the way to build a winning business unless you’re Amazon.”
– Bob Whitney, Director of Engineering Grailed
2. Can my engineering team do this?
For Dan, a better question is: should my engineering team be doing this?
Talent is hard to get, specialized talent even harder. What is the feasibility of building it with an existing team? You certainly don’t want to do it for years and then find you haven’t done it well.
For Madeira Madeira, search is an incredibly important part of the stack. The marketplace is all about helping users find the right product; browsing and searching millions of products with ease is critical. Dan’s team must have the ability to optimize the customer experience when it comes to search and browse. However, optimizing how search indexes and scales at that level is not something he wants his team spending time on.
Bottom line: it is hard to build, deploy, and maintain at a level of sophistication that is demanded by customers today.
Bob puts the question this way:
“Is this something we really want to invest in, or are there people out there doing a much better job than we are and working full time on it?”
Bob Whitney, Director of Engineering, Grailed
For Dan, decisions revolve as much around happiness and enthusiasm of his engineering team as around other factors. The engineering mindset is often: “why have us if you are going to buy something”, and this is understandable: ultimately, it is his team that will have to support any product. To that effect, if you are buying:
3. Find partners, not vendors
The provider you are buying from has to feel like an extension of your team: when the system is down at 1 am, they need to be as invested as your own team in making sure you win. Dan’s advice: if you are buying software, look for a partner, not a vendor.
Adds Bob: when you decide to buy, small things matter. Can you reach the support team on Slack? Are they ready to go an extra mile to help you out? For a marketplace, staying on top of customer expectations is critical, which directly translates into being able to rely on any piece of software — and its team — 24/7.
4. To what extent can you control the experience?
Regardless of whether you build or buy, your team will want to be able to make relevant changes on their own — and without it taking days. The key is owning the experience, and keeping the control over what’s important. If you are buying software, you’ll want to know how the product is built and exposed.
To Dan, black box products are a no-go. He brings up the MACH Alliance philosophy because it encapsulates the right mindset: owning the customer experience doesn’t mean you have to build all parts of it, but it does mean you need to be able to stitch them together really well.
Dan wants full control of the user experience, today and tomorrow, so software choice depends on its flexibility: can it meet the current use case, but then also evolve? Tight integration with his data is key.
To that end, Bob and Dan call out good documentation and API-first products that they can plug into their stack and easily customize.
5. When comparing cost, think past year one
Looking at a yearly cost of a solution versus building it with open source internally will almost universally bias you towards building. However, things are never that simple. Says Dan: “When you add maintenance, and you add on the fact that you’re only getting into a V1, and not factoring the V2, V3 etc, the calculation becomes dramatically different.” Your team is now owning a product rather than a project, and the total cost of ownership is a whole new equation.
Bob advises asking yourself whether you are going to be doing what you want to do really, really well. It may take you a couple of iterations and, depending on what you’re building, a long time. This adds up really quickly, and you’re often invested a year in before realizing it wasn’t a great idea.
Buyer beware, though. Coming back full circle to the importance of his own team embracing the choices he makes, Dan looks at their ability to build on top of a product, customize it, and use it innovatively. You need to be sure that you’re also buying the product’s evolution and the ability to influence that.