Watch Roundtable: Build vs. Buy Ecommerce Middleware

Summary

View our roundtable with Flxpoint CEO and CTO, Travis Mariea and Matt Myers, accompanied by SKULabs Head of Product, Brent McAhren, as we discuss the dilemma of building vs buying ecommerce middleware.

We will be hitting on a variety of topics including the decision framework, reasons for building or buying, and alternatively, the risks of building or buying.

To stay updated on the latest articles, webinars, podcasts and feature releases, subscribe today!

Below, you can view a transcript of the webinar.

Austin Rose:

All right. We’re right here at 2:03, so let’s go ahead and get started guys. All the attendees, thanks for jumping on today. Really excited about this conversation. This is actually something we have internally a handful of times just with our internal staff and we hear from a lot of our network and audience that we talk to on a daily basis. And what today we’re going to be talking about is building versus buying in what we call ecommerce middleware.

Austin Rose:

So if you’re an ecommerce retailer and you’re in the dilemma of, “I need automation, I need integrations. I need a way to connect my systems and my partners. Should we outsource that to a third party company and go use a platform specific to my needs or should we build it in house and do everything ourselves if you have the dev team for it?” So, super excited about this conversation, today the panelists, we have Travis Mariea, he’s the CEO of Flxpoint, Matt Myers, our CTO of Flxpoint and Brent McAhren, head of product at SKULabs. Thanks guys for jumping on. And Travis, I’m going to start with you, there might be some people on here that aren’t familiar with Flxpoint. Why don’t you give us a quick little elevator pitch of what Flxpoint does.

Travis Mariea:

Yeah, sure. So Flxpoint is a retail operations platform really focused on those multi-channel sellers that have what we call distributed fulfillment, which is sourcing inventory from not only their own warehouse in some cases, but also drop ship vendors, 3PLs and kind of managing that complex order routing, inventory management, when you do have multiple sources of inventory. So we’re that central kind of order manage system. Some cases, some people might consider us their ERP, but really kind of that central hub to route, optimize and automate your ecommerce operations.

Austin Rose:

Perfect, great way putting it and Brent, why don’t you give us a quick little overview of SKULabs?

Brent McAhren:

SKULabs is in a similar position, but we put a lot of emphasis on in-house fulfillment operations and management of the purchasing and other aspects of the warehouse operation and ecommerce operations primarily. There’s a big emphasis on standing as part of each of the processes. So you can maintain accuracy as you’re performing any of the tasks within the warehouse. And we’re integrated with a lot of sales channels out there, but I think we serve a different audience and together we serve an even better audience where we compliment each other’s platforms.

Travis Mariea:

Yeah. Certainly, and worth noting that, our integration Flxpoint-SKULabs really they do compliment that side of things where you have your own wear house, you leverage SKULabs for all that in-house warehouse management, barcode scanning, things like that. And our order routing when it comes to deciding, should it go into SKULabs as a warehouse order or should it go to a drop ship vendor, print on demand vendor, a different 3PL, whatever. So we found that that kind of relationship works really well, so excited to have you on.

Brent McAhren:

Yeah.

Austin Rose:

Exactly. All right, so let’s go ahead and jump in and let’s just talk real quick through what we’re going to be going over today. So obviously, first we’re going to start out with what the dilemma is. We’ll talk about exactly what is this question that we keep hearing and we keep talking about for building versus buying. We’ll talk about the decision framework, so what are the costs, the control, the connectivity and the maintenance of building and buying. There’s going to be differences in trade offs between the both. Really the meat of this conversation is going to be around the reasons and the risks. So reasons you want to build versus the reasons you want to buy. And then the risks of that you’re going to take if you want to build it yourself versus the risk you’re going to take with going on and buying from a third party platform.

Austin Rose:

So we’ll hit on those big parts as well. We’ll have some notable thoughts, final thoughts from the panelists at the end, and then open it up for some questions. If you guys want to ask us some questions, go ahead and jump on the live chatter, the Q and A, and we’ll be able to get to those as well. What’s going to be really good after this as well is we do have a build versus buy ultimate guide, has a couple things on there. Really just obviously the full guide of really good content behind this specific dilemma, as well as a comparison chart that’s free download, salary report, looking at what does it take to build a dev team and an ecommerce team to help with running your ecommerce business and a bunch of other really good value in that guide. So we’ll be providing that after this webinar as well.

Austin Rose:

So let’s go ahead and let’s jump at the beginning right at the top, what is the dilemma? So the dilemma is I am growing my company, whether I’m bringing on more people or sales volume is going up and I’m having this dilemma of, I either need a build or buy some type of automation or integration with my ecommerce systems or my fulfillment partners. I really need to start connecting things to make our processes not as manual. This could be really from all of these different value points here, so things for inventory and warehouse management, maybe need to automate your order management, maybe you just need a UI to do everything in.

Austin Rose:

And maybe you need to automate accounting, fulfillment integrations, your website integrations, maybe marketing, maybe customer service. There’s a whole bunch that comes into what you need for your business and your ecommerce business. And this is the dilemma that we hear from a lot of our audience in network. And Travis, I’m just going to start it off with you because I know you’re kind of boots on the ground talking to a certain prospects that come through, certain customers that we have on board. What are the questions? What is the dilemma? What are they asking themselves when it comes to this specific topic?

Travis Mariea:

Yeah, it’s really, how much should we rely on a third party versus what can we control in the house? And specific to ecommerce middleware, I mean, this gets brought up in just about any kind of business relationship, especially in technology specifically, when it comes to building software versus buying it, but even more so in the ecommerce middleware, we feel it’s really kind of more mission critical integration software that is makes it tougher to decide on. And the reason is because you’re connecting multiple systems together where that’s something that really has a high maintenance, high monitoring cost. That kind of goes along with it.

