Listen: Modern Merchant Podcast EP 3 – Tech Talk (Custom Development Work)

Below, you will find a transcript of the episode.

Austin:

Welcome to The Modern Merchant Podcast. I’m your host Austin, and coming at you with another episode today. Super excited about this one. I actually have a couple of teammates on the Flxpoint team joining us today. What we’re going to talk about is ecommerce integrations. A lot of this is going to go hand in hand with doing custom development work, as well as leveraging pre built integrations and just how all of that makes sense in the ecommerce realm. Again, I have my CTO of Flxpoint, Matt here, as well as my CEO of Flxpoint, Travis. Thanks guys for joining. I really appreciate it.

Matt:

Yeah. Thanks for having us all.

Travis:

Yeah. Appreciate you putting this together.

Austin:

Absolutely. Ready to get this started because I know, really from a consultant perspective and chatting on any really customer success manager conversations with current customers, integration talk always comes up. Really, one of the main things is, and that I’ve seen is the evaluation of using pre-built integrations as well as custom integrations, and just how we need to make all of these systems make sense together. Really, the first topic I want to get on is defining what an integration is, specifically for ecommerce. Matt, I’m sure you could probably give us a better understanding. What would you say is just a good, easy definition of ecommerce integration?

Matt:

Yeah, so it’s gonna vary, but basically, any way that you’re obtaining or sending over product data, order data, invoicing data, anything related to ecommerce. If you look at it from two different sides, you’re going to obtain this data from somewhere such as obtaining product data from a source or a fulfillment center, distributor, third party logistics company, a PIM, product information management system, and then you’re going to essentially want to push that data somewhere else. It’s just a way to help automate that process in a day and age where all this data lives in different areas.

Matt:

Finding a method to integrate, whether that’s via file, whether it’s an API integration, really any mechanism that you can do to obtain that data and pull it into a system and then use it somehow and then sync it up or push it to another system is what we’re talking about when we’re referencing ecommerce integrations.

Austin:

Yeah, absolutely. Really just keeping it simple is connecting systems to systems, or connecting some type of way of communicating with two different platforms, two different softwares, two different, maybe an ERP to a OMS. Really just moving data back and forth, which is obviously our bread and butter. That really goes hand in hand with custom development work and custom integrations, and that’s the bulk of what really we wanted to talk about today. One thing that we get all the time and customers always asking us questions is, should I go down the custom route? Should there be some type of custom development needing to be built here for this specific operation to work exactly with what I want with my system and my platform?

Austin:

Travis, I want to direct this one towards you, because I know you’ve been in the realm of evaluating custom integrations and really just understanding if this is going to make sense for that customer and what goes into play there. What would you say is the first thing a company should ask themselves if a custom integration should work? What should be their question that they should be asking their team? Like, should we do this or not? What should be the first topic that comes on to their mind?

Travis:

Yeah. The first thing you’re going to want to do is just evaluate the market. What’s out there that’s pre-built? Is there any alternative? Because the second you go on custom, custom anything, whether you’re talking about custom t-shirts or merchandise to integrations, it’s going to be more expensive than anything that’s pre-built, repeated and sold in a pre-built fashion. You definitely want to look at that and understand, okay, well, there’s nothing there that accomplishes our goal. Maybe it’s connecting to a supplier or it’s connecting two different systems together.

Travis:

Once you realize that there’s nothing pre-built out there that’s ready to go, that makes it a little more cost effective and maintainable for you. You got to look at what’s the actual value. What’s the value I’m getting out of this and what do we think we can get in return? Using connecting to a drop ship supplier, for one, it might be a need to have. This is a large supplier that is a big piece of your business. You need to make this connection happen. It’s a no brainer you need to do it. It’s not really hard to look at ROI on that, it’s not one that’s nice to have. It’s like, I need to integrate my CRM, but I can get by without it for a little bit.

Travis:

Definitely looking at what you’re going to get back in return. Then, digging into, what does it take after the fact? You’ll have to start looking at different vendors, and I think we’ll talk more about evaluating, but that is the next step, is really evaluating, okay, we need to have it. This is a big part of our business. It’s a big part of our strategy, our competitive advantage. We can do it. What’s the total cost of ownership of this integration? That’s a big thing to think about. It’s not just the integration that can hire a developer off Upwork. He can build a script that pulls out a file and uploads it to my Shopify store, and boom, we’re done. It costs me less than $1,000 to do that, but what’s the total cost of ownership of maintaining it?

Travis:

Are there more that are going to come later that you need to have this be a repeatable process. Really looking at that holistically and understanding your business strategy as a whole and how this is going to play in your businesses. It’s what you should do to step back first before you just go hire someone on Upwork to build an integration.

Austin:

Yeah. It comes down to the opportunity cost. It’s budget versus, how is this going to be effective for my business? Is it really going to automate things? Is it going to bring down labor costs? How many times did we hear people that are constantly manually placing orders throughout the day, hundreds of orders throughout the day, where, either a pre-built integration or custom integration or some type of platform can help you out there? I think it’s definitely, again, hand in hand with what you mentioned is opportunity cost on that.

Austin:

Whenever you get into evaluating, should we go with pre-built or custom integration work? Matt, what do you think like the first thing that they should do right out of the gate to start the evaluation process?

Matt:

Well, just to piggyback off of what Travis is saying, the idea of using a pre-built versus something custom, sometimes you may have 80% of what you need as well. You may have, I can import most of their data, but I can’t handle descriptions or attributes really well. A lot of those nitty gritty details are another part of that evaluation where it’s like, you need to think … let’s say I could get the 80% and maybe there’s a manual workaround for that 20%, is it worth going a custom route just because I can’t support this minor use case? Or is it worth finding workarounds to make that work?

Matt:

I just wanted to caveat that to where I’ve seen a lot of that, where most of the time pre-built connectors will work for the majority, but back to Travis’s point, if that minority of that functionality is strategic to your business, then you may have to evaluate a customer out at that point. As far as evaluating, really, you need to define what you’re really trying to achieve. It’s one of the biggest things that we see. Are you trying to import all product data? Are you trying to make sure you get orders? Are you trying to ensure that you have accurate invoice amounts?

Matt:

Do you have any sort of custom unique things in your business that someone else doesn’t? A good method that we use and that a lot of people really use is compare it to the pre-built. Look at a pre-built out there that maybe solves most of it and see where the gaps are, and leverage those gaps to determine, okay well this works, but it doesn’t do X, Y, and Z. That’s more my important thing. Out of this pre-built, maybe they offer these functionalities, but I really don’t even care about part of these functionalities they offer.

Matt:

The biggest step is defining really, with any development work, defining your requirements and understanding like what you’re really looking for and what would make that integration or that connection a success metric in your mind. I usually try to isolate that down to the need to have versus a nice to have. It would be nice to have this data, but at the end of the day, we have a workaround for that. Then, you can, when you get back in evaluation and it’s a line item out, in our case, when we quote our customers for these and we try to give them a breakdown of where the hours would be spent.

Matt:

You can evaluate, okay, is this requirement, or this component, this integration worth the extra effort and the money and the time to achieve it, or would I rather find a workaround? Break down the requirements, really find the gaps of what you’re looking for, define what your success metrics are, and then evaluate it against pre-builts and see what it would take for you to do it. To actually do it, obviously there’s companies out there that do custom integration work.

Matt:

You could go to someone like Upwork, or a website like Upwork and leverage that, but you also want to think about subject matter expertise. If you’re going to some random developer and they’ve never interacted with your platform that you’re dealing with, or any of the intricacies of that, you have to take that into consideration, or they may have maybe a large number of hours that they have to work to achieve something, maybe they miss some nuances that are kind of relevant to that platform. That’s the second step of evaluation. Try to find someone that’s really … knowing and understanding your use cases and the systems that you’re trying to connect together is an important aspect too.

Austin:

Yeah. It’s a pretty extensive process, I feel like, in the evaluation process, and you got to check all these different boxes. I really like what you said. Real quick too, is the need to have versus a nice to have, and I know Travis, you and I have talked about that all the time, is defining that need to have and nice to have as being one of the first steps of evaluating. But yeah, I definitely want to get your thoughts on that too.

Travis:

Well, Matt brings up a good point. I think if there’s anything to take away from this, we’re talking about specific ecommerce integration, it’s the business logic that goes into that and having domain expertise, or at least some background there is so important from whoever you hire, especially the more complex that your integration is. We talk about ecommerce integrations, just to step back to that, it’s typically syncing inventory and cost data on a lowest level. The skew has an inventory, quantity and it has a cost. Where does it stock from a warehouse perspective?

Travis:

Product data is a big piece in drop ship, getting product data from a distributor, if you’re drop shipping is a big piece. Not as much if you’re doing traditional wholesale retailing, but product data feeds are a big piece of that. So understanding the nuance that goes into getting images and pulling an image link or pulling from a Dropbox file and correlating that back to a skew number in an inventory feed or product data feed. There’s little nuance there, that if a developer just hires a guy that knows how to build something, he’s going to have to learn this for the first time, where ecommerce specific developers who know workflows won’t go through that learning curve.

Travis:

The order routing and the shipment tracking side of things, that’s huge. If you’ve never done that before, especially depending on how sophisticated integration is, are you bringing in multiple sources, are you just sending it to one actual supplier, or one platform, or is it multiple? All of those things factor in. The most basic level, just sending orders via email, sure, a developer can definitely figure that out, but if they’re not familiar with, okay, what do I need to send in this order that I’m sending via this integration, you’re going to have to over communicate more and more with that developer on what that should look like, so the work really kind of falls on you.

Travis:

Yeah, and to Matt’s point about the need to have and nice to have, if you can say, that really comes back to a question of ROI. If it’s an order routing integration, and you are currently having a full time employee doing that order routing, right? Manually grabbing an order from your order manager system, sending an email, attaching a CSV, whatever it might be, maybe mainly typing it into an ecommerce platform or their supplier, just as an example, manually grabbing tracking information, what could they be doing with their job if they’re not just simply hitting keys all day, to copy and paste over order information?

Travis:

Can they be doing things that aren’t getting done? Can they be driving the business? We have a quote from one of our customers who was doubling order volume during a certain quarter at the same time, was able to go from two people to one person managing their orders just because they implemented our system and we were able to automate that. You got to look at that, that might drive what’s a need to have as it goes, because, if it can help you grow your business, then it becomes very strategic. But yeah, I just wanted to hit on those.

Travis:

The last piece, just to wrap up on the evaluating side, knowing your workflows, knowing them so you can communicate to the developer, and leveraging, hopefully our developer does already have some background in your workflows is number one. Ideally, when you’re automating, try to replicate what you currently are doing manually and then improve it. A lot of people, to Matt’s point, talk about looking at custom dev in general and then how to evaluate the scope of it as a whole, try to keep the scope down to replicate what you’re doing manually and then improve it through the automation that you have. That’s typically the best. I would think, Matt, that from what you’ve seen from that approach.

Matt:

Yeah, Stuff [crosstalk 00:14:26] to get the manual. If you can take a lot of your manual interactions and automate those, that’s a great first step. We’ve seen that with a lot of our customers where we focus on that first and then we think of, okay, what’s the next evolution of that afterwards? But with that in mind, back to evaluating, there are two other things that really come into play and one of those is scaling. It is good to think about the longterm picture of your business and to think about like … I’ll provide an example. Imagine you’re selling a product from one distributor and you think in the future, you might expand to another distributor that sells those same types of products.

Matt:

If you build one to one integration between that distributor and your platform and then all of a sudden you would like to incorporate this other distributor in the future, now you’re going to have to come with this reconciliation process of, how do I ensure that I can make a decision on where do I even route that order? When Travis is talking about the order routing, it can get crazy as you start to scale your business. You’ve got to think about those long term requirements whenever you’re either looking at custom development or pre-built solutions around, like, is this going to allow me to expand my operations in the way that I see fit in the future?

Matt:

You may not have to solve those problems out the gate, but you should always think about them and you should at least ensure that the solution that you’re going towards long-term will account for that long-term scalability that you would need as you grow your business and expand maybe your automation or anything like that. That’s definitely important. I had another one, but to be honest, I’ve lost it, so we’ll come back to it if I think about it.

Travis:

Yeah. You touched on something that I think can be a whole another podcast. Also, we should talk about doing one of these in like a month or two about the build versus buy conversation. You’re basically bringing up like, you can build something really quickly, but you’re somewhat touching on, think about your business in a year, two years, five years, 10 years. Are you going to be continued to build on top of that, and what does that look like? Versus, can you buy something that gives you a foundation at least. A lot of the custom integration work we’re going to see, it’s custom for a reason. You need something custom to your business. Is there a platform like a Flxpoint or other ones out there that’s more of that foundational hub that you can build on top of?

Travis:

That’s a good thing. Also, I don’t know if we plan on talking about it in this, but custom integrations are fine. Having that foundation of logic and something you could build into an API rather than just kind of hacking something together for the first time out of thin air by someone you hired on Upwork, are two very different things. Having that core foundation, I think, is good, and you can still customize as you go. NetSuites and the Salesforces of the world known for being super customizable, I think that’s worth maybe discussing a little bit as well, and there’s a little bit of a difference there on those kinds of custom integrations versus just building something out of thin air.

Matt:

Sure.

Austin:

Well, I think, from our perspective and just being … I mean, this is our life. Every single day we’re talking the talk and we’re helping these businesses out. I think that building that foundation from the start, from the get go is 100% the first step of going. We had a customer, not too long ago that I was speaking with that only, over the past, it was like four to five years, they’ve spent millions of dollars on custom dev work for their own just custom system. They just started with the custom route right out of the gate and have just been building on top of it, like you guys have been talking about.

Austin:

Then it gets to a point where they start to realize, wow, we’re spending way too much money right now maintaining, having this dev team, keeping everything up-to-date and adding on more and more, why don’t we go with someone like Flxpoint, why don’t we go with another platform or some other software out there that’s going to save us so much money, and then we can leverage their team? I think we have some topics here. I think the order, I want to skip ahead to really what we’re talking about right now, because I think it’s very interesting to stay on this track is, the whole in-house dev work versus outsource dev work for custom integrations or ecommerce integrations.

Austin:

What’s the opportunity cost for in-house versus outsourced. Even outsourced, not just necessarily, I’m just going to outsource this dev team and I’m going to give them all my login credentials, and I’m going to tell them what to build, even leveraging someone like us, where we’re technically we’re the software that helped you out, but we have the dev team to do custom work because we have the experience. Matt, what’s your thoughts on that? I know you’ve got a lot probably going through your head right now.

Matt:

Yeah. Just going back to your previous comment around the customer that invested a lot of money in building their own kind of system for their needs. That’s a great in-house representation. If you want to be the next Shopify, you know how they started as an ecommerce company with surfboards and Canadian kind of ecommerce actual retailer, and then they evolved that into the platform, or like an Amazon, where you build the platform up and you spend a ton of technology and then you do Amazon web services.

Matt:

If you’re going for that play, that’s a great in-house leveraging of your resources. It’s also anything highly specific to your business. That’s a great reason for an in-house development team. If you know that this is your core business, and this is the value that you’re providing, that’s typically when we see people go in-house. Some examples of that could be, if you’re an affiliate network, or something like that, and you’re building that core affiliate software inside of there, and that’s a unique challenge that maybe someone else hasn’t solved and there’s not a platform out there to do that.

Matt:

Those are really good examples of when you would want to use in-house dev teams and expand that because they’re building things that are unique to your business, that are detrimental to your success, and almost, I think of it almost like proprietary. Those are things that you don’t envision other people having, or you don’t really … someone else is solving that problem. Outsourcing is really anything that is supplementary to your business. Where, it’s not my core business that I have an integration to this place. I know I need to submit orders to them, I need to automate that at some point, but there are many vendors and platforms out there that can help me achieve that.

Matt:

Really, that small component of my business, it’s not my core business, it’s just a necessary thing to … a means to the end. I generally, most of the time, it seems that retailers and brands and things like that are really more centered around focusing on the things that matter to their business, like branding their business, finding manufacturing partners that manufacture their products, finding good distributors, best pricing, understanding how they can warehouse products internally to reduce some of the costs and order in bulk.

Matt:

Those are more of their business-centric things of how they can offer, and obviously like marketing strategies, like social networking. Those are their core business … that’s the value that they provide. When you think about why you may go to a certain website and buy products off their website, it’s not because they have the best software most of the time, it’s because they have the best prices or they have the best product selection, or whatever it may be, and they’ve branded and they’ve curated their selection really well. Those are generally the things that most businesses focus on in the ecommerce space.

Matt:

You would really only really want to leverage in-house dev if you find that unique, proprietary thing that you can offer that you don’t see being possible by outsourcing it. It needs to be domain centric in your business.

Travis:

Has to be a competitive advantage, basically is what you’re saying. It’s a great point. If it’s not a competitive advantage, it’s just a commodity, it’s just anyone else. There’s this book about, I think it’s called The Big Switch. It’s a super old book about how technology is essentially just a commodity and that it’s not really a competitive advantage for most companies. There are some debate around that because it can be said that, Amazon, the reason they build AWS was to be able to run their ecommerce website as fast as possible and faster than anyone else on the web, which at that time, how quickly it ran was really competitive advantage, so they invested heavily in the AWS infrastructure to make sure that they have a quick checkout, conversions were high.

Travis:

It really was a competitive advantage. Now, they’ve basically said, okay, it is a commodity, everyone can have AWS. There’ll be more technological advantages that you can leverage as a retailer and a brand, but to Matt’s point, he’s spot on. That’s typically not how you win that game. You win that game by being a good retailer and a good brand, and the technology is usually table stakes, what you see out there. Ad technology passes it, and maintaining it and doing it in-house is typically the commodity that is not really giving you that huge of an advantage.

Travis:

With that said, you do need to be looking at how to leverage technology to be running a good business, and you can get a competitive advantage through technology by leveraging a third party. You can leverage a third party. You don’t have to do it in-house. When it comes to in-house versus outsource, I really think for these mid-market to the larger enterprise retailers, I think a healthy mix of both, really having an in-house dev that can work on some projects and work on different …. can speak the dev speak and work with an outsourced specialist, that is …

Travis:

Austin, you brought up, we have developers that will build custom integrations on our platform and connect it to other platforms. Someone that specializes in understanding that exact platform, is a consultant. That’s really how the big boys do it now. They hire consultants, and the consultants will be specialists around certain platforms or domain expertise. The in house devs are potentially moving into more of a managerial role. Talking with people that work at these big retailers, I feel like they’re just professional agency recruiters or hires.

Travis:

They hire agencies for everything. They’re really good at hiring agencies to do stuff. There’s a reason why they do that. They’re hiring specialists to do the work that it would take them a ton of time and the learning curve to figure out how to do. It makes sense, but I think having some of a light dev might turn more of a subject matter expert on their own business, their business logic, their business case. It’s really about having specialists in certain roles, and whether they’re devving or just dev managing, I think a healthy mix of that team is what makes a lot of sense.

Matt:

Yeah. If I can expand on that a little, it’s definitely true. As a business, you may have some specific business things like, I want to make sure that anytime my customers place an order on my store, they have a real time shipping rate, they know exactly what they can do. To achieve that, you may have to connect multiple systems together. You may have to find a rate shopping provider, like ShipEngine or something, so that you can shop at the cheapest rates given the two locations that are being set up at any given time. Those things, for example, are business requirements that are best implemented when you have some sort of internal resource that can at least speak to that.

Matt:

They know where these systems and these parts live and everything. Even though they may not dev everything, they may use pre-built connectors in other platforms to aid in that process. They have the domain understanding of what they need to achieve that business goal, and then they’re working with integrators, they’re working with platforms to make sure that all the pieces are aligning so that they can fundamentally achieve that. That’s another really good use of an in-house dev, even if they’re not actually devving, like Travis is saying. They at least understand the at play and they can help connect those pieces together with third party vendors or third party platforms, so definitely a good point.

Austin:

I love what you mentioned about Travis about making sure that you have some type of dev contact or consultant on your team, because if you don’t, how many times we’ve talked to maybe certain tech managers, or maybe not tech managers, CEOs and things like that, that just don’t understand the language? Don’t understand like, hey, I know you need this. We can grab this from the API or here’s some calls, and they’re just like, “What’s an API. What’s a call?” Things like that. Having that contact on your team to help when we say we are building custom integrations for you, because we’re the specialist, when it comes to an ecommerce order management integration or inventory management integration.

Austin:

That’s all we’ve been doing for 15 years. I think it’s definitely worth asking the questions of, again, what you guys are talking about, what’s the business use case, and is it a commodity or not? Then secondary to that is, I think this is super important is, if you are looking to outsource, if you are looking to use some third party, if you’re looking to use some outsource team, ask what their background is. Have they been doing this for forever? Have they been doing this specific type of customer integration? Have they been connecting these systems? These operations, have you guys been doing that?

Austin:

That’s one thing that’s worth noting, and I think this is going to be a nice little segue into the whole pre-built integration versus custom integration is, a lot of systems out there, they have these integrations, but is that really their core value? For instance, we were talking about this earlier by connecting my Shopify account to Amazon. I have an Amazon store, I sell on Amazon the same exact products that I sell on my Shopify site. Shopify isn’t really a management platform that connects the systems. What they’re good at is building great, easy turnkey website solutions with payment processing and really having a great brand, marketing experience for your customer.

Austin:

They’re not known to have a great integration with Amazon, because it’s just not their core business model. One thing, Travis, I’ll start with you is, is give us your thoughts on this whole pre-built integration versus custom integration. Maybe some examples that you’ve seen with other systems out there.

Travis:

Sure. I think you’ll have to, as a retailer, typically, I’m talking about a retailing scenario. For brands, for sure a little bit more, but, or sometimes at least, but retailers have to look at themselves like, do they feel that integration and integrating with other systems is going to be core to their retail business? Because traditionally, retail didn’t really have to do much integration. You see most of these multi channel platforms and OMSs out there. There’s a ton of just … you search for inventory and order management, and you see all the same names, 20 or 30 out there all going for the same customer.

Travis:

They’re going for the customer who just needs one siloed inventory and order manager system that is maintaining their warehouse inventory and can send a PO once a month, and they have a pre-built connection to Shopify and it works fine, or big commerce, or whatever. If you’re that kind of company, and integration is not core to what you see as your business strategy and your fulfillment strategy as a company, as a whole, then you might be fine with pre-built integrations and a system that isn’t really focused around integration.

Travis:

If you have distributed fulfillment and need distributed order management type systems where you’re sending orders to drop ship suppliers, you’re integrating the API or integrating the EDI, you really do need to look at what … is this system really built for that? What’s pre-built, is it ready to go versus what’s custom that needs to be done. Typically, the systems that are built for integrations and have the idea of their customer is going to be heavy in integrations, it will be easier to build custom on top of that. That’s a long way of saying that first, it starts with the platform. Before you would start looking at pre-built first custom, look at your platform. Is it extensible? Is it customizable? The NetSuites of the world, Flxpoint, I brought Salesforce earlier more like a holistic outside of the commerce side, but they have a commerce component.

Travis:

They are known for being super customizable. That comes with a little more complexity and it comes with more work and time that might go into understanding the system. But if you are looking to integrate and have integrations be a core to your business, making sure that it’s going to fit your workflow, starting with your workflows, understanding your flows, and it’s customizable and flexible enough to fit those, it’s going to allow you to really not have to switch platforms every five years. That’s a big thing. I’m going to switch. Looking at the platform, understanding the API docs, having that in house dev that can talk and speak to your logic and look at the docs and make sure it fits your business cases is really kind of the first couple steps in identifying whether pre-built or customer integrations are going to make sense for you and your business strategy.

Matt:

Yeah. Just to go a little further into … I see a common challenge is people basically choose the upfront time versus essentially the longevity. For example, it’s super easy to set up Oberlo on Shopify and get going, and you can do that within an hour, and now all of a sudden, you can sell products online. Whereas, even the more simple solutions like even inventory source, and getting that set up still requires you to establish a relationship, get your account set up and everything, but now you have cheaper pricing potentially, or you have more quality products or more reliable distributor. Definitely, when you’re looking at pre-built versus custom, don’t get too dissuaded by the setup time, for example, if it’s going to be long-term beneficial to your business.

Matt:

You have to factor that into you the onboarding versus the longevity in … are you going to have to do a migration like what Travis is saying in three years and migrate to another system, or can you leverage that and continue to expand on it?

Travis:

Just going back to the in-house versus outsource, I just wanted to touch on that. I think there’s three aspects of a custom integration. There’s building it, there’s maintaining it and there’s scaling it. Knowing that and thinking about that will help you determine when the platform, whether the pre-built versus custom route is good for you and how to do your mix of in-house versus outsourced employees, or consultants. If you think about building as easy, building is the easiest part of all that. You can connect two dots, right? You can connect point A to point B, API to API, CSV, whatever. You can connect those. You can hire them to Upwork tomorrow. It can be done. Maintaining is tough, not only as orders scale up or inventory size scales up or product data scales up, but also the complexity, well, maintaining, just in general, as things change, I should say, before I get to scaling.

Travis:

Things change, it’s maintaining it. How do you know? Is there a tooling in there to alert you when things change? All of that is a factor. If it goes down, if you outsource that and then you look to maintain it and that guy, he sets it up and then he decides he needs to change business decisions, makes a job change, right? Whole career changes. So, he’s like, “Oh, by the way that server I set up for you, I’m going to shut it down, you need to go figure out how to get my code on someone else’s server.” Maintaining that part, and then scaling it, as the data volume goes up and then as the complexity increases with the amount of different integrations that you have to add to it, you should look at that on … I probably want someone in-house or at least … I’m not in-house necessarily, but I want a core partner that can help me maintain and scale something, first having to reinvent the wheel and do all of that in-house.

Travis:

Building on top of a layer for custom business logic can be done though. That can be in-house because I understand your business logic. I’ll pass it to you, Matt, because I really … We’ve talked about this just over a couple of beers before. I’m just amazed at what I’ve seen you build, specifically within inventories on Flxpoint, just like the AWS infrastructure, the monitoring, the job management, all of that. Retail is gone today. The second you become a retailer with a distributed order management system or distributed fulfillment strategy, essentially, you go away from this siloed, I can use any off the shelf warehouse or inventory management system to, I now need an infrastructure to maintain these integrations and to scale up.

Travis:

I’ve always thought that was amazing. Before you look at the product, that underlying foundation is key. How can, I guess, CTOs from a retailer perspective, how can they look at that and understand that’s a piece of this as well?

Matt:

Sure. Yeah. Anyone, when they’re looking at their business, they have to consider the moving parts. They have to think about the risk involved with that, they have to think about the maintenance, mitigation plans, responsiveness around how you’re going to react to events that happen. Obviously, from an infrastructure standpoint, as you scale up your operations, as you add more distributors, as you want to sync more frequently, as you add more channels, you now have more processes that need to run to sync all that data, to keep everything aligned. You need to make sure that it’s done within certain events. Once I update the price, making sure that triggers a sync to my relevant channels, that’s that. There’s a lot just revolving around keeping things in sync as you scale it.

Matt:

It’s very easy to do a one to one connection, but just from the scaling, the second you want to scale that, then it becomes more complicated. A good example of that is if you connect to a distributor as like a retailer or brand, you connect to some sort of source and they provide you data, and then you want to push that to a channel. Then all of a sudden, now you want to push that to another channel, or perhaps, maybe you don’t even expand the distributors. The idea is that those channels have different data structures, they have different specifications that are required in certain fields, different workflows for each of those channels. You end up adding layers. You end up adding a layer at the channel level to say, how do I modify the eBay data versus Amazon data, or the Shopify data versus the Amazon data?

Matt:

You build these layers out as you go and it slowly evolves and it turns into basically a platform. If you really want to do things correctly and you want to give yourself the granularity of control, the build versus buy, you end up doing that. From the infrastructure, you have to build out like a whole team most of the time, or at least someone that is very competent in cloud engineering and how to set up dashboards and alerts when things are not working the way you want to, and having a team available to respond to those and investigate those events. That’s really one of the biggest differentiators that put platforms like us really a better choice in most situations. It’s just because we do that.

Matt:

We take off that burden. When it comes down to … this isn’t even a technological concept, this is just focus on what your business is good at. If you want to advocate your business as being great, perfectly on time in sync, and that’s how you’re differentiating yourself against competitors, then yeah, maybe it makes sense to go down that route, or at least find a really core partner that has those functionalities. But most of the time, it’s a waste of bandwidth, it causes growth because you can’t focus on initiatives that really would drive your revenue or drive your brand or your marketing strategies or product selection, or distributor fulfillment expansion, whatever it may be.

Matt:

It’s one of those things that when you look at the technology that goes behind keeping everything in sync and being able to constantly check on it, apply changes as necessary, monitor for issues, having thresholds in place to alert you of anomalies, things like that, it’s it’s a whole business in itself, and it’s basically one of the reasons why we build a platform ourselves because we saw all these challenges. It’s a little unrealistic to think that, at least the majority of people out there, have the capability of achieving the same thing on their own. It really is just like a separate focus and a separate business, and it doesn’t make a lot of sense for people to home grow that inside of their business.

Austin:

Yeah. You guys gave some awesome insight really, on, not even just custom integrations or ecommerce integrations, but custom dev work in general. I think, when it comes to deciding on a partner to work with, do they have an API? Do they have some way for you to connect into that platform by yourself with your in-house dev team? Obviously, evaluating, do they have the backend team to build out certain custom integrations? Like our Flxpoint developers, are they able, are we able to do custom integrations for people? It’s really evaluating who understands the work like we’ve talked about, who understands formatting of data, who understands how to submit over orders? Everything was chatted on there.

Austin:

Lastly, I would say, before we move on and wrap up here, the whole pre-built versus custom integration, try out the pre-built integration. It doesn’t hurt to connect one of those connectors, and give it a try, see if it works for you. There’s no need to spend hundreds of thousands of dollars for a custom integration when that pre-built integration could have worked just fine for you. Check all those boxes of need to have. Obviously, that’s definitely a big thing to keep in mind.

Matt:

Yeah. If I can add that real quick. Travis mentioned this earlier about sensibility. Even, when we talk about pre-built, there’s this notion that the integration works one way and that’s it. You have to go that way, you have to sacrifice maybe your rules and the way you do things to go with the flow of how that integration was built. For a lot of platforms, that’s true, but the extensibility is important because platforms like NetSuites, like Flxpoint, often try to say, we have a standard integration, we have a pre-built integration, but along the way, we know that things can be customized. We know that you may want to sync to certain locations, we know that you may want to apply dynamic rules that say, if you’re from this category, you have these different rules and things like that, and sync these to these different fields in that scenario.

Matt:

Maybe these brands all have sale prices attached to them and you need to control that logic. When you’re looking at the pre-built solutions out there, look to see if there are those dynamic rules with it. Look to see if you can customize your workflows, even out of the box with a pre-built integration. Just because you have some unique workflows doesn’t necessarily mean you need to go down the custom route. It may mean that you can leverage pre-built integrations as long as they’re a little bit extensible and customizable, kind of with what we do with our Flxpoint integrations.

Austin:

Yeah. It’s like that. The Zapiers of the world’s [LIGO 00:42:12]. We’ve been referenced being an ecommerce Zapier, being able to set up all these different rules where … Man, Zapier is super cool. I don’t know how to write or look at code, but I can go into Zapier and just make all these cool little workflows and I just feel like I was a developer. No, it’s a really good point that you bring up there. Lastly, I wanted to talk about this because we get this conversation all the time. I really think that this question is really going to be valuable to a lot of retailers out there that are viewing and listening to this podcast. That’s the cost of custom integration. How much does it cost to do custom integration?

Austin:

Obviously, we’ve talked about the evaluation process. We’ve talked about third party partners, we’ve talked about in-house versus outsource. The cost of a custom integration, I really wanted to chat on this because, from my perspective, custom integration, custom website design, anything that’s some type of custom work, I’ve seen so many retailers out there just get screwed. They pay hundreds of thousands of dollars for some custom website that really, they could have just bought a Shopify store and put on a free theme or $50 theme, and it would have looked and performed just as great as that $10,000 thing that they bought. From a pricing perspective, now what’s some insight that you have on there when it comes to evaluating the price of a custom integration? For instance, someone says, “Hey, I need you to build this integration for me. I know this is what I have, I’ve evaluated it. How much is it going to cost me?”

Matt:

Yeah. It’s a good question, and obviously it varies significantly depending on the task, and the company you’re getting quoted from and their experience. You can tear it out though. If you go to someone that is a freelancer, they’re going to have a standard development cost, and what they don’t have is the expertise of maybe your domain that you’re working in. Maybe they do, but you’re going to pay some sort of cost for that. Then if you go to say a company or a platform that has a strong background and expertise in what you’re specifically trying to accomplish, you’re going to get some extra cost essentially there for subject expertise, but that’s also going to result in usually less hours. Just like we talked about before, they don’t have to get that ramp up and that background on understanding the specific domain that you’re in.

Matt:

Really, I mean, what you’re paying for is a developer most of the time to just build that. The second piece of that is servicing or maintaining that integration. There may be some costs associated with that as well, so that you can make sure it’s running reliably, because you’re now … It depends on where you go, but you could think about it somewhat as, if it’s a custom integration, it may be outside of the scope of standard servicing methodologies of a pre-built connection. For example, you go to a platform and they have a pre-built connection, if that connection has changed, that’s one effort now to apply to many different people. So you can replicate that change very easily, whereas if you have a custom integration, it’s now your integration and you have to have specific resources dedicated to go and modify and service that.

Matt:

You’re going to eat more costs just because you essentially don’t get to … they have the crowdfunding effect of leveraging that for multiple people. When it comes down to actually quoting costs, really, what we look at on our side is we look at the complexity and equate that to some sort of estimated hours. Usually, we just do a flat rate type of deal, but we essentially have a pretty good understanding of what it would take, based on an evaluation, and then we can quote out the number of hours for different components. One thing that you want to look at with the cost is really making sure that you identify where those costs are being allocated to. If you have three or four different requirements, and back to the very beginning, nice to haves versus need to haves, equate those hours based on what you need.

Austin:

One thing to reiterate there too, and what we’ve seen is, just so people have an idea is that sometimes there’s a charge for a proof of concept. A lot of times, for a custom integration, it’s quoted out on an, like you were saying, an hourly rate based on how many hours that dev team thinks that it’s going to take to accomplish those. Then as well as, sometimes there is like a maintaining cost. Travis, what’s some insight that you have on quoting out custom integrations?

Travis:

Yeah. Matt [inaudible 00:46:38] a good point that you’re typically going to see two different approaches from the person you’re hiring or the company you’re hiring. It’s time and materials, which is like, I’m going to charge you the hours that it takes me and the resources it takes me as I go. Then there’s a fixed cost that I’m going to scope this out and take more time upfront to scope it out. I would be a little leery. In the larger companies, in the larger projects, time and materials is almost required because scope could have it so quickly, and it’s a multiyear project. You must have to do it, but if you’re just connecting two platforms and it’s a three to five week integration, or 10 weeks at the most, or whatever it might be, I’d be leery of someone that can’t scope it out fully and give you a fixed rate.

Travis:

If, as long as it’s pretty straight forward, I think I personally have always said, if you’re an expert in that area and you do the time upfront to just scope it out and to clearly define a proposal, you should go get a fixed rate and it works out for both sides. With that said, if it’s super custom, if you feel you want to be more flexible and you’re open to doing more of an hourly thing and you trust it, maybe it’s … I think it’s good to think about an integration team that you’re working with or a contractor. The first one you might want to do, almost like a proof of concept, a fixed rate, just like a date before you get married kind of thing, and get a feel for that. Then, you might want more flexibility to build, just change things or modify as you go. You might have a more complex project where you might feel more comfortable with hours and time and material approach. Just be thinking about that. There’s usually two fixed rates. It reduces the amount of risk on you.

Travis:

However, you might get a lot of pushback from your developer on like, that’s out of scope. You might hear that a lot. Keep that in mind. Just to give everyone, because I’m sure everyone … anyone that listens to this is probably like, how much does it cost? What should I expect? How am I getting ripped off? I’m just giving my two cents of what I see in the market. There’s three different types of consultants you can hire. I say consultant, that might be a mix of a team or just a single developer, or whoever it might be. It’s going to be the general just freelancer, which for an integration work is going to be somewhere between $50 and $100 an hour from what we’ve seen. If it’s offshore, in some other country, you could even get a little bit lower than 50, but typically if you’re going to get a decent integration, it’s done between $50 and $100 an hour.

Travis:

If you have a platform specialist, someone that knows the integration types and knows the platform you’re working on and things like that, that’s going to range between $100 and $300 an hour. Someone that … you’re not just finding by putting out an ad on Upwork. You’re actually talking with someone that knows NetSuite or knows Flxpoint, who’s a preferred partner, a preferred Shopify plus partner. You’re going to see $100 to $300 an hour. That’s typically what we see. Then that third level of, not only do they know Shopify plus, but they’re also specific to the healthcare industry. They know your industry, they know your workflows, they know your platform and they are super targeted and dialed in, you’re going to see North of $300 an hour on top of that.

Travis:

Then, those kinds of guys have carved out a niche for themselves and they are in a space, and they’ve done it because they’re good and that’s why they can charge that. Obviously, for a lot of the small businesses, that’s going to be … you could probably get by with the first or second tier. I would definitely almost always recommend a second tier for all the reasons we talked about earlier on the learning curve and the issues with just hiring a generalist when it comes to implementing. That’s a long way of saying, it could be anywhere between $50 and $500 an hour, depending on who you’re talking to.

Austin:

Yeah. I like what you brought up though, the different verticals, who are very specific to that product niche, and if they can solve that, it’s just going to be much more expensive too, if they’re again, the platform and the niche preferred partner.

Travis:

Sorry. I know we’re at the end of it. The last part I just want to get in here is like, if it wasn’t clear, the opportunity costs, if you hire a $50 a month, or an hour developer, and it takes them 10 weeks to do something, and you have to go back and forth and all your time is invested in communicating it, and then you can hire someone for $300 an hour and they can do it in two weeks and they do it all themselves, they do it perfectly, you have to weigh that, where you look at the two. The best way of doing that is start with some kind of fixed small engagement, a proof of concept, whatever you can, and dip your toe in the water. That’s the best practice for sure in hiring devs.

Austin:

Well, and real quick too, on that, I would say a lot of people, if you’re ever evaluating a custom integration where I would say you want the Flxpoint team to do it for you and NetSuite team do it for you, whoever, if they go through the due diligence of fully evaluating proof of concept, asking you questions about like, do you need this? Actually doing the consulting work, and then they give you a fixed price or some type of price off of their hourly rate, that’s usually like, okay, this is a good company to consider. I’ve seen other companies or I’ve heard of other companies that are like, right when you say just out of the gate like, “Hey, I’m going to need this.” Instead of them going through that consulting, evaluating process, they just say, “Yeah, that’s $10,000 right here.”

Austin:

I don’t think it’s very trustworthy of a company to consider that. Make sure to work with a company or a freelancer or a team that actually does the leg work upfront to make sure it’s fully scoped. I think it’s really my two cents on that part too. Wrapping up here, especially because we’re going a little bit late on time. Matt, we’ll start with you. Do you have any final thoughts on this ecommerce integration, custom dev work that would be great for the viewers and listeners?

Matt:

Yeah. The biggest takeaways for me is, find … pre-built connectors are generally a great solution, and the biggest thing is that you have to determine if the nuances, if your use cases fall outside of that. If so, is the platform that you’re maybe leveraging extensible enough to handle those. I think if you look at it from that approach, most of the time, custom development work really isn’t needed. But at the same time, sometimes it’s necessary to connect that last mile, essentially, to make sure that you get that last bit of connectivity or integration that you need to fully wrap up your entire solution in your business workflows. Definitely just be diligent around evaluating it, get to know your partners that you’re working with, whether that be a freelancer or platform or company that you’re working with, understand what their workflow is, how are they going about evaluating these? What are their quotes going to be structured like?

Matt:

Can they provide you some guidance? Maybe you don’t know if you need custom development work really, can you present them your use cases and see if they can solve that within their platform before going down the custom route? I know we do that a lot. Really, the biggest thing you can do, if you’re looking at this and trying to decide if you need to get custom developed work, really define what you need, what’s nice to have, and work with your team or your freelancer, whoever you may be working with, to really ensure that those are well-defined and understand, where does it fall outside of that connector? Which of these are really the offenders?

Matt:

Then make an educated decision. Back to what Travis was saying, what’s the value of this? Is it going to bring enough value to my business to go down this route? What’s the workaround if I don’t go down this route, and how close can I get if I choose not to do custom development work? Then just make a decision based on all of that information, you have the ROI, what it might return you, and how it’s going to impact your business, and so it gives you a good leg to stand on of like, did I make a good decision or not? You’ve done the proper work necessary.

Austin:

Yeah, no, that’s some great insight. Travis, any final thoughts?

Travis:

Yeah, just to piggyback on what Matt said. pre-built is great, because whoever has built that and is operating, will maintain it. The biggest takeaway at custom dev work, custom integrations is you have to maintain it. That is the 80% of the issues with building something custom, is the maintenance of it. Keep that in mind. What’s the opportunity cost of maintaining something on your own versus having someone else maintain it? The second a product goes out of stock, but the integration is broken and you don’t reflect that properly, orders breakdown when you’re sending them to your supplier, anything like that, an API is changing and now you need to go rehire that guy to build another custom, addition to the change in the API. Maintenance is a big key piece to it. If you leverage pre-built and have someone else maintain it for you, do that, for sure.

Austin:

Yeah. That’s a good point. How many times have we seen someone change their API or go from EDI to API or go from an FTT to an API?

Travis:

Even a CSV [inaudible 00:55:20], header changes and you don’t have the tools in place to understand it’s changed. You just notice because you sold some out of stock, right?

Matt:

Yes.

Travis:

Yeah.

Austin:

Definitely. That’s great. You guys, great insight. Thanks for joining me today. I appreciate it. Talking about ecommerce integrations is a huge topic in the realm of ecommerce, but yeah, again, Travis, Matt, thanks again for joining. Obviously, all the listeners and viewers, appreciate you jumping on The Modern Merchant Podcast today. Definitely be on the tune for the next episodes to come. See you, guys.

Matt:

Well, thanks for having us.

Travis:

All right. Thanks.