Ep. 24: How Long Does It Take to Integrate your CAD and ERP?

How Long Does It Take to Integrate? A Look Inside CADTALK's Implementation Process (Episode 24)
The Integrate Intelligently Podcast, Episode 24 — with Jeff Bickler and Scott Bickler (CADTALK)

Introduction to Integration and CADTALK
Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Bickler, again accompanied by my brother, CEO and founder, Scott Bickler. This is episode 24: How Long Does It Take to Integrate. Today we'll talk about our specialty, integration, and dig into one of the most common questions we get: how long is it actually going to take? Scott, we're getting close to Christmas — do you typically take time off this time of year, or is it full steam ahead?

Scott: I call it "separation season" — that's how I think about it. When everyone else is hitting the brakes, I like to put on the gas. I tend to work a bit more during this stretch, though I still make time for family. I like keeping the momentum going, so I try to work at least a little every day — some days less, maybe just a bit in the morning — just enough to keep things moving. But yeah, definitely separation season right now.

Jeff: That's good. Next week's Christmas week, and I know a lot of our manufacturing customers shut down between Christmas and New Year's — pretty common in the industry. That was true when you were in manufacturing too, right?

Scott: Yeah, my wife's company has that same week off. It's pretty standard.

Jeff: That's actually why I like using this quieter stretch for more strategic planning — the busy weeks don't really give you room to focus, but the last couple of weeks of the year give you that quiet time to dig into ideas and strategy for the year ahead.

Scott: Exactly.

Jeff: So today we're talking about integration timelines — how long it actually takes. We use "CAD integration" as kind of a catch-all phrase, and some people take that literally, as just CAD to ERP. But when we say CAD, we really mean the broader engineering software landscape — all the acronyms we've talked about before: CAD, PDM, PLM systems, tied to ERP, and sometimes CAD to PLM directly. Any integration involving master data and bills of material is really our focus and our expertise.

I wanted to paint a picture of what integration looked like before something like CADTALK existed — pre-built, productized integration — versus what it looks like now, and what a realistic timeline looks like today. Scott, since you built CADTALK around the idea of a SaaS, pre-built integration platform that gets customers to market faster, can you give us some history — what did integration typically look like before a specialized product like this existed?

Understanding the Value of Integration as a Product
Scott: In the old days, integrations were mostly custom-built — custom code written specifically for that one connection, before APIs were as prevalent as they are now. I think when software first really took off, everyone was building their own point solution to solve one specific problem. Customers ended up buying a bunch of different best-of-breed systems, and found themselves running five, ten, twenty different systems, all holding overlapping data — and eventually asking, "could these things just talk to each other?"

That naturally led to the ERP concept itself — really just a centralization of a bunch of previously separate, singular functions into one big monolithic system that tries to do everything, essentially vertically integrated. Over time, more specialized, niche needs emerge again, and things proliferate back out into multiple systems — and people are back to wanting those systems to talk to each other. There's always this tension between one big monolithic system and a collection of best-of-breed tools, and figuring out how to connect them. In the past, that connection was almost always a custom, one-off effort — you'd hire consultants to write the code, and it would work, for a while. But we all know the problems that come with that: the person who built it leaves for another job, nobody else understands the code, it's fragile, and things break.

What's unique about being in the integration space specifically, and trying to productize it, is that instead of building a product that does one specific business function — accounting, AP, whatever — you're building a product where integration itself is the product. That's really where CADTALK comes from. There are other players in this broader space — Zapier, Boomi, plenty of general integration platforms — but what we do is very niche, specifically around bill-of-material and engineering data. The idea that "integration is the product" is actually a fairly recent concept, probably within the last 10 to 15 years.

The way I usually explain it to customers: we've taken all the boilerplate that every integration inevitably has to deal with — extracting data, handling user login, the data-matching logic of how you determine this part matches that part — all the universal pieces that, if you built custom, you'd have to rebuild every single time, for every single customer. What we do is eliminate all of that. We've built a product where the connection to your ERP, your PLM, your PDM system is already standardized and pre-built into our add-ins. Those systems already know how to talk to each other, and the common use cases are already handled — from an ERP standpoint, that's creating items, item master data, bills of material, and all the related data around that: manufacturers, suppliers, routings, and other tangential information. All of those connections are already pre-built, ready to use on demand, without building anything from scratch.