Travis Mariea:

I mean, the improving part that also is kind of factored in, that can apply across just about any technology, but when it comes to the maintenance and the monitoring, because it’s an integration software, a lot of our customers say, “Do I really want to one, build it and to keep building it? Because I want to integrate with multiple other vendors, channels, whatever it might be, but also do I want to have to monitor that, make sure it stays up, build a team around that and then just maintain that integration as it might change.” So typically this is around the vendor integrations, a retailer, a merchant who integrates with their multiple suppliers and needs to connect from a drop ship perspective, integrating their own warehouse, to like their ERP, it might be, integrating third party warehouses, which you obviously need to do a one time integration there in a lot of cases.

Travis Mariea:

So on that supply chain side, they’re really looking at those and on the channel side, looking at where are they selling? So they’re asking, “Should I go and build this new integration to this new marketplace or work with another company or find a platform that’s already built it for us when it comes to all their marketplace integrations like Amazon, Walmart, eBay, and then they’re platforms as well, Shopify, Magento, WooCommerce.” So kind of looking at those, seeing what’s prebuilt, what’s not prebuilt, but they might want to leverage a partner for is really what they’re asking on both that supply chain and sales channel side.

Austin Rose:

And Brent, from your perspective, obviously with your specific audience that you guys come and see, what’s the dilemma for you guys? Like what’s the conversation getting brought up in this regard?

Brent McAhren:

Yeah, so we talk with all sizes of businesses and I think there’s the smaller teams who maybe have… At a minimum for any choice of building, you have to have some form of development resources on your team. So for the teams that either have maybe a few developers and they’re maintaining their ecommerce site, it may seem like a good idea to try to build it in WooCommerce and I think there might be… I guess the best way to explain the dilemma is that it seems like your ecommerce platform might be the best place to maintain your operations. And it doesn’t take very long to find out, like we just heard about the engineering problems, the uptime, the maintenance of the integrations themselves.

Brent McAhren:

I’d say I’m sure you guys saw just as the same as us in the past two years, all of the changes within the ecommerce platforms, a lot of privacy oriented changes, technical overhauls that we haven’t seen in the past five years really, where people are trying to modernize their APIs, eBay, Amazon. I think that’s probably, that’s some of the appeal is that you think you can bring this into your ecommerce platform or, I mean, we also have the uptick in the platforms, what are those, like development platforms as a service where it feels like you can bring every thing into a table or a spreadsheet and integrate everything. And there’s a lot of nuances to order data and inventory data, kitting and bundling, I know is a big task for anybody who faces that. I could probably talk endlessly but I’ll probably leave it at that.

Austin Rose:

Yeah. I was about say, I think Matt will talk to you about the kitting and bundling fun part, but let’s jump into the decision framework and then I’m going to shoot it over to you Matt, on this part. And I’m going to go over the four key topics that we see when making a decision before you go into building versus buying. First one here, cost. What is the most efficient and cost effective solution for the team? That’s a huge question to ask yourself and you’re going to have to probably have a lot of people on your team to figure that out. Control, another big one, can you meet your company’s unique requirements or can the third party that you’re looking at, can that meet exactly with your requirements that you’re looking for for your business? Because, I mean, if you’re an ecommerce retailer, your requirements are so different compared to all the other ones, everybody’s got their specific use case or edge case.

Austin Rose:

Connectivity, what fits best in your tech stack? Not just from a integration standpoint, but from just a process point. And then the last one that people don’t even really talk about a lot, is the maintenance of it. Do you have the team to rely on, to help upkeep the system that you’re building? Does the company that you’re going forward with to buy a solution for, do they have the capabilities of maintaining their up and solution? So Matt, I want to jump over to you, what out these four stands out the most to you, one, two or three or all four of them that you can expand upon a little bit more?

Matt Myers:

Yeah. Yeah. I could do all of them, but just to kind of give a high level over these. I mean, when you’re thinking of cost, when you’re building, you’re thinking of the immediate cost of hiring new people potentially, or at least shifting existing resources over to this new project and endeavor. The long term maintenance of that fits into those costs as well. So you’re having people on staff to be able to support that long term, the actual infrastructure costs you, how are you running these servers and things like that along with just like the opportunity cost of not investing that time elsewhere is a big piece. So from the cost, I mean, it’s almost a no-brainer like if there is a prebuilt solution out there that can do what you need, the cost is almost like not even a factor most times, it’s usually cheaper to go with that prebuilt solution most times.

Matt Myers:

So definitely if it’s out there and it exists, that’s probably going to be your most efficient route. But maybe to kind of go into the control, maybe you have like a very, very simple use case, but you need like really highly compliance, you need a lot of compliance inside of that application or you have very specific like auditing requirements that you have to adhere to. And not every SaaS system is going to do that for example, that they might be hitting the top compliance things that you need to do, but not every tiny little micro certification. So with that, control if you need that or you maybe have a very nuanced flow and not many people in the market do it, there’s not a lot of products out there that supports that use case, control might be a big factor.

Matt Myers:

Connectivity kind of comes into play too if you think that you’re going to be expanding your connections, you have a lot of fulfillment sources, for example, or a lot of channel integrations, platform integrations, marketplaces, then connectivity is probably going to be… you want to look more towards the buy route because building that many connections adds to the maintenance and adds to the cost and so you want to be mindful of that. And the maintenance, I mean, there are other ones here too that, just very briefly like the flexibility of the future changes to your business model and your decisions, something like that could be added in.

