Ep. 28: The Power of Configuration: Why Platforms Beat Custom ERP Integration Every Time

Configurable vs. Custom: How to Think About Building Integrations the Right Way
The Integrate Intelligently Podcast — with Jeff Bickler and Scott Bickler (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Bickler, accompanied by founder and CEO of CADTALK, Scott Bickler. No guest today — Scott and I are talking about configuration versus customization: building a one-off integration versus using a platform or tool built to speed up integration work. Scott, good to see you again.

Scott: Good to see you too.

The Three Approaches to Building an Integration
Jeff: Scott, briefly walk me through the two or three approaches you typically see when someone decides to build an integration — whether that's with us or integration in general.

Scott: There are a few approaches customers or companies tend to take. One is the tried-and-true method: build your own, from the ground up. It's like building your own house — you're ordering the 2x4s, the sheetrock, doing all the work yourself and putting it all together.

The next approach is some kind of middleware — an ETL solution, essentially. Think of it like Zapier, but for SaaS apps — tools like Dell Boomi or MuleSoft, general platforms for integrations. There are some pre-built pieces in there, but you're still building a lot on top of it.

The last approach is a platform integration service that does a very specific, niche thing — pre-built for a specific use case.

Jeff: Does that cover what you see out there, or am I missing something?

Scott: That's a good description. There are different levels of complexity, and I think it's genuinely confusing for a lot of people trying to figure out where these products sit and what level of granularity they give you in solving your problem. At the very low end, custom integration is the most flexible but the hardest to implement. At the high end, you get the most prescriptive, formulaic approach — which might not do things exactly the way you want. There are pros and cons at every point.

Jeff: So visualize it as a spectrum — on one end, full DIY, get exactly what you want, built exactly how you want it. On the other end, something you just download or install that does what it does, no customization, and either that fits your needs or it doesn't. And everything else falls somewhere in between.

Scott: That's basically it. The custom approach gives you exactly what you want, but the catch is you have to tell it exactly what you want — you've got a programming language, a tool, and your specific problem, and no embedded knowledge to lean on. The way I look at it: how much knowledge, how many best practices, are actually embedded into the solution you're using? Think about human learning — I can either figure everything out myself through trial and error, or I can build on the shoulders of people who've already solved these problems.

Jeff: Right — you don't have to reinvent everything yourself.

From Custom Integration Engineer to Building a Platform
Jeff: Scott, you weren't always running a software company — you cut your teeth writing custom integrations. Tell me about what that was actually like, and how those custom builds took on a life of their own even after you moved on.

Scott: I was an engineer at a manufacturing company, and I taught myself programming. The first thing I really worked in was Microsoft Access — a fairly accessible entry point into programming at the time, a lot you could do with point-and-click. Over time I moved into Visual Basic and C, learning general programming and best practices. VB6 was probably the first thing I really wrote in.

Once you understand how the tool works — how to make code do what you want — it's a pretty addictive experience. Once that clicks, everything you look at starts to look like a problem you could automate. I was doing the job of a manufacturing engineer — which is actually the kind of work CADTALK automates today — and eventually people realized I understood the systems well enough to just go figure out how to improve things. I did that for years.

It really came down to watching people's workflows, figuring out what they were doing, and asking whether code or a tool could streamline it, save time, and get more out of people — make them more efficient. You end up building a lot of very specialized programs tied tightly to a specific problem. A lot of what I built were integrations, because we already had systems in place — an ERP called Sightline at the time, plus several others — so a lot of the work was tying things together. But it was tightly coupled, built for that one specific problem.

Why Custom-Built Integrations Become a Maintenance Trap
Scott: What I learned quickly is that companies rarely stay the same — things are always evolving. People would say, "this works great, Scott, but now we're doing it this way," or "that thing didn't work as expected because our data was bad." Everything I built became a little maintenance job. Eventually I couldn't build anything new because I was too busy keeping everything I'd already built running. That became my full-time job — and it got boring fast. I felt like a prisoner of my own ingenuity.

The only way out was to leave the company or move to something else entirely — which felt bad, because I'd be leaving them in a lurch. Nobody else understood what I'd built. You get this huge performance improvement from building the thing, but then the maintenance burden is in the details — because the business tends to mold itself around its tools.

I think people forget how much a process depends on the tools available at the time it was created. My background is industrial engineering — the engineering of processes — and you're always asking "why do they do X this way?" I love the example of the pot roast recipe that gets passed down for generations: cut off both ends of the roast before putting it in the pan. Three or four generations of moms follow this recipe without questioning it, until someone finally asks why. It turns out the great-great-grandmother who created the recipe had an oven too small to fit the whole roast — so the tool drove the process, and nobody ever questioned it again.

People get very dependent on their tools. They stop remembering why they made a decision, they fall into a rut of just using the thing — and then if it breaks, suddenly you desperately need it back, because you've oriented your whole workflow around having it and don't even remember how to do it the other way. What used to be a nice-to-have that made things faster becomes mission-critical almost overnight, and your job turns into keeping it alive.

Why Platforms Solve the "What Happens When I Leave" Problem
Scott: So the bigger question becomes: how do you build something that outlasts you — that doesn't require you personally to keep it running? That's where platforms come in. But even a platform is only as good as its adoption — if nobody else knows how to use it, it might as well be custom, because it doesn't actually solve the problem. You want the barrier to entry low enough that the knowledge can be spread across a team easily. Then you get something powerful: an environment that lets you build really useful things and keep them maintained over time.

That said, you do give up some flexibility for that. But that trade-off can be a good thing. We see this constantly in implementations — a customer asks for something based on their own experience, but we've seen the problem play out across hundreds of customers, so sometimes we do things that seem to make no sense from that one customer's narrow view, but make a lot of sense in light of the collective pattern we've seen. By buying into our platform, they absorb that accumulated knowledge — sometimes with some frustration, like "why do I have to worry about that, I don't have that problem" — and then three months later, they do have that problem.

Jeff: That's really true. I've heard the same thing from customers — they had "a guy," an intern or an employee who built the integration, and that person had been there forever. Then they retire or move on, and suddenly it breaks and nobody knows how to fix it. It worked great while that one person was there, but it wasn't something the company could scale or maintain — they just didn't have the internal resources or knowledge, or the people who did were already stretched thin. That's exactly when they come to us looking for something simpler and more sustainable.

Why "Higher-Level" Integration Platforms Aren't Always Enough
Scott: Absolutely. And if you take the next step up — a platform like Zapier, Make.com, MuleSoft, or Boomi — why isn't that enough on its own? Those tools can be very powerful, and they're the next level up: a platform with off-the-shelf integrations you can build on. But the same problem persists.

I think of it like programming languages — machine code, up to assembly, up to C, up to C++ and C#. Every layer builds on the one below it. Integration platforms work the same way: each higher-level tool takes on some overhead in exchange for making things simpler to manage. Think about .NET or Java — they introduced garbage collection, a runtime that handles memory management automatically. In the old C days, you had to manage memory yourself, or you'd get memory leaks that eat up all the machine's resources. Once you're in Java or .NET, you don't have to build your own garbage collector — that problem's been solved by some of the best minds in programming, and you just get the benefit.

Same idea with integration: you can roll your own and pay the "ignorance tax" of not knowing what you don't know, or use a tool like Zapier that abstracts away the API calls, tokens, and JSON handling — point and click instead of learning REST APIs from scratch. But that kind of tool doesn't carry much embedded domain knowledge. It's still a general-purpose language, one level up from raw code — you're still rolling your own logic, business rules, and best practices.

Then you get to something like CADTALK, which is domain-specific — solving the exact problem of moving designs from engineering to manufacturing, with all the idiosyncrasies of bills of material, ERP behavior, revision bumps, phase-in and phase-out timing. That requires a much deeper level of domain knowledge, and we've baked that expertise directly into the product to keep you on rails — so you don't have to pay down that ignorance tax yourself. We've already figured it out and built in a prescription for best practice. If you don't want to do it exactly that way, it can feel more restrictive — but it doesn't mean you can't. In CADTALK, we let you drop down through different layers: here's the prescribed way, but you can back out and do it differently if you need to. That gives you speed to integration while still preserving flexibility to adapt to each company's specific needs.

Balancing Flexibility and Structure: Lessons From Apple vs. Microsoft
Jeff: So it sounds like when you started building CADTALK, you took your own experience with custom tools — and the pain of maintaining them — but wanted to preserve the configurability and flexibility you valued, while still giving customers a framework or umbrella for how to implement things well. You wanted the best of both worlds without locking things down to one rigid way, but also without forcing everyone to build from scratch.

Scott: Right, because neither extreme is "wrong" — flexibility versus a prescriptive approach is a dichotomy you actively manage. The classic example is Steve Jobs and Steve Wozniak building the original Apple. Wozniak was the tech guy — he wanted ports on top of ports, the most flexible, tinkerable platform possible for hobbyists who love to plug things in and experiment. Jobs wanted something simple enough that his grandmother could use it — a fully controlled, top-down experience: Apple writes the software, builds the hardware, and it all just works without bugs.

Both philosophies built massive businesses — Microsoft largely followed Wozniak's philosophy, Apple followed Jobs's. Both can work. You see people ebb and flow between these preferences all the time: "I love my iPhone, but I wish it could do this one thing an Android does" — but then you'd have to deal with everything else that comes with switching. It comes down to understanding what you actually want and need, and weighing the trade-offs. I'm a tech guy, and I run an iPhone — people ask why I don't want the flexibility of Android. Honestly, when it comes to a phone, I just want it to work; I don't have that many needs. Relearning a different platform wasn't worth it for what I use a phone for. But for a different use case, I might choose a completely different tool, because the trade-off would be worth it there.

Jeff: That makes sense — it's not that one approach is good and the other bad. There are real trade-offs, and you have to decide what you value: something simpler that does fewer things well, or something more flexible and complex that requires more configuration.

Why Products Bloat Over Time — and How to Avoid It
Scott: It's fascinating to watch products expand and contract over time. You see it constantly — someone builds an ERP, and it grows, and grows, until it becomes this behemoth that does everything. Then a new product comes out that's radically streamlined — it just does one thing well — and everyone loves it because there's no bloat. They use it for a while, love how simple it is... and then they start asking for one more feature. Then another customer asks for something else. Before long, that once-simple, beloved product has become the bloated behemoth again. The cycle repeats.

So the way I think about it: build something that lets you adjust to a customer's needs without bloating the core product, and layer best practices on top so it looks simple on the surface, but has a layer underneath that lets you handle more complex use cases when needed. That keeps the product from ballooning into something nobody likes, while still giving power users the flexibility they want.

The Hidden Cost of Customization: Technical Debt
Jeff: That connects to something we talk about a lot — technical debt. Any time you build a fully custom integration, or heavily customize something, the more you add to cover every edge case, the harder it becomes to maintain over time.

Scott: Exactly — every feature you add starts with negative value. That's true of any system, not just software. Every change causes disruption — in software, it introduces the possibility of a bug; in any system, it creates a new decision point or interrupts existing flow. Everything you add starts in the negative, and you have to ask: will the long-term value outweigh that upfront cost? That's the lens for every decision, even when there's a lot of pressure and it seems to make sense in the moment for one situation.

When we build features at CADTALK, we always ask: could this feature solve ten problems instead of just one? Because solving ten problems gives us a much better chance of clearing that negative-value threshold.

Jeff: So when CADTALK builds features that let a customer configure or achieve ten different outcomes, that flexibility is intentional. But what about the alternative — just customizing the standard product one-off for a customer who needs something specific? Why not just do that instead?

Scott: Because of the technical debt it creates. Here's an analogy: imagine every time we needed a new word, we invented a brand-new letter instead of using the alphabet we already have. Right now, English uses 26 letters, and we build every word in the dictionary from that same set — we're all working from the same alphabet, just arranging it differently.

Now imagine instead I keep adding new letters for every new conversation I get into. Eventually I realize the letter "K" doesn't work anymore — nobody can pronounce it. Now I have to go back through everything, everywhere, and remove it. Versus if I'd just used the standard alphabet the whole time, "K" not working in one conversation wouldn't ripple through everything else.

It's the same idea as that old movie Multiplicity, with Michael Keaton — he keeps making copies of copies, and each copy degrades a little more: one becomes overly masculine, another becomes almost childlike. Copies of copies degrade, and you can't really fix them. It's the same risk with one-off customization — every day, you might learn a new best practice, but if that knowledge only lives in one customer's custom build, it doesn't spread. You've created a fork in the road, and that thing now has its own separate life, disconnected from everything else, unless you consciously go back and integrate the improvement — which is a lot of work, every single time. So most people just don't do it.

The way we approach it: everyone's using the same alphabet. I can build slightly different words for you than for another customer, but we're never creating a whole new alphabet each time.

Why Buying Software Means Buying More Than the Tool
Jeff: We've talked about the benefits — faster implementation because you're not building from scratch, more reliability, and something I really liked: the built-in best practices that reflect the cumulative knowledge across every customer and workflow you've seen. You get those benefits while giving up some flexibility, since the product isn't built exactly to your process from day one — but it comes with proven workflows already built in, and it future-proofs you. You mentioned that yourself — when a process changes, or data problems surface, having something configurable means you're not stuck; you can adapt and keep using it for years.

Let's recap the three approaches: full custom integration, middleware platforms like Boomi or Zapier, and then something like CADTALK — a pre-built, domain-specific integration platform that still offers real configurability.

Are there other platforms like CADTALK, maybe outside of the CAD integration space — AP automation, warehouse systems, anything with a similar philosophy?

The Avalara Comparison: Domain-Specific Data Normalization
Scott: The one that comes to mind is Avalara. They're not really integration-first the way we are — they solve a very specific problem, tax compliance, but they integrate with a lot of different systems to do it. Their approach isn't about tying two systems together directly — it's about normalizing data coming in from different systems into their own engine to solve a very specific tax problem.

Think about the complexity of dealing with thousands of different tax jurisdictions around the world — Avalara has consolidated all of that into one engine, with best practices baked in for what data you need and how to report it. Then you build integrations from various ERPs into that engine, and it knows how to handle everything because they've normalized the incoming data into one consistent structure.

It connects to systems theory — how you design a pipeline. A single flow is always more efficient than parallel flows, because there are fewer decision points. If you've got data feeding in from lots of different sources into one pipeline, the sooner you can normalize everything into a consistent shape, the more efficient that pipeline runs. That's exactly what Avalara does — normalize invoice data from many different systems into one structure, then run it through their pipeline to handle all the different jurisdictions. Different domain, same underlying principle: solve a domain-specific problem, and build the integration layer around normalizing everything into it.

How to Evaluate Integration Software: What You're Really Buying
Jeff: I like to close these conversations with something practical for people evaluating this kind of decision. One thing I'd recommend: don't just do the standard build-versus-buy cost analysis. Think about what you're actually getting for that cost — not just a piece of software, but the best practices, the accumulated knowledge, the process expertise, and the elimination of a maintenance headache. Any other recommendations for a company evaluating integration software, given that it really is a spectrum decision?

Scott: I'd say: don't think of the tool as just the tool. The tool is the company — the collective of the service, the tool itself, and the knowledge of the people behind it. You're not just buying software, you're buying the service and the expertise that comes with it. People often think "just give me the tool" — but the tool isn't the whole product. The product includes everything around it, including the services, the collective experience, and even the mindset behind how that team approaches solving your kind of problem. If a vendor's preconceived approach doesn't match what you actually need, the tool alone isn't valuable to you.

Here's a misconception people have: sales is a service. People hear "salesperson" and assume they're just trying to sell you something. But often you don't even know exactly what you need — that's the irony. You have a problem to solve, but you're not sure what tool or approach actually fits. A good salesperson is providing the service of educating you on what you actually need, filtering out what won't work, and pointing you toward what will.

Jeff: That makes a lot of sense — someone genuinely good at sales helps you solve the problem, gives you the right advice, and teaches you what you don't know. When you're evaluating something new, you don't know what you don't know. Someone experienced in that space can consult with you and help you think it through.

Scott: Sales gets a bad rap because people assume bias — and sure, there's some, why wouldn't there be. But that doesn't mean the guidance is wrong. Especially for a complex or technical product, the real job of a good salesperson is to guide you and help filter the decision. A lot of buying paralysis comes from the paradox of choice — people are afraid of making the wrong call. Really, all they need is a decision, and talking to someone knowledgeable — sales included — helps you filter the information and get pointed in the right direction. That's the actual job.

So the sales function, the consulting, the product itself, the collective expertise of the company — all of that is what you're really buying when you buy a product.

Jeff: That's a great takeaway — it's all of it together. Not just the product itself, which matters, but the service and the knowledge of the people you're working with, who can be a real partner going forward.

Closing Thoughts
Jeff: Scott, another great discussion — really appreciate you coming on. Any last thoughts before we wrap?

Scott: I think we covered it pretty well. Any further and I'll start getting too technical and lose people — I tend to be a deep thinker on this kind of problem, so it's easy for me to go down a tangent. Good time to put a bow on this one.

Jeff: Every time we have these conversations, I learn something new from you — even after knowing you my whole life and working alongside you at CADTALK for a long time. The way you make comparisons and analogies, how you think through why a problem matters and how people should approach it — I learned something new again today.

That's all for us on The Integrate Intelligently Podcast. You can find us wherever you subscribe to podcasts — Apple, Spotify, YouTube — and of course you can watch us here on YouTube. Subscribe if you're interested in learning more about CADTALK, and visit our website at cadtalk.com. Feel free to leave a comment if there's something you'd like us to cover in a future episode — we're happy to talk through whatever you need to solve.

Scott, great seeing you again — until next time.