Jeff: That's really one of the things that makes software work in general — you solve a problem once, and then it scales, often very fast. When you write custom, one-off software, all the accumulated knowledge about how to solve that problem lives in that one piece of code, and you don't know what you don't know. You end up paying what we call an "ignorance tax" on every edge case you haven't hit yet — "oh, that didn't work in this situation, or this one." But when you buy software that's already been deployed and scaled across a large number of organizations, you're tapping into that collective, accumulated knowledge for a relatively low license cost — you're paying to not have to rediscover problems someone else already solved. You're also getting all the best practices bundled in. It's not just the code you're buying — it's all the accumulated experience and the lessons learned from everyone who hit those problems before you.

Scott: Exactly — we've captured that knowledge and built it permanently into the platform, so nobody has to rediscover it again. Every integration platform does some version of this, at varying levels of depth — but the core idea is removing the login handling, the extraction logic, the custom-property mapping, the connection to each target system — all of that gets removed as a concern, so you can focus purely on what's actually specific to your business, which is the part you actually care about. Everything else is already done — but there are enough configuration entry points to personalize it, because not everyone does things exactly the same way. You start with a solid baseline algorithm built on best practices, then provide enough flexible entry points — shims, essentially — where a customer can say, "yes, I follow that best practice, but my specific version looks like this." You have to balance flexibility against prescribed best practice to create something genuinely valuable.

Jeff: Exactly right — we try to cover the most common use cases, of which there are many, but build enough configurability that customers can still hit their specific goals. Otherwise you're locked into a rigid integration that does one fixed thing — and either you're forced to heavily customize it, which puts you right back into custom-software territory, or you're stuck with whatever it happens to do, whether or not that actually fits your needs. The way I explain it to customers: with CADTALK, you get all the benefits of custom software tailored to exactly what you need, without it actually being custom — combined with all the benefits of a pre-built SaaS platform. Best of both worlds — ultimate flexibility, but without having to build the standard integration plumbing yourself. It's not a rigid, one-size-fits-all product, but it's also not a DIY project.

Scott: Not at all — and that's really the goal: cover the broad market while leaving enough room for everyone's "special sauce." I think the reason people buy software at all comes down to cost savings or competitive advantage — and every business has some process, product feature, or way of doing things that's genuinely idiosyncratic to them, something that makes them competitive. A lot of software tries to force a cookie-cutter approach — "you're a manufacturer, so this is how you should run your ERP, our way or the highway." We'd rather guide customers toward genuine industry best practice while still giving them room to be themselves, because that's exactly what made them competitive in the first place. So you want that balance — we can push proven best practices into place, but there's still room for what makes each customer different.

The Importance of Scope in Integration Projects
Jeff: We know the pitfalls and risks of building an integration entirely from scratch — the sheer cost and effort, since you have to build everything yourself. Even if you try to reuse someone else's old code as a shortcut, it wasn't built for your specific use case, so you're really just trying to save money while the underlying challenge is still there. What CADTALK is really trying to do as a platform is make integration sustainable and achievable, and meaningfully reduce the cost of implementation. But regardless of the platform, every integration project carries some risk. Scott, what does implementation actually look like to you — from when you first started, versus the projects I've worked on more recently? Are there fundamentals we can point to — not just for CADTALK, but for implementing any software or integration — around how long it should take and what the actual steps look like?

Scott: We actually touched on this a bit during the ERP episode — if you're evaluating an ERP, the question is always: what problem am I actually trying to solve, and what's the most important one? The same thing happens with integration. People start with one specific problem — say, scheduling — and then, once they're in it, they start seeing everything else the tool could do, and scope creeps everywhere. That's when you get what I'd call the "shoulds" — "I should also be doing AP automation, I should also be doing this" — and then this weird cognitive dissonance kicks in: "if I bought a product that does ten things and I'm only using two, aren't I overpaying?"