Matt Myers:

If you’re building it, you definitely have flexibility, but you still have to invest that time and that cost to gain that. So there’s some other factors here they can figure in, but these are definitely four of the main ones I think, that you could kind of factor in. And to me, it kind of comes down to like, if there’s something out there that does what you need, then it’s almost guaranteed by it’s going to be cheaper, but when it comes to specifically the control, connectivity, if those needs aren’t met in that other platform, then at that point you might need to evaluate more of a build.

Travis Mariea:

Yeah. I think that’s a good point that it’s almost always a no brainer just to buy, if there’s something that fits all these other needs. I mean, you’re going to want to… basically, everyone’s out there to buy a product that does what they want and they’re only going to build if they don’t find the right product or partner. And if they can’t find that right product or partner, that’s when they start looking down the build path. And so no reason that you really would just start and be like, I’m not going to look, I don’t need it. I mean, you should always probably look, make sure before you start building something, there’s not something exactly what you’re looking for out there but there’s that kind of have that in their mentality, that I’m going to build this throughout the gate. They know that they need a high level of control. They know they’re going after the long term, as Matt kind of mentioned, they’re going after something that they want to be flexible, change, evolve.

Travis Mariea:

So it’s really one of those two things are both of those things. High level of control, they know they need that and it’s probably because, and it factors in that they want to go long term, have a lot of flexibility, all of that. And then lastly, because they really do truly believe that this, whatever they’re building, is a competitive advantage and they don’t want it just to be a commodity. So if there’s any one of those three things, and a lot of times it’s all those three things, at least the first two, then you go down that build path.

Travis Mariea:

But if you do feel like it’s something that you have… Well, let me put it that way, like if that’s really important to you, those three things, then there’s also the approach of like, you can buy something, but if it’s got an open API, and I think we might talk about it here in a little bit, but if there’s almost more like a hybrid, which we’re seeing more and more, you can take a prebuilt solution that is flexible, has an open API, make it proprietary to some extent based on what you’ve done with that platform, but still get the commodity type features of it that allow you to kind of move quicker and not waste time.

Travis Mariea:

And as Matt mentioned, the opportunity costs, not kind of throw the opportunity costs away on other projects. That’s really the ideal setup, is to find something that is almost like a hybrid build verse buy kind of scenario. You think about it just about everything as hybrid, unless you want to create the server that you’re going to be the product on. So you just got to figure out what level of flexibility and what pieces do you want to outsource along the way and giving and taking a little bit there is really kind of ideal.

Brent McAhren:

I agree there. We get a lot of people coming to us from the build, they’ve already made the decision to build. And just like you’re talking about a hybrid solution is what they come to us for and they see, “I see an open API, I see they’re integrated with Shopify, Amazon,” and I think one of the pieces under control here is not just your control, but you have to think about your marketplace’s control. Amazon and eBay, they don’t want you to even have your customer’s address, if they could help it, maybe in the future you won’t. Maybe you’ll just have a shipping label with a tracking number. But they want ultimate control of their customer data and they’ll go to great lengths to protect that. So the compliance side of it under their control and your requirements for that can be practically insurmountable for most companies. And you can see that in the Amazon seller forums.

Travis Mariea:

Yeah. Compliance is a good point. That’s because we had a glance over that earlier, but you’re right, that’s another… that should go in there with maintaining, monitoring, improving and compliance should be its own called out line item, for sure.

Austin Rose:

Yeah, definitely. And I think this is a good starting point. These are four pillars that we can expand upon. If you’re in this decision dilemma, like list these four out and start writing underneath like, “All right, what’s this different stuff, compliance, under control and everything like that.” So it’s a good framework here. You guys really specified exactly where we can start and I want to get into the meat of this on the reasons of building versus the reasons why we want to buy. I’ll start here on the left talking about reasons to build, so these people came in and they’re just like, “You know what, all these third parties ain’t working for me, let’s talk about the reasons why someone would build.” So obviously full control over data and security, they have full control. It’s their team’s baby that just built this.

Austin Rose:

They can build the specific specifications that they’re looking for. I think we’ve had a couple customers, that’s worked with a Flxpoint team where they just kept building on top of it and on top of it and on top of it, and it just got to a point that they couldn’t scale enough for what they were looking for, but you can be specific to what you want. And the last one is your code, your property. So Matt, I want to jump this over to you and I want to get your thoughts on why, I mean, why would anybody want to build something if maybe there’s a third party out there that could do even 70%, 60% of what they need?

Matt Myers:

Yeah. That’s a really loaded question, but to dive into some examples of maybe why somebody would want to kind of build. So one example is like built to your exact specifications, like whenever you integrate the new system, let’s take like BigCommerce and Shopify, like those are two different platforms out there, those platforms have different relationships and how they like do parents and variants, for example, like you can have a simple product in BigCommerce but that concept doesn’t exist in Shopify. Like those type of design decisions could really empower you in some ways. And that’s just a simple example, but there’s probably infinite numbers of those. Like in our system, we have purchase orders associated to orders, and that supports kind of like the drop ship model. Whereas if you just had kind of a purchase order as a standalone entity, it’s more of like the traditional kind of ecommerce model and like the warehouse management.

Matt Myers:

And so those type of decisions can really empower like potentially your use cases and what you do. And when you build something, you have full control over that, so you can match it through exactly what you’re doing, there’s not a lot of quirks and work arounds that you have to kind of implement to make something fit someone else’s model. So that’d be a great reason to build, that type of scenario. Security, same thing, maybe you want to implement let’s say some sort of certain vendor restriction or these layers, like in an ecommerce route, maybe you don’t want certain data to go somewhere, you don’t want certain people to have access to certain data. You can implement those controls on your own to a point where another platform may not be doing that by default.

Matt Myers:

And if those things are important enough to you, if they’re crucial, kind of like Travis said, if they’re giving you competitive advantage, or if they’re very crucial to kind of your inner workings of your business, those are all great reasons to build, those are the things that you should be looking to do. If those are not crucial, maybe they’re annoyances or they’re quirks that you have to work around, but they’re not crucial to your business, those are things where it’s like, “All right, maybe I can compensate on these factors and go more with a buy approach.”

Brent McAhren:

So on the build side, I would say overwhelmingly, it can be cheaper, I guess, if you’ve got some blinders on that you might not know you’re wearing. “Yeah, I’ve already got a developer, why would I spend any money on this? Let’s just build it on top of our Magento,” and then you don’t really realize it until six months that now that API changed a little bit, that’s broken. We kind of talked about that, but it is cheaper upfront, possibly, depending on the extent of what you’re trying to build it really. Yeah.

Brent McAhren:

Then it’s hard for us to admit that upfront because we only talk to… we hear from the masses who have experienced what happens when you go and build it, and you’re $500,000 in and now you’re thinking to yourself, “Well, what have I done? Maybe I should have just paid somebody a monthly subscription fee and then none of this would’ve happened.” And that’s a real story, they’re one of our longest certain customers, they couldn’t have been happier to switch after… and that was a hybrid solution, you’re building it yourself with a big consulting team, helping you onboard to an ERP and then you realize, “This is an ERP, this isn’t something that’s kind of successful as SKULabs are Flxpoint to my team.”

Travis Mariea:

You what’s funny is we always see, Brent, you mentioned this earlier, someone has tried to build it first. They always seem to start there, like if they have the developer and it seems cheaper in their head and don’t think about having to build features and monitor and all that kind of stuff, they always seem to build first and then they go and they buy and they’re like, “We already try to build this, it’s crazy, we don’t want to maintain anymore.” But it’s almost like, I think if you really do, if there is an argument to build, you probably should buy first, prove out that you’ve got that part of your business covered, at least the 80% of it, that you need done and then only if you see it really truly being a competitive advantage, then building on top of that.

Travis Mariea:

Whether it’s building it to the API or completely scrapping it or taking out pieces of it, I feel like because there’s definitely… I mean, we’re somewhat biased to some extent, but I do truly believe that we should win that build versus buy conversation nine and a half times out of 10, but in our customer segment, it makes a lot of sense and I can confidently say that. But you look at companies like Uber and how they built on Twilio’s API first. And then they end up going down the route and they actually pulled it back and they brought that in house because they saw enough of a competitive advantage, but they got up and running on Twilio. Still today, I think they use Google Maps as the back end and they never got to the point of where they want to tackle what Google maps has done, but they did with Twilio.

Travis Mariea:

So I think that approach can make sense and maybe expands across all size companies, but I could see that argument. And then also, I’m just thinking in general, we deal with mid-size companies, somewhere between 5 million GMV and 20 million GMV on average, I wonder if this is like a different co… that’s our spectrum, that’s what we understand. I wonder if there is a different conversation of these billion dollar companies where it probably makes them to build more and more just because they have the team that can move quicker, faster in most cases. So, I don’t know, it just, it’s something worth kind of just thinking about, I guess.

Matt Myers:

Yeah.

Brent McAhren:

Because what we see talking to them, I mean, they’re telling us that we don’t have the speed, we don’t have the capacity, let’s treat this business unit as its own independent operation and let’s not even connect it to our ERP because we already know that’s going to cost us $250,000. So they’ll come to smaller platforms and say, “This will maintain the operations of this warehouse and I can take some inputs and outputs from this system and connect those to the ERP to do some accounting,” to say, “Here’s what I sent in total, here’s what they’ve received in total.” And then not wire everything directly.

Travis Mariea:

Yeah.

Matt Myers:

Yeah, definitely makes sense. And I know it is interesting because you look at like Apple, they are following that same paradigm where they’ve historically bought processors from external vendors and like they’re slowly getting into this mode where they’re now making their own processors and putting those into max and that’s most likely saving them a substantial amount of money in the long term, probably not in the short term and it’s also giving them a massive competitive advantage for having these like great processors, great battery lives, no one can compete with them, it’s proprietary.

Matt Myers:

So there’s definitely like different factors and I imagine like at a certain level, building definitely makes sense when you’re doing millions or billions of transactions and you can shave off some sort of value off of every one of those. But I definitely think for like the medium size business, it’s more like, “I only have a finite amount of resources at my disposal right now and I need to find the best utilization of that,” and I do think most of the cases, that make sense to say like, “Let me just try something out first, maybe prototype it, see if it fits my use case and where the gaps might be and then from there make the assessment, like can I do a hybrid model to fill in those gaps or is this going to completely not work and I need to start with kind of a build approach.”

Travis Mariea:

Yeah.

Austin Rose:

Yeah. And I think that’s… I mean, you guys are given a good little transition over to why would somebody want to buy. So we’ll talk about the risks on both of these here in a second. We’ve already hit on a few of those, but economies of scale, implement a solution really quickly, you get an out of the box UI, fewer security risks, hopefully unexpected payoffs, there’s a lot of different payoffs you’ll get from working with the third party. Travis. I mean, you’re right here at the forefront of people buying ecommerce middleware, so what stands out to you out of these or is there anything on here that we didn’t talk about or isn’t on here that would be like the number one, number two, three reasons to buy rather than build?

Travis Mariea:

The number one to try to like, because you hit on them here, but then maybe to kind of rank them, to talk more about that. Typically, what I think, what I see, I mean, cost is up there, but I think time to market, you kind of hit on there, like just taking a Uber example, they didn’t want to go build out a whole phone dialing API, messaging API. So I just think time to market factors in greatly there and cost is kind of a given and it’s almost always cheaper, we kind of went back on that example, but technically, it can be cheaper in the long term, right over building. But I think time to market is huge. Validating the thing that you’re building or that you’re… the part of the business that you’re building, I know you’re buying it here, but that’s a big piece of it.

Travis Mariea:

So I think time to market factors in greatly, I think the team that goes with it that kind of should factor in, the platform that you’re buying, but the team should factor in too, where hopefully people are there that are asking you the questions that you didn’t think to ask, having that expertise is huge. So it’s software as a service and there’s almost always a service component in this world that we’re talking about, ecommerce middleware that comes with it. So there’s all of that. And then just like we kind of touched on earlier, just that out the box ready made solution that you know. Like you said, security risks and all that, which I’ll let, Brent and Matt probably know more about, but… Yeah, I think the time to market is a big one and be able to get it going and that’s why I kind of brought that analogy earlier of, get it up, build buy it then, and then only build once you feel it adds competitive advantage.

Austin Rose:

Yeah. Yeah. No, that makes a lot of sense. Matt, you got something?

Matt Myers:

Yeah. I’ll just briefly to touch on it. It’s a lot of work to build a system, whatever you’re building, whatever the scope of it is. And I just think buying is a lot easier and so time to market for sure, but just general complexity of how am I going to build system? It’s going to take a decent amount of time. There’s going to be a lot of decision making. There’s going to be a lot of potentially tech that you create in that process. So I definitely agree with Travis, like time to build or time to market. But in addition to that, just really like, it’s so much simpler to just buy something out of the box and build it, like why we in the wheel, your default option should generally be, find the best thing out there that fits your need and go with that. And only kind of stray from that path if you feel like it’s necessary to achieve success in your relative domain.

Travis Mariea:

The one thing I’ll say before we kick it over, I heard someone say it’s like money scales really well. I’ve heard someone say that and it like took me back and I was like, “What? Oh yeah, I guess that makes sense.” Like you can just… you can take money and apply it to a lot of different places and it can get you going very quickly. And it never changes on how well it works. It will work the same every time. When you go and build something, route the gate, you’re not sure if it’s going to be scalable, you’re not sure if it’s going to be repeatable, you have to are fresh and the hardest thing to do is start fresh on a blank canvas. But if you’ve got money and you can just buy up everything that you need to get done, that’s going to be applied repeatably every problem you run into.

Brent McAhren:

Yeah. I think I’m a pretty good reason to buy or a pretty good reason to build. If you want to become a software company, are you trying to run a software company or are you trying to run your business? It’s something I don’t think I shared prior to this call, but SKULabs was born out of very successful ecommerce business. They had accuracy problems, they had shipping problems, they were shipping the wrong product. Each time you ship the wrong product, that’s $50 round trip, so every mistake is costing you money. And their team was probably, I think they had five, six people shipping at the beginning. Then they came out with…

Brent McAhren:

They tried to solve the problem one at a time, started with, “If only we could scan, so let’s try to scan. Wouldn’t it be nice if we had inventory? Let’s let inventory.” By the time you know it, we realized that, or they realized… I joined a year or a year and a half in, that other people might be able to use the solution and that they were having major scaling issues, compliance issues, learning how to support a software product as well as keep it online. But yeah, unless you’re trying to start a software company, that’s a pretty good reason to buy.

Austin Rose:

That’s a good point. I mean, it’s a very good point. And how many times have we heard situations like that? I think, who is it? SellerActive, was the same way, I think we had a conversation with them that the original, they were an ecommerce company, turned into a software company. So really good important thing. And I kind of want to just echo what Travis said. I think the customer service part gets thrown by the wayside, it isn’t talked about. I mean, we even put it in here where when you buy a company, you buy a team, whether it’s a dev team or a customer service team, senior product specialists, contact and you’ve got people that work with hundreds of other retailers and they know all of the nuances that you’re going to need, whether it’s from a tech perspective or an operational perspective. So you’re not just buying the platform, you’re buying a team on top of that as well.

Travis Mariea:

Real quick, just the one thing, because you kind of brought up and made me think about it, just the concept of network effects in general. And you’re buying a team, the team behind it, but you’re also buying the knowledge and the experience of even the other customers that are connected into it, you’re competitors, it could be or whatever. But if somebody doesn’t work properly on their side, that team, as long as you’re buying behind a good team to identify as those things and a good product team to implement changes, you’re buying that network effect of, it happened to someone else before it ever happened to me. And so, especially in the integration world, that’s valuable. So it’s one of those things to think about that there is more power in numbers whether you’re it or not, someone else is making your life a little bit easier because their experiencing is something that you haven’t yet.

Austin Rose:

Yeah. Absolutely.

Brent McAhren:

Our platform should help you be proactive by default.

Travis Mariea:

Right. Yep.

Austin Rose:

Yeah, definitely. So good points there, now let’s talk about the risk. We’ve already hit it on a handful of these, for the risks of building and the risks of buying. There’s going to be risks to pretty much everything we do. Just going to start off here on the left, the risks for building. So just additional resources that is going to pop up in the development timeline, any unpredictable external factors. I mean, there’s so many moving parts that go into building software or building integrations, building automation that sometimes you don’t know about and they just pop up, new things in the market, things like that.

Austin Rose:

Affording tech debt. I think Matt could do a whole webinar on tech debt and we could do that, but it’s a big thing that people don’t think about. Brent will join in on that. And then building and maintaining a secure ecosystem. So again, a lot of moving parts and there can be a lot of risks involved with that. Brent, let’s start with, what jumps out of the gate for you on these risks for building, I know we’ve talked about a handful of different stuff, but what’s new that we haven’t quite talked about, that people should keep in mind?

Brent McAhren:

We really haven’t talked about technical debt. And as soon as I see it there, I’m not sure exactly who or is in our audience today, or maybe viewing the video later. But it really explaining what technical debt is is important to emphasize how much of an impact that can have on your organization. If you’ve ever lost an employee and then now you don’t know how to do, maybe they were submitting invoices for somebody and now you don’t know who to contact and how to send that invoice. And now you’ve spent half of your day trying to figure out something that they did in a minute or two.

Brent McAhren:

That’s a pretty basic example of what technical debt is. But imagine that on the scale of a software solution, where now you need a developer to really figure out why and how that was connected and depending on your developers that you had, or if you unfortunately outsourced it and now you don’t the original developers, finding out the answer to that, how did that work? It wasn’t designed in a way that was standards to comply or were they kind of winging it? You know those can be huge impacts and be catastrophic. And you may ultimately depend on this to the degree that you’re losing a significant amount of money every minute that’s down. So that’s a huge risk for building it yourself and technical debt cannot be understated. That it’s easy even for the best teams to implement technical debt even when they’re trying to avoid it.

Austin Rose:

Matt, what do you got on this?

Matt Myers:

Yeah. Completely agree. All that’s accurate. Technical debt is… I mean, just in general, like to me, I loot at this and I think of two things, like biggest risk to building to me is like scaling, like something’s always easy to do in a simple terminology and it always seems very simple up front. Maybe it is simple and then over time, the volume increases or the scope of that thing increases and that adds complex, it can add technical debt behind it as well. But when you’re building something, you are committing basically, is the best way I like to describe it. You’re committing to like the future change and the scaling concerns of that specific challenge. And so maybe today you only receive 10 orders a month and that solution’s great. And in a year or two, you’re receiving 500 orders a month and everything’s broken and because you’re not accounting for that, for example.

Matt Myers:

So something like that to me is one of the biggest risks, just like preparing for all the technical complexities that come with that build. Tech debt, yeah. Like making sure things are well documented, well coded. Brent kind of touched on something of like, you don’t know if they made something makeshift or if they did a really well job of kind of coding something, that’s a little bit of risk if you’re kind of a, just a business owner and you’re outsourcing and hiring somebody in and sometimes you don’t have that validation layer to really assure that things are done in a way that will be future proof. So there’s some risks there too as well.

Matt Myers:

Yeah, those are kind of the biggest ones that stand out to me. Definitely external factors, integrations are changing all the time. You’ve got to keep constantly keep up the day with those, definitely projects always take the longer than they’re estimated out to be. Those are just kind of common things in the software development world, whether it’s internal or a SaaS solution. And then security and just building an ecosystem in general, building something sophisticated enough where you can adapt to it and you can have an ecosystem around it, is also really challenging too. Like it’s easy enough to just build something point A to point B.

Austin Rose:

Yeah. And I think one thing too to keep in mind, I mean, you guys brought up a good point, so it’s the, what if that developer leaves that built this or that maintains this? One thing that we’ve seen and talked to about, a million times, is just the simple, “I need a website,” and someone goes out and they buy somebody to build them a website for it then to not be really anything they were looking for. And it’s that initial project scope, they’re not scoping the project correctly, they’re not outlining the exact requirements out of the gate and it’s just going to get off, started off on the wrong foot. And it’s just, that’s a huge risk to building is just not starting out in the right at gate and whatever the requirements. So a couple kind of notes there. Travis, anything on that or you want to jump over to the risk of buying?

Travis Mariea:

I think just a real quick, just to piggyback on a little bit. You’re right, people are the most expensive and unpredictable when it comes down to it. So that’s the biggest risk I think, or the most common risk you’re going to run into with building is people are expensive and most unpredictable when you compare it to a product or a company or an organization that you’re betting on versus a person. The other, but I think the biggest and the one that sets you back the most is kind of the unknown unknowns. I think there’s like… like Donald Rumsfeld is like famous for that, like talking about risk, like going into war where there’s known risks, there’s risks that we know we don’t know and then there’s the unknown unknowns, which we have no idea to even start to think about what potentially could happen.

Travis Mariea:

And that kind of goes back to what I was saying earlier about the value in the team of having people ask the questions that you never thought to ask. So I think that’s actually the biggest risk is the unknown unknowns, because they can set you back so far and they can cost you a lot of money. Hopefully you never run into one that big, but if you don’t even know what might show up, then that could really throw you into a tailspin when you’re just trying to [inaudible 00:41:35]. What looked like a simple project might turn into something extremely complex. But the most common one is just, you lose a developer, there wasn’t the right person, whatever it might be, and that happens very common and that sets you back.

Austin Rose:

Good point.

Brent McAhren:

And one last point, for larger companies, publicly traded companies, they’ve learned this as well. And I forget which one exactly it was, but they’ve come out with a new policy saying, “I don’t want anybody at our company building their own tool sets for things. If this isn’t going from the top down or at least integrated into the core of the business, we can’t.” We have a severe risk of these small tools and they may do something really simple, they may just look at the ecommerce store and then they set a status to pending or something while your company reviews it. And now your team is dependent on that software and you may forget it exists and now what? It’s more technical debt, but this is a big enough risk to any size company that it’s something that should really be considered before you get to build something.

Austin Rose:

Good point, good point. Let’s talk about the risk of buying because I think there’s another one that kind of goes in, hand in hand with what you’re saying there Brent. But the three that we put on here is the trust of the third party software. It’s a big thing, I mean, that’s one of the biggest, I feel like that I’ve seen in the past as well. The software addressing like the majority of your needs. Everybody doesn’t want to have a bunch of softwares that work and co-mingle together, they’d rather get as many consolidated as much as possible.

Austin Rose:

So very important thing to ask yourselves. And then the last thing is just the confidence in the company’s ability to weather market downturn. I mean like, are they confident in us, are they confident in Flxpoint and SKULabs if we have another pandemic or anything that just pops up in this ecosystem? So just one thing to note that I think those are three of our biggest risks that you’ll see. I think we have a few more on the guide. Travis, I’m going to kick this over to you, just as our last part talking about here is we’re running a little bit late on time, and then we’ll go to our final thoughts. Anything you want to expand upon on these risks of buying?

Travis Mariea:

Yeah. I’ll keep this really quick because I know we’ve kind of touched on it right from the intro, but I think one specific one that we’ve seen with competitors and just in our space in general is people get bought, our competitors, a lot of people have been bought recently, order management systems are getting snatched up with ecommerce booming. And there was one, a bigger one in our space that kind of goes after the top to your retailers that was bought by the biggest one in our space. And they basically said, “Well, all these contracts are now our new contracts and we’re going to change to our pricing.”

Travis Mariea:

And so we had a lot of customers come to us saying, we got to jump off system X because they got bought by system Y and it’s just crazy. It’s 10X the price now. So that comes down to, you can mitigate that risk by working in contracts and pricing pieces in the contract that you sign and sign more multi-year deals and stuff like that. But that’s one specific that I’ve seen in ecommerce middleware that customers should be wary about and should definitely factor in. And then yeah, that just factors into lack of control we talked about. But I think that’s the one point we hadn’t made yet that is very hits home for our place.

Brent McAhren:

Yeah. They’re lucky if they’re getting to keep the product at 10 times the price. A lot of these that we’ve seen are actually getting shut down or at least rolled into the parent company in a way that you can’t use it anymore effectively, they want to either keep it for themselves or reduce the cost by cutting it down to a very limited subset of their existing audience.

Austin Rose:

Yeah. Very good point. No, it’s a really good note there, good thing to kind of sound off on that last part of risks versus buying, but I want to go into final thoughts. I know there’s a lot to unpack here. I think this would be a good section for maybe some advice for retailers out there listening to this and what’s some things that maybe we didn’t hit on. Brent, I’m going to start with you. What’s some final thoughts on this?

Brent McAhren:

Yeah. I feel like I’ve touched on…I’ve hit almost all of my notes that I had here when I wrote down some thoughts before the meeting. Yeah, don’t make a quarter million dollar mistake.

Austin Rose:

That’s perfect right there. No, I love it-

Travis Mariea:

… woke up every day. That’s the first thing I think of every day I wake up that’s… I got that my mirror right there.

Austin Rose:

It’s actually the logo right behind Travis that says, “Don’t make-“

Travis Mariea:

Quarter million dollar mistake.

Austin Rose:

“… quarter million dollar.” What about you Travis?

Travis Mariea:

Yeah. I mean, we did touch on a lot. I think we touched on everything I had. The last thing I kind of would leave is, if you leave this webinar and you think you… you’re watching, recording or you’re here now, whatever, and like, “I’m still not really sure I could build verse buy. Let me look at each software and make a determination.” I think the best thing to do is just a checklist of what the pain points you have, the goals you have, however best feels to format it, but pain points, goals, things like that. And kind of look at what it solves today, what each software solves for you today. Find out the box, things that you want to aspire to do in the future and kind of leave those open and just have those at least documented and understand like, do I feel that this software will be able to do this for me in the future?

Travis Mariea:

Having kind of like a matrix there. And then make sure at one point in that checklist you kind of outlined, is this a competitive advantage or is this just a commodity? And then if you kind of put that matrix together and that list and you look across all these pieces of software, you’ll find one that will check most of the boxes, but I don’t think any will check all of them, or at least there’ll be question marks in that aspiring section. And then that will just help you kind of give you a framework to decide where you want to go. So if it’s a tough thing or tough decision, I would definitely outline in that format.

Austin Rose:

Yeah. Matt final thoughts.

Matt Myers:

Yeah. I mean, nail on the head for me too, it’s really about figuring out like what’s most important to you. What’s actually valuable and going to drive your business and kind of what you’re doing and then make sure that you look for those in platforms and see if that’s available and if not, then you kind of revert to the build. I mean, the biggest advice is just, in my opinion, it’s like don’t reinvent the wheel, kind of use this in this context, like try to go find something out there that fits, but acknowledge that maybe you have a nuance use case at times that doesn’t. And then to Brent and Travis’ point throughout this meeting is really like, see if there’s a hybrid model that you can incorporate into that and basically leverage what people have done and get that network effect and get all that existing benefit and then figure out what is the complex business specific use case that I need to, and how do I adapt into that? And what system best lets me do that. And then make a decision based off that.

Austin Rose:

Perfect. Well, thanks guys. We did have a few questions come through and I know we’ve got about eight minutes left so we can hit on maybe one or two of these. Let me grab one that I really like here and I’m going to direct this to you Travis, and obviously Brent and Matt, feel free to expand on this. Because I think this is somebody getting the build to the buying decision and it’s, how should I prepare myself for like a third party demo, for me to make sure that I’m making the best decision on buying rather than building? So what’s the best way to prepare yourself when you are about to make a buying decision, when you’re talking to the sales reps, getting on demos, things like that. So like how should somebody best be prepared for that?

Travis Mariea:

Yeah. I mean, I think that’s exactly what I was saying earlier. I think, just start with that list of pain points that you want to see demo would be good. I would definitely make sure to email the rep first. That’s definitely a piece of it, like here’s what I’d like to see. Whenever someone comes to us, we try to give them as much material ahead of the demo, because you don’t want to just get on and just see the same thing that everyone else gets shown you.

Travis Mariea:

You would prefer to get like a vanilla demo, get an idea of the platform. Here’s the five things I would love to see in the custom demo. Look through it, understand that, I think ask about things like SLA, ask about open API, all that kind of stuff. Because it goes back to what we were talking about, like trusting the control, not having much control, someone that’s put in an SLA has taken the time to say we trust. And when we back our technology, the open API shows we’re flexible, that we can help support your growth in the future and kind of be the flexibility there. So SLA, API, get an idea of the platform prior, write down your major pain points that you want to see and then send that prior to the rep and then have the demo.

Austin Rose:

Brent, any thoughts on that? Oh, sorry. Go ahead, Matt.

Matt Myers:

Yeah, just having a mental map of like, what do we do today really helps in those conversations and like being able to, do you process orders to this person and how do you do that? Do you send them an email? Do you drop an FTP file? Do you go to log into a portal and do that and how do you get orders from your sales channel? And even if you’re doing all this manually today, just understanding kind of where the pieces are at and how you can kind of connect them together really helps out on those demos when you have those platforms, because they can help take that info and engineer kind of how that might fit into their platform.

Travis Mariea:

Yeah. That’s good point.

Brent McAhren:

Yeah, that covers it pretty well. I would have the answer to the question, how do you create a purchase order ready? And you may have to ask several people, how do you decide which orders to fulfill today? Those are two great questions that’ll kind of see a lot of answers that you might find you have on hand. There’s no [crosstalk 00:51:50].

Austin Rose:

Yeah. Yeah. I would say too. I think one really important thing too, is the people that you get on that demo. It can’t just be the CEO. I think the CTO or the tech contact, maybe a developer, maybe the person that’s in it, the ecommerce manager or the website person. I think having the right person on those demos to ask the right questions. Or as Travis said, make sure you’re prepared with those questions before jumping in as well. Because I think with a lot of these demos, it’s very much solutions building, where we’re going through every single process and making sure that this fits what your pain points are. So that would be my thought there too.

Travis Mariea:

To your point, get it recorded. So you can actually [crosstalk 00:52:34].

Austin Rose:

Get it recorded.

Travis Mariea:

… and get more questions and then dive into a lot of these companies, I’m sure SKULabs does it like we do it. From the demo, you do like a solutions call to dig in more on the details. And so get it recorded, send it to teams, see what questions pop out of that. And then kind of to Matt’s point, if you can get a diagram together and you can provide a diagram, at least before that call if not before the demo, of what you do, that’s super helpful.

Austin Rose:

Yeah. All right. We got one minute and I can’t hit all of these questions or at least this one question, but I got this popped up twice and it’s super simple. Yes or no. Do you guys do custom integrations? So Brent, do SKULabs do custom integrations?

Brent McAhren:

Depending on the capacity, I would say last year and the year prior, have been kind of busy for that. A lot of integration maintenance that we’re doing so far is… as far as custom integrations, I think we have a pretty good XML and JSON format that we can interface with any store, similar to how we interact with all of our other channels. So it gives you a lot of the same power, support for order edits, that type of thing without having to have a direct integration, because I know there’s a lot of up and coming sales channels, Wish is… seems like everybody wanted Wish and now nobody wants Wish, it’s all over the place. So it’s hard for us to add support for every integration.

Austin Rose:

Yeah. Travis, or maybe I should ask Matt, do we do custom integrations?

Matt Myers:

Yeah. We do custom integrations and Brent’s complete spot on. There’s a ton of platforms out there and a ton of fulfillment sources too that integrate. Obviously, we don’t do all of them, but if it comes up then an integration needs to be done. We have that. We also have an open API spec. People can integrate to that. In Flxpoint, we also have kind of like dynamic file parsing utilities. So you can just feed us a file and basically any format with like a CSV or a header format and we can import that data. So you might not even need to go to that depth of a customer integration, but there are options out there available.

Austin Rose:

Got it.

Brent McAhren:

Yeah and to that point, Flxpoint can send orders into your SKULabs, so through a custom integration there, or maybe one of your vendors is sending you parts of their orders, who is also a Flxpoint customer. Those can find their way to your fulfillment operations platform.

Austin Rose:

Yeah, exactly. We integrate with SKULabs. So Flxpoint is an integration with SKULabs, works out perfectly. Both of us obviously have a handful of different integrations, different sales channels, different fulfillment options, warehouse management systems, accounting systems, things like that. So if you guys want to have any more information thrown your way, head over to our websites, Flxpoint.com. We don’t have an E in it, it is F-L-X-P-O-I-N-T.com and then SKULabs, S-K-U-L-A-B-S.com. Travis, Matt, Brent, thank you guys for jumping on. We’re coming right up here at the end of this round table. Appreciate everybody for jumping on and attendees, you guys will be getting the recording after this. We will be sending that out and uploading it to our different social accounts and onto our blog, providing over to Brent as well for your all’s audience and network. But other than that, if you guys have any more questions, head over to our websites and fill out a contact us form for us today. Thanks guys. I appreciate it and everybody have a good day.