Ep. 27: Building the Future of CAD Integration: A Developer’s Perspective

Building the Future of CAD Integration: A Developer's Perspective (Episode 27)
The Integrate Intelligently Podcast, Episode 27 — with Jeff Bickler, Scott Bickler, Connor Hyde, and Jake McCann (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Bickler — episode 27, January 2025: Building the Future of Integration, A Developer's Perspective. Today we're joined by a wider panel than usual: of course my co-founder and CEO, Scott Bickler, and two of our software developers, Connor Hyde and Jake McCann. Welcome, everybody.

Connor / Jake: Hello, happy to be here. Great to be here.

Jeff: Today's our largest panel ever — four of us, me included, plus Scott, Connor, and Jake. Connor and Jake are two of our software engineers here in the Cincinnati, Ohio area.

Meet Our Developers
Jeff: Every story starts off like the hero's journey, right — the superhero origin myth. So tell us a bit about yourselves: how you got into software development, your backgrounds, where you went to school, that sort of thing. No childhood trauma required, but anything you want to share.

Connor: I actually started in computer engineering, which is kind of tangentially related to software development — a bit more hardware-focused. I wasn't totally sure what I wanted to do heading into college, which I think is a pretty common scenario. I'd built a few computers by that point and spent a lot of time on them, so computer engineering seemed like a good fit. I was quite wrong. The first year was fine, but the second year was brutal — digital design, working with circuitry, breadboards, power calculations, and on top of that, a course called semiconductor physics, which was the nail in the coffin. I had some buddies in CS, did a hackathon, really enjoyed it, and decided to pivot to computer science. Haven't looked back since.

Jake: I wanted to do chemical engineering when I was younger, then took a chemistry class in high school and hated it. I applied to Ohio State and didn't get in, went to a branch campus instead, then applied to their school of computer science and didn't get in either. I ended up switching into computer science anyway — my older brother, about 11 years older than me, does computer science work and convinced me to try it, and making stuff sounded cool. I eventually got into the school of computer science, graduated, and realized they hadn't really taught me anything all that useful. So no real losses from not getting into either place on the first try — I'm here now.

Jeff: It's interesting hearing you both talk about that journey. Many years ago, Scott and I were both at the University of Cincinnati. Scott, you originally wanted to be a mechanical engineer, right?

Scott: Yeah, I think I wanted to do electrical and mechanical at the same time — because I was apparently a masochist and thought that sounded fun. After realizing how difficult that would actually be, I landed in industrial engineering, mostly because that's what I could get into — it was hard to get into the engineering school in general. I ended up falling in love with industrial engineering, the engineering of processes. Sometimes your life works out the way it's supposed to, not the way you originally planned. Worked out really well.

Jeff: Such a true statement. I'm the only non-engineer on this call — no engineering degree here, as we all know. My background's in languages, and I was a teacher. But it's interesting how nobody takes a direct path. It's rare that you know from birth exactly what you want to be, go through life, get to university, and nothing changes. No surprise we've all had our own ups and downs getting to where we are.

Developer Origins
Jeff: Tell us a bit more — how long have you each been at CADTALK, and how did you land here?

Jake: I've worked here about three and a half, almost four years now. I got the job because I needed an internship, and my buddy Connor was already interning at CADTALK — so it was a pretty easy in. I showed up, and they gave me a ton of responsibility and freedom really fast, probably a little more than was wise, but it was pretty cool and enjoyable. I'm the backend architect now, so I spend a lot of my time on architectural design and the long-term architectural roadmap — trying to make things more stable and scalable over time. That's basically what I think about for eight hours a day.

Connor: For me, I've been here since around August 2020 — it's been a while. What initially drew me to CADTALK was the challenge: there was something new every day, not a lot of hand-holding, and unique problems to work on at a really early point in my career. That captivated me from the start. These days I'm the development manager — day to day, I look at blocked issues, specify requirements for work items, do some admin work to keep the team moving forward, and I still take on standard development work on top of that.

Life at CADTALK
Jeff: I want to highlight something you both touched on — the level of responsibility and workload you were handed early on. That's really one of our core values here: radical responsibility and continuous improvement. Each of you basically described getting thrown into new challenges and new opportunities right away, because we want to empower people to grow. As Scott's said before, the work works on you more than you work on it. It's really a vehicle — if you've got the right personality — for improving yourself, learning fast, and growing. That's genuinely one of the things I enjoy most about working with each of you: neither of you shies away from something just because it's new or unfamiliar. You dig in and figure it out.

Jake: Especially compared to a lot of my friends in computer science who went straight to big corporations — they sort of became a cog in the machine. Granted, they never got to live through the pain of accidentally taking down 25% of a product [laughs], but they also never get the joy of building something big and new, rewriting a bunch of code all at once, and having people actually let you do it.

Jeff: I think the big difference between working somewhere like Meta, Amazon, Microsoft, or even the classic software-engineer dream job — somewhere like Nintendo or one of the big game studios — is that at CADTALK, you get to do a lot. You'll have real impact. That's not to say you wouldn't have impact somewhere like Microsoft, but in an organization that large, your role tends to be very narrow — which can be great if that's what you're looking for. But if you're like me, or like Scott, or you're a fit here, you like learning new things, tackling hard problems, and being challenged beyond a narrow scope. You definitely get that opportunity here.

Technical Achievements
Jeff: Tell us about something you've done here that you're especially proud of, or that you've really enjoyed working on.

Connor: There's always the first integration, which holds a special place in my heart — Business Central, I think, always will. But if I had to pick the thing I'm most satisfied with, it's probably the drag-and-drop support we added for IFS. Not necessarily because it was the most technically complex problem, but because it meant working within a lot of real constraints — both in our product and in IFS itself — and making it work well. I got a lot of gratification out of that.

Jeff: That's amazing — I'm actually learning about this for the first time. You built that?

Connor: Yeah, it's been in there for product structures for a while now — we're still working on extending it to operations.

Jeff: That's great, I genuinely didn't know that was there — you all are hearing it here first, exclusive: drag-and-drop functionality in the IFS application for product structures. Jake, what about you?

Jake: Mine's something I haven't fully finished yet, but I've conceptually solved it: decoupling our front end from our back end. Since I started here after school, it's felt like I keep relearning everything from my entire college coursework, over and over, at increasing levels of complexity. This particular problem involves a lot of multi-threaded work and process communication protocols — probably the most complicated piece of software I've ever written, but it's actually pretty simple to look at conceptually, which feels nice. I've explained it to a bunch of people, and they nod along and go "yeah, I get it" — which is a good feeling.

Scott: I think one thing people don't realize about software development is that it has a real art to it, almost a craftsmanship element. People assume it's all science, all ones and zeros. But it's a lot like building a piece of furniture — sure, it's functional, it holds your plates and forks, but when it's beautifully crafted, that adds something. Software has that same quality. When something's built well — tight architecture, solid unit testing, good architectural principles throughout — it becomes a piece of art. It satisfies both the analytical and creative sides of your brain.

Jake: There's also a timelessness to it. You can look at a nice car from the '60s and still think it looks great. In software, especially with how fast libraries and frameworks evolve for every language, it's really easy to chase a fad, build a million-line codebase around it, and then have it be unsupported in ten years — or have maybe ten developers on the entire planet who could still work on it. You end up with what I'd call shovelware, or ghostware — it just disappears into the night, never to be touched again.

Jeff: I'm not totally sure I know what "shovelware" means — Connor, you probably know these terms better than I do.

Connor: Shovelware is basically garbage software — a dime a dozen. And ghostware would be something like a library you rely on for a long time, and then suddenly there's not a single developer maintaining it anymore. It just decays over time and becomes unusable, with nothing supporting it.

Scott: A lot of the problems we work on here really come down to building a platform — something with more generic reach than a one-off solution. What makes it interesting is that anyone can write code to solve a specific problem — honestly, you can get AI to do a lot of that now. Solve this particular problem, generate the code. But solving a problem in a way that's reusable, in context, is the actual skill. That's essentially what we do here: we're integrating into a lot of different applications, and there's a lot of overlap in how those problems get solved. We could solve each one differently and end up with a wildly inconsistent product — but instead we put a lot of thought into how to build something once, apply it across every integration, and get a highly reliable, consistent result.

Most integrations in this industry get built as custom, one-off software — often through consultants — and they tend to be unreliable, high-maintenance, and expensive. Our whole goal is to democratize that: build a platform that makes it easy and reliable. But everything we build has to pass through the filter of "how do I build this so the same principle applies everywhere," across every integration we support. That's the art in it — that's what makes it interesting.

Jake: That's exactly how you avoid becoming shovelware, which I mentioned earlier. If you're using bespoke software that was built for you — or that you built yourself — most non-software companies aren't comfortable spending $200,000 a year on engineers just to maintain it. That bespoke product will inevitably break every six months, no matter what, even if the smartest engineer alive wrote the best possible code — there's still some baseline level of maintenance required. The approach Scott just described avoids the risk of CADTALK having, say, one customer running some one-off thing that we eventually stop supporting because it isn't sustainable for us to maintain.

Platform Development Challenges
Jeff: Talk a bit about your day-to-day experience here. Scott and I have talked on the podcast before about this idea of a platform — the way I describe it to customers and partners is that CADTALK offers off-the-shelf integrations. We don't build bespoke, one-off code. It's a configurable platform — everyone using one of our CAD add-ins, or a PDM or PLM add-in, is using the exact same underlying technology, the same code, every time. No matter what you're trying to accomplish with your integration, you're working with that same add-in. Same on the target side — whether that's Infor, IFS, Acumatica, or another PLM — everyone using that connection is running the same type of code. We're not altering it customer by customer. So talk about the actual challenges of building a platform like that versus building bespoke, one-off code — what Jake called "shovelware."

Connor: I can start with this one. One of the most difficult things is keeping data uniform across the different products we support. The end goal of CADTALK is moving data from one piece of software to another, and the hierarchies and structures of that data can look wildly different across systems, even while sharing the same core underlying principles. So one of our constant challenges, as we build toward the platform and unify things, is preserving each product's core principles while also folding them into common patterns we can reuse across different products and features.

One of the biggest difficulties on top of that is that no software team is perfect — including the teams building the systems we integrate into. Beyond normal, expected changes, every so often something comes completely out of left field that we just have to deal with. Customers are going to update their systems eventually, and they don't care what's happening under the hood on our end — they expect everything to keep working, every minute of every day.

Jeff: That's a good point. Something that's unique to our position is that we're in the middle — the middle child, essentially. We're taking data from one system and putting it into another, with complex data structures on both ends, and Connor's right that customers just expect it to work. Meanwhile, the developers on each end of that pipeline aren't perfect either — they've shipped bad code before, and they still do.

Connor: It's not uncommon at all — recently, one of the systems we integrate with just up and broke something. They changed how a piece of the API used to work, and what we used to be able to call was just gone. Not there anymore.

Scott: That's a genuinely different kind of development challenge than most people are used to, or even aware of. It's actually really hard to write bug-free code even when you control every piece of it — but layer in the complexity of your own product having multiple versions, every system you integrate with also constantly evolving, and every customer potentially sitting on any version of any of those things at any given time. And it all has to keep working, because it's critical data. The problem is genuinely multi-layered — more complex than typical development, because so much of it is outside our control, and we're also juggling multiple versions of every product we connect to.

We sometimes call this "dependency hell" — a term you hear a lot in software, where products are built on top of other libraries and dependencies, and just keeping versions aligned can be really difficult on its own. Now imagine that everything you integrate with also has its own versions and dependencies you have to account for. That's really the value we provide: we absorb all of that complexity so the customer doesn't have to think about it. It's not just solving the integration problem — it's removing the burden of everything around it.

Jeff: That's a great point, because customers who build their own integrations, or bring in custom development, are missing exactly that. We have to account for every variation — upgrades on both sides of the equation, all the time, across every customer, plus new features we're developing and all our own dependencies. If you build your own, every time something changes on either end, you're stuck dealing with it yourself. And that happens far more often than people expect.

Scott: There's no shortcut here — you're not actually saving money by building your own. A lot of customers assume they could do it cheaper, but they don't realize the complexity isn't just the integration itself — it's every change that happens afterward. Especially with cloud-based software these days. Jake, you and the team see this constantly with our partners — some of these cloud platforms push two or more updates a year, and it's not unusual for one of those systems to rename an API, add new fields, rename existing fields — twice a year, sometimes. Imagine having to maintain your own custom integration through that cycle. You're either updating constantly, or you fall into the other trap: never upgrading, stuck running some 30-year-old version because the pain of updating your integrations keeps getting pushed off.

The customer isn't just buying software — they're buying the system that keeps it working. Everyone thinks of it as one component: "I'm buying the right to use this software." But you're also buying the ongoing system that makes it work every single day. You're buying the expertise — Scott's original design, Connor and Jake's ongoing work, deep knowledge of both systems' APIs, and how each system actually behaves in real business use cases. Because even with full API access, you still have to account for how customers actually use these tools — and let's be honest, customers use their tools however's easiest for them, not necessarily the way the developers originally intended.

Jeff: Connor, Jake — I'd love your perspective on this, since you live it day to day: how do we actually drive down that variation? Customers use SolidWorks differently, they use every system differently — that's a known, unchanging fact. Add to that the fact that every system we integrate with is also changing, built by imperfect developers, and our own code is imperfect too. So architecturally, or from a coding standpoint, how do you actually make that work?

Connor: One method we rely on is pushing configuration down to the users. In a lot of target systems, functionality can be used in several different ways — so where it makes sense, we expose those same configuration options to our users. That said, you can absolutely over-configure a product and make it harder to use. We try to walk that line carefully. When we hit a case like that, we typically just default to matching whatever the target system itself can do — that usually covers the functionality people actually need.

Jake: I think the general safest approach we lean on is matching the same data validation the target system already enforces — "you can't enter this value here," "you can't perform this operation," "this field is read-only," and so on. As long as we mirror that closely, we can expose as much functionality to users as we want, as long as we're preventing them from shooting themselves in the foot. And usually, if the end system's API allows it, there's a way to support whatever the user's trying to do — the API generally tracks pretty closely with what's possible across the dozens of screens in these systems.

Scott: It's a great example of that whole spectrum of options — on one end, you could write raw code and hit the API yourself, doing exactly what you want with total control. On the other end, you're doing everything manually by hand. CADTALK lets you turn that dial pretty precisely, by giving a lot of configuration flexibility to get close to exactly what you want, but within sensible constraints. We essentially create a prescription for how to do it well, with enough hooks built in to let you customize it to your own process.

Configuration vs. Customization
Jeff: Every software company juggles new features and bug fixes — I know you two have talked about "submarine code" before, not totally sure what that means. What do you each prefer working on: the big, under-the-hood improvements — call it plumbing — or the more visible, surface-level work, more like painting the walls? My wife and I have an older home, and you can see it in the background — I have zero interest in painting anything. I'll run plumbing, build walls, build a deck, all the underlying infrastructure — but not everybody's like that. Some people love picking out bathroom vanity paint colors. Using that analogy, what do you two prefer?

Connor: I'd say I prefer the plumbing, by a good margin. A lot of my day-to-day involves fellow developers asking how something works, and the best feeling is being able to say "go read this file" and have them come back and go, "oh, that makes sense." Cleaning up things that have nothing to do with the end user but everything to do with the development experience — that's what I genuinely enjoy most.

Jake: For me, I think it's pretty common for developers to enjoy building new things, which we get to do fairly often here, surprisingly — or maybe not surprisingly, just luckily. But strangely, I also like fixing bugs. I don't love the actual process of tracking down where a bug lives, but the satisfaction afterward makes it worth it in a weird way.

Jeff: Kind of like a brutal workout — miserable in the moment, but you feel great after.

Jake: Exactly that. Some days it's all bug-fixing, and it's simultaneously the most gratifying and the most painful day.

Jeff: Not being a developer myself, I honestly don't know which I'd prefer — I've done a ton of CADTALK configuration work over the years. Early on, it was really satisfying, because it helped me learn how CADTALK actually works behind the scenes, even though I can't read the code and don't fully understand the architecture. Working through configuration with customers helped me understand, at a general level, how CADTALK represents and handles data. That said, after doing it for several years, I hit a point where I felt done with it — probably because I'd learned what I wanted to learn, and the initial excitement faded. In implementation or project management, you're mostly repeating the same work with small variations — maybe 80% of what you do is the same task again. For some people that's great; for me, eventually it became "I have to write this rule again," with just a slight variation.

Jeff: Good to hear you each have your own thing that keeps you engaged.

Future Outlook
Jeff: Connor, you mentioned your first integration was something you're especially proud of — your first real venture into this. Jake, you talked about the backend decoupling work. From my seat in sales and customer experience, one of the best things we've shipped recently is our new licensing system — licensing used to be such a chore.

Connor: Much better now — self-serve licensing is really nice. On my first integration, I had to wait five hours just to get a license with access to the feature I'd built. Now I can do that myself instantly.

Jeff: That's great. So — hypothetically, if a co-op student or intern were looking to break into this field, or land their first job, what's the one piece of advice you'd give them? Someone starting out today, heading into their first co-op or internship, or just getting into software development — what would you tell them, based on your own path here?

Connor: One of the best lessons I've learned here is: don't over-optimize, and don't drive yourself crazy chasing the perfect solution. When I started coding here, I was very new — I only had the baseline coursework behind me. But just getting to any working solution lets the team point you toward a better one, and that process teaches you even more. It's a very easy trap to fall into, trying to find the perfect answer right away. My advice: find something that works, and go from there.

Jake: Iteration will always beat anything you could possibly figure out purely in your head before starting. My advice would be — build a small thing in your free time. AI tools are great for this, honestly — a lot of them expose a public API for $20 a month, and you can build something genuinely cool.

I'm also a big proponent of going to a smaller company that'll actually let you work across a good portion of the codebase, because nothing teaches you faster than being dropped into something you have absolutely no idea how to solve, then being handed the responsibility to figure it out anyway. You'll be wrong a lot along the way — but I feel like I've learned more in the last three years here than in five years of university, and I'm confident that'll keep being true.

Jeff: As a former teacher, one thing I genuinely love about you both is watching you grow — you came in as students. I loved seeing my own former students go on to their careers; a couple got scholarships, studied what I studied, went on to work at NASA — one of them is at Blue Origin now. It's not that I had much to do with your success, but I love watching you go from being students to being real contributors on the team. It's genuinely fulfilling to watch. A little sappy, coming from a dad and a former teacher — but true. So: what excites you most about where CADTALK is headed? What keeps you motivated?

Jake: For me, I've gotten to the point where I know the codebase well enough to see a lot of the legacy pieces — not flaws exactly, but some not-so-straightforward, older parts of the system. It's exciting knowing enough now to actually understand those problems, which means I know enough to help fix them — not necessarily fix every issue, but rewrite things more cleanly, modernize them. I'm excited about that modernization work and building on it.

Connor: I think we've been here long enough now to really see the patterns and common use cases across CADTALK's customer base — taking that knowledge and turning it into real plans for making the codebase more configurable and more user-friendly. It's exciting to have that context now and actually get to do that kind of planning, especially in a space where "linking two things together" always seemed pretty cut and dry on the surface. There's a real amount of ongoing care and maintenance software like this needs to keep working reliably, especially with both ends of every integration constantly changing. The world's got a new hammer, and integration is a pretty perfect nail — I'm excited to see how much AI ends up genuinely making that easier.

Jeff: AI is definitely everywhere right now — I was at a conference last week, and it's the buzzword of every conversation. I used it myself again just today. It'll be interesting to see how platforms — including CADTALK — end up leveraging it going forward.

Connor: That's really exciting to me too — seeing where it actually shows up, and in what use cases. A lot of people are still struggling to identify concrete use cases in their own applications, so it'll be cool to see how it surfaces here at CADTALK specifically.

Jake: It's a good place to be in, honestly. When I graduated, I figured most of software had already been solved — every piece of software already written. Then suddenly there's a whole new caliber of problems to work on. It's a whole new thing.

Advice for New Developers
Jeff: Scott, before we wrap — any key takeaways from your seat as founder and CEO, and of course the original technical founder who actually wrote CADTALK, even though you're not doing hands-on development anymore?

Scott: No, honestly — I'm just really proud of these two. They've done an amazing job learning everything and picking up the software. It's genuinely cool to watch a vision you've had for over twenty years come true, and to realize you've built a team of people who've bought into helping carry that vision forward. Seeing people get excited about a problem like this, and grow and improve within it, never stops being fun — and that's true of a lot of people across CADTALK, not just Jake and Connor. It's really part of the ethos of the company: continuously look closely at this problem and figure out how to help manufacturing companies run as efficiently as possible. That's what we do. Jake, Connor — any last thoughts before we sign off?

Jake: I'd say — even though integration might not sound like the most exciting problem on paper, there's still a lot of joy in it. There are still plenty of unanswered, genuinely interesting problems that are fun to work on and rewarding to solve. And if you're a student in CS or CSE and you're not doing great in school — just get the degree, it doesn't matter as much as you think.

Jeff: I thought for a second you were going to tell them to apply to CADTALK.

Scott: [laughs] No — but you know, I studied Latin and Greek, and I get that a lot of people wouldn't expect that to be interesting. But everything is interesting — it's just not interesting until you actually learn about it. Nothing feels interesting when you don't know anything about it yet. But once you have enough knowledge to be genuinely valuable — enough to actually understand what you're talking about and provide value — it becomes tremendously interesting, because now you can talk to other people about it, educate them, provide value to a company or to friends. For years, people would ask why on earth I studied Latin and ancient Greek, or tell me they took Latin in high school and hated it. But it's the same as anything else — it becomes interesting once you actually develop the skill.

Jake: And I'd add — the reverse is also true. I was really interested in AI model development, then I took an actual AI class, which turned out to be mostly statistics. It's just statistics — not that interesting to actually do, even if the outcome is cool. The output looks amazing; the process can be a slog.

Jeff: That's a good closing takeaway too — the thing that looks super cool from the outside isn't always super cool on the inside. Well, Connor, Jake, Scott — thank you all again for joining. I really enjoyed this. As a former teacher, watching you both grow — mature, really — from students into young professionals here at CADTALK is genuinely exciting for me to see. Thanks for being on the podcast, and for everything you both contribute to the team and to our success. I really appreciate it.

Jake: Thanks for having us — it's been an awesome journey so far, and I'm looking forward to what's next.

Jeff: That wraps up this episode of The Integrate Intelligently Podcast. Find us at cadtalk.com, and please subscribe wherever you get your podcasts — Apple Podcasts, Spotify, and of course on YouTube, where you can see our lovely faces live. We're no Joe Rogan, but it's nice to be able to have these conversations in our own little niche. Scott, good to see you again — signing off for today. Thanks, everybody, see you next time.