People naturally have big eyes when they buy something — but at the end of the day, if you pay for a product and it solves the core problem you originally set out to solve, and you're happy with that value exchange, everything beyond that is a bonus. I'd approach implementation with exactly that mindset: get the core thing working, get that value as fast as possible. How quickly can you realize the original benefit you set out for? Then you can go back and ask, "I already paid for this — what else can it do?" and layer on more, iteratively — "oh, this ERP also does this cool thing," or "CADTALK also issues part numbers automatically." What you don't want is the very common failure mode where people expand scope mid-project, get fatigued, and the whole thing collapses, losing all the value they were originally after. That's the biggest risk. You're much better off with an evolutionary approach — get the core thing done, then iterate — rather than a "big bang" implementation trying to cram everything in at once. You have to keep coming back to the original problem you set out to solve, and genuinely limit scope around that.

Jeff: There's a lot of pressure right now, especially in IT and ERP conversations, around time-to-value — how fast can you get to that quick ROI. Cloud software, CADTALK included, has been built to deliver that as fast as possible — but you really have to narrow down what the actual KPIs are, what you're really trying to solve, and get those working first. Otherwise, like you said, it's like walking into a buffet and piling your plate way too high — you end up not actually getting the value you needed, and every extra feature you chase adds time, adds risk of failure, and increases the risk that nobody even adopts it in the end. None of that brings any real value.

Scott: Projects are a lot like that in general — most don't fail from starvation, they fail from indigestion, from trying to do too many things at once. That's true of a lot of things in life, but especially true of projects. People tend to think of implementation as a single event — "I'm going to do this thing" — when really, that's rarely how anything actually works. You don't lose weight in a weekend; you maintain a calorie deficit consistently over time, and if you keep that practice up, you stay there. Same principle applies everywhere. I actually dislike the word "implementation" a bit, because it implies a discrete event that finishes — when really, implementation is a much bigger share of the overall life cycle of the work than people assume. It's more of an infinite game than a finite one — a finite game has a defined end; an infinite game's whole purpose is to keep going. Implementation is an infinite game — you're never going to have it exactly the way you want on day one. You're constantly refining it.

Iterative Approach to Implementation: Learning and Adapting
Jeff: I've personally worked on well over a hundred projects, and I learned firsthand what happens when a customer takes on too much — the project drags on and on, they never really get the value they were chasing, not because the software failed them, but because they tried to do too much at once, and something had to give — data quality suffered, or something else broke down. You really have to focus on the core, foundational things. It's the same with fitness and health, which you and I both came to later in life — it's genuinely simple, not complicated: lift some heavy things, do some cardio, eat fewer calories than you burn, focus on whole foods that keep you in a sustainable deficit, and you'll get better results. Same with learning a language — I've studied six languages in my life, from my former career as a language teacher — you don't learn Latin in a year or two. I spent 25 years with it, just steadily, a little at a time. That's the muscle you actually need to build to get the biggest return — and I think that's part of our values here too: relentless reinvention, the idea of continually coming back and iterating.

Scott: Right, and I think everyone assumes more is automatically better — that you can eventually get everything you want, you just can't get it all on day one. What actually happens is complexity increases exponentially as you add more goals simultaneously, and humans have real cognitive limits — we can only hold so many layers of complexity in mind at once. I see this internally all the time, too — people get tunnel-visioned on a process, and the moment you introduce more variables, performance drops. It's like a golf swing: if a coach gives you five things to fix simultaneously, your swing falls apart. Give you one thing to focus on, and it actually improves. Once that's locked in, you layer on the next thing, then the next — but hand someone fifty instructions at once, and they can't execute any of them well.

Same thing happens with implementations, or with a diet — tell someone "just eat fewer calories than you burn," and physics takes care of the rest; they'll lose weight. But add "hit 200 grams of protein a day," and now there are two competing rules. Add micronutrient targets on top of that, and now the rules start contradicting each other, you overthink everything, and you end up making worse decisions — "I'm not hungry, but I need more protein, so I'll eat anyway" — and you don't actually lose the weight you set out to lose. Adding complexity, even well-intentioned complexity, often makes the actual outcome worse, because people struggle to juggle multiple competing priorities at once. It's much easier to take one thing as far as it'll go, then layer on the next, and the next — rather than making shallow progress on five things simultaneously and not really getting anywhere on any of them.

The Five Phases of CADTALK Implementation
Jeff: That leads right into how we approach CADTALK implementations specifically. One of the real risks with CADTALK — like with any flexible platform, and especially an ERP — is that because it's so configurable, and covers so many possible use cases, it's easy to try to do too much at once. Over the past several years, working closely with our implementation and professional services team, I've developed a process that reliably delivers value to customers — a five-phase approach, sometimes I describe it as seven phases depending on how granular you want to get. I want to walk through what that actually looks like, because I think these are useful foundational principles even outside CADTALK — even if you're implementing entirely different software, or building something yourself.

Scott: You're closer to this day to day than I am at this point — go ahead and walk through it.

Jeff: Sure. Over more than a hundred projects, even before I formally documented the process, you start to notice a rhythm to how things naturally unfold — this wasn't designed all at once, it emerged over years. We always start with what I call the initiate phase — that's simply getting the software downloaded, installed, and connected: your ERP, your CAD or PLM system, your PDM system, all talking to each other through that pre-built integration. That step is quick, because the connections are already built — get the software installed, licensed, and ready to go.

Next is the educate phase. Because CADTALK is a platform, we work closely with customers on learning the interface, understanding the process — how testing works, how configuration works, even though the actual configuration is typically handled by our professional services team. We talk through what the product can do, and critically, what scope we recommend. Early on, we used to build fully custom scopes for every single customer. Now I've honed that down to about 10 or 12 genuinely common use cases that the vast majority of customers need — high-value, high-frequency scenarios. During this phase, we're not just teaching the product — we're saying, "here are the twelve things almost every customer does — maybe 80% of customers land on exactly this." That fixed, well-defined scope lets us plan a clear start and finish for the project, so customers get real value without the risk of overreaching.

Then comes the collaborate phase — matching that predefined scope to the customer's actual environment. I always tell customers up front: don't worry, this predefined scope still delivers a lot of value — it's not the ceiling, it's the foundation, and we can absolutely build on it later. During collaborate, we're working directly with the customer to understand their design process, their engineering release process, what an engineering change actually looks like for them, what their properties and data structures look like — mapping both sides: what does it look like in engineering, versus what does it need to look like in manufacturing, PDM, PLM. That mapping — really, it's more of a transformation exercise than pure mapping.

Scott: Right — "mapping" trivializes it. It's genuinely not that simple.

Jeff: Completely agree, and it's a bit of a pet peeve of mine, because people love to boil this down to "oh, it's just a mapping exercise" — I've had customers say exactly that on demos. If you want to trivialize it down to its smallest possible description, sure, it's mapping. But it's really much more than that.

Scott: It's a transformation exercise. Honestly — having a child is technically "a mapping exercise" of two people's DNA. [laughs] Doesn't quite capture it.

Jeff: Exactly — a bit of a hot take, but not wrong. It really is a transformation, and our team actually uses that word internally — we're transforming data from one structure into another, not just field types, but formatting, sometimes combining data from multiple sources entirely. During the collaborate phase, we define exactly what that data transformation looks like. Sometimes it's something concrete: "my CAD or PDM description field is too long for my ERP field, so I need to split it across multiple fields," or "I have an English description and a Japanese description, and I need each one routed into the correct language field in the ERP" — and then edge cases like "sometimes I don't have an English description at all, only Japanese." There's genuine transformation logic happening — that's what our architects and the customer work through together during collaborate.

Once that transformation is fully defined, we move into the generate phase — building the actual rule logic: what do those transformations look like as real configuration inside CADTALK? Building in conditional rules — if A, then B; if A and B, then C — or lookups, like "each" in one system mapping to "pieces" in another, or "units" somewhere else. Those conversions and lookups get built during generate.

I actually combine generate with validate into one continuous loop, even though you could treat them as separate phases — because they genuinely iterate together. You generate a rule based on what was defined in collaborate, then validate it; if something's not quite right, you go back to generate, then validate again, back and forth, until everything defined in that fixed scope is actually working correctly. That circular generate-validate loop is how you get to the real value you're after.

The final phase is accelerate — actually putting the product to use in the wild, letting your users work with it day to day. That's our five-step implementation framework, built around a deliberately fixed scope.

I remember customers used to ask, "wait, is that really all it can do?" And the answer is always no — once they're actually in there using it, and I know you've seen this too, Scott, they start saying "wow, this is genuinely powerful, it can do way more than I realized" — and then, "can I also do this? Can I do that?" And the answer's yes — but we always bring it back to the original value they set out to get first.

The Psychological Aspects of Implementation
Scott: There's a real psychological element to this too — it's part of why some software vendors break features out and charge for them separately. Once a customer realizes the product can do something they're not currently using, the perceived value of what they already have shifts in their mind — even though nothing about their actual usage changed. It's genuinely strange: you were perfectly happy paying a certain price for a certain outcome yesterday, and the moment you learn it can also do more, you suddenly feel shortchanged for not using that extra capability. I catch myself doing the same thing sometimes — evaluating software and thinking, "well, this feature overlaps with something I already own elsewhere, so I like this option less" — even though that overlapping feature costs me nothing extra and I don't have to use it. It's a strange bit of human irrationality, but very common, and you have to watch for it in yourself.

That psychological pull is actually a big driver of scope creep in implementations — people start to feel like if they're not using everything available, they're somehow overpaying. It's the buffet mentality — "I paid $29.99 for this buffet, so I'd better eat everything," versus paying $25 for a steak and fries at a regular restaurant and being perfectly satisfied. At the buffet, you feel compelled to get your money's worth, so you pile on dessert, rolls, everything — and you end up with indigestion, both literally and figuratively.

Jeff: Right — you solved your actual problem, being hungry, and then you kept going anyway, and now you feel awful and somehow gained ten pounds from one meal. It's completely psychological, and it's very human — which is part of the point of this podcast, honestly: helping people recognize and push back against that instinct. Just because a tool can do more doesn't mean you should do more right now. That's a very common cognitive trap, and it can genuinely put the value you originally wanted at risk — you were perfectly happy with the core outcome, but now that you're trying to grab everything else too, you risk not getting either.

Scott: That's the killer point, really — you go in wanting one specific thing, and you'd have been thrilled with just that. Instead of framing it as "I'm getting my core value, plus other value I can tap into later when it makes sense," people frame it as all-or-nothing: "if I can't get everything right now, none of it feels worth it." There's actual economic theory behind that instinct — a kind of relative discounting effect. You're willing to pay a dollar for something, then the moment you learn that same dollar could theoretically get you 50% more, you mentally devalue the original thing you were perfectly happy paying for a minute earlier. That's genuinely how markets work at a psychological level — not to get too deep into game theory — but it's the same underlying mechanism. It's a bit like the hedonic treadmill: the life you have today might have been a dream ten years ago, and yet it doesn't feel like enough now. Same trap shows up in implementations, and it's exactly what puts the thing you actually wanted at risk in the first place.

Jeff: It's really important to stay anchored to the value, and the specific part of the project that matters most. I've been on projects recently where a customer kept pushing for more and more scope, and the project kept stretching longer and longer. I'd ask directly — "is this really necessary, is this actually critical to the core goal?" — and sometimes the honest answer was "not really." The longer a project drags on chasing extra scope, the more risk accumulates. We want customers getting real value and real usage out of the product as fast as possible — not sidelined chasing everything at once.

Scott: There's a real parallel here to test-driven development in software engineering — the "YAGNI" principle, "you aren't gonna need it." Developers constantly over-engineer, writing defensive code for hypothetical scenarios that may never happen — building out elaborate contingencies for edge cases nobody actually needs yet. Test-driven development flips that: you only write enough code to pass the specific test tied to an actual requirement, nothing more. When a new requirement shows up, you write a new test for it, then write just enough code to satisfy that. It's a deliberate guardrail against the very natural human tendency toward bloat — because subtraction is hard, and addition is easy, for almost everyone. You have to actively guard against that instinct, and implementation is a huge place where it shows up. People assume "we can only get better by adding more" — but that's not actually true, because people consistently underestimate the risk that comes with taking on too much at once.

Jeff: That's exactly why we built those five phases around a genuinely fixed initial scope — it gives customers the right amount to start, without overreach. But once you've finished that and you're actually using it, you can always come back and add more. It's genuinely common for a customer to come back later and say, "we've got another project," or "our process evolved, and we want to automate more of it with CADTALK." I've seen that repeatedly — we actually just had a long-time customer, someone we've spent a lot of time with at user conferences over the years, reach back out simply to say "I've got a new project" and purchase more implementation time, because they'd been running CADTALK for something like five, maybe seven years, and are still finding new ways to get more value out of it.

Scott: There's also this instinct to maximize the value of money already spent — "I'm already paying for implementation, how do I get more out of the same spend?" There's a good story that illustrates the flip side of that, actually, from years ago when I was doing ERP customization work. We built out a system, and it ran fine — until it scaled up to more concurrent users, and only then did a real performance issue surface, something you genuinely couldn't have seen until you hit 10, 15, 20 simultaneous users. The customer was furious — "why didn't you anticipate this and build it into your development process from the start?"

I understood the frustration, but I explained: I could have preemptively guessed at every area that might eventually be slow, and spent a lot more time upfront hardening all of it based on my best assumptions about what might become a bottleneck — assumptions that are informed, but still limited. Fast code is genuinely complex code — that's something people don't always appreciate, and you're always trading off various pros and cons. Or, I could build the thing, see empirically where it's actually slow under real load, and only optimize that specific bottleneck — which, overall, ends up costing significantly less, because none of that speculative optimization work for problems that never materialized gets wasted. Once I walked through that, the customer actually came back and said, "good plan, thank you" — but the initial instinct was that somehow doing it "twice" meant paying more, when in reality it's the opposite. It's the same reason nobody writes a paper in one perfect draft — you write, get feedback, revise, and that iterative process is actually more efficient than trying to nail everything perfectly in a single pass. Same logic applies to code, and to implementation generally — build it, get feedback, refine it, build a bit more. That's the lean-startup MVP mentality: don't prematurely optimize for problems you don't have yet. It's genuinely cheaper in the long run, not more expensive.

Key Takeaways and Lessons Learned
Jeff: So a few key takeaways here — themes we've actually touched on before, including with guests like David Trout, Kevin Miller, and Steve Mould. Focus on what actually matters most, stay disciplined within those boundaries, and remember that less is genuinely more. Think of it as a journey, not a single destination. And listen to people who've actually done this at scale — we've run hundreds and hundreds of projects, and we've learned real lessons, often the hard way. If you've never failed, you probably haven't learned much. We've made mistakes along the way, and I think you want a partner who's honest about that — "yes, we got this wrong, we learned from it, and we changed our approach because of it" — because those lessons are exactly what end up being valuable for the next customer.

My takeaways: follow the implementation plan, get the highest-value pieces working first, and treat it as an ongoing journey rather than a fixed destination. Get the value, get it moving, get feedback — the lean-startup approach, essentially.

Scott: That's really how you figure out what actually matters.

Jeff: Great conversation, Scott — I think we've touched on some similar themes to recent episodes, but it all ties together well: how CADTALK was actually built around flexibility, what we've learned running real projects, what's consistently worked for customers, and the ability to keep enhancing CADTALK over time specifically because it's a configurable platform — while still keeping initial scope simple enough to actually realize the value quickly. If you want to learn more about our implementation approach, or about CADTALK itself, visit us at cadtalk.com.

Scott, we're heading into the last couple weeks before Christmas — not sure how many more times we'll record together before the new year, but looking forward to 2025 and everything on the horizon. Anything else on your mind before we sign off?

Scott: Just want to wish everyone happy holidays — you might be listening to this after the holidays already, so happy whatever time of year it is when you're hearing this. Hope everyone's had, or has, a great stretch with family, and comes back ready to keep at it. Looking forward to more of these conversations.

Jeff: Agreed — Merry Christmas, happy holidays, happy New Year if we don't catch you again before then. And if you're watching this after the new year already, no problem — welcome to 2025, and we're excited to keep this conversation going. Scott, thanks a lot — we'll see you next time.

Scott: Sounds great, thanks.