.jpg)
The CRM Success Show
Talking with the people who own the largest and most complex CRM systems, with a strong focus on Salesforce.
For the executive, admin, architect, and RevOp leader running Salesforce orgs at scale. Every other week, we interview the people who actually own the system, prior guests include leaders at Walmart, Rockwell, Gusto, credit unions, and nonprofits, and every industry in between. Talking about data migrations, development, change management, partner selection, AI rollouts, Agentforce, team building, and the decisions that went sideways.
Website: https://www.crmsuccess.show/
Your Hosts on LinkedIn (Reach Out!):
Maz: https://www.linkedin.com/in/davidmasri/
Khero: https://www.linkedin.com/in/kherothetxrecruiter/
The CRM Success Show
Building Products in the AI Era - Rich Walker, Quik! (#42)
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
What does it take to build successful products in the AI era? In this episode, Rich Walker explores how AI is changing product development, workflow automation, customer experience, and the way businesses operate. He shares lessons from building Quik! and discusses using AI to improve efficiency, communication, and customer success while creating products that deliver measurable value.
About Our Guest
Rich Walker is the Founder and CEO of Quik!, an entrepreneur and customer experience-focused technology leader. He founded Quik! in 2002 with the goal of eliminating paperwork inefficiencies and making work easier. Today, Quik! powers more than 42,000 forms and helps financial professionals streamline their workflows.
Rich is focused on using AI to drive efficiency, improve software development, and strengthen communication. His leadership philosophy centers on vision-driven growth, customer experience, empowered teams, data-driven execution, and taking fast, decisive action.
Outside of work, Rich is a father, husband, car enthusiast, bodybuilder, and enjoys skating, bodyboarding, and snowboarding.
Talking with the people who own the largest and most complex CRM systems, with a strong focus on Salesforce.
Learn more: https://www.crmsuccess.show/
Your Hosts on LinkedIn:
Dave "Maz" Masri : https://www.linkedin.com/in/davidmasri/
Khero Witey: https://www.linkedin.com/in/kherothetxrecruiter/
Welcome! You are listening to the CRM Success Show, where you will hear from CRM executives who have overseen some of the most interesting and complex CRM implementations. Your hosts, David Mossri and Kira Whitey, will be bringing you real stories, real insight. Follow along on social media for updates on new episode releases, exclusive content, and much more. Enjoy the show and thanks for listening.
SPEAKER_03Hey, welcome to the CRM Success Show. Today we're talking with Rich Walker, CEO of QIC. So welcome, Rich. Glad to be here. Thanks, Dave.
SPEAKER_02So, Rich, nice to meet you. Thanks for joining us today. We like to start off really nice and easy with our podcasts. As you've listened to them before, you know what questions come in next. So just start off by giving our listeners a little bit of an overview about Rich Walker and what and who are QUIC.
SPEAKER_00Sure. So I'm a serial entrepreneur, started my first business at age 12. Later in life became a financial advisor, saw tons of paperwork being filled out, including myself. And then I said, no, never doing that again. So then I invented QIC to fill out my forms for me back and tooth. Now I'm running a 24-year-old company that is growing like crazy. We have a dominant position in the wealth management space. We manage over 43,000 forms in this highly regulated environment. And we generate over 1.4 million forms every month for our customers so they can fill them out, get them signed with DocuSign, do the process of opening accounts and managing accounts. And a fun fact about our company is that we generate so many forms digitally. We save more than a tree worth of paper every hour of every day. And we plant those trees with the Arbor Day Foundation. So we're closing in on 100,000 trees planted.
SPEAKER_02Wow. Super impressive. So not only is it a business with a real time save process improvement, but also you're doing a bit of social good at the same time, which is awesome. Rich, people always ask, is entrepreneur a skill you pick up over time being an entrepreneur, or is it something that you feel like you're born from the inside with a young age? What are your thoughts on that? What are your thoughts?
SPEAKER_00Man, I think I was born from the fire. My entrepreneurial spirit came from being super poor as a kid, having a lot of different challenges, realizing that if I did things, I could make money. And then when I made my first product at age 12, made a thousand dollars in one day, I realized, wow, this is amazing. People will pay you for something that they want that you make or you provide as a service. I believe everybody should try to be an entrepreneur. I don't think America has enough entrepreneurs and they are the innovators and the drivers of economies, in my view, but it's not for everybody. It takes a certain kind of steal. I'll just give you an example. When I started quick, I left a multi-six figure income to make $1,000 a month for the next four years. My rent was higher than a thousand a month. So how do you sleep at night knowing you can't pay rent on the next first of the month? I slept fine. That never bothered me once. I just looked at it as I'll figure it out, I'll find a way to get the money. I was never late once on paying any bill that was due. Yeah, I went in debt. I did all the things that were crazy. I did consulting work. I did whatever it took. But that's kind of one of those things that I think to be an entrepreneur, you have to really steal yourself against risk and stress and not let it drive you crazy and not let it cause you to lose sleep. Just stay focused on what you're trying to accomplish. Um, so yeah, it's not for everybody, but I really think everybody should try it.
SPEAKER_02Love it. Um so operational inefficiency was arguably one of the reasons that QIC was created, or at least the idea came from your personal experience in the financial services space. Tell us a little bit more about that. So presumably you were doing a very manual process and you felt there must be a better way and it didn't exist, and you thought, sod it, I'll build it myself. Is it literally like that? Or how did you come across that?
SPEAKER_00Look, let's bring this back to the core of your show because honestly, this is where it started for me. I was frustrated with the fact that I'm putting all this data about my clients into my CRM and it had nowhere to go. Like, why do you do all this work? Why do you keep clean records and then you have to sit there and transpose it by hand onto documents? I thought that was the stupidest thing ever. And ironically, I'd also built other integrations with my CRM to do other things, like automatic charting systems to display Yahoo! graphs of stocks that our customers owned, Monte Carlo simulator to simulate the returns they would get over time if they did certain types of investing and risk profiles. I already had this kind of concept of there's this really amazing source of data that's not being leveraged. And when the forms became a problem, it was just the same thing to me. I said, I'm gonna take this data and put it on the form. So, Carrie, you might laugh because the original version of my product was a hack. I took an Excel spreadsheet, I connected it to my CRM. I knew I could pull the data. I took an image of the form and overlaid fields in Excel on top of the image so that I could mimic filling out a form. And then it would just print, print the Excel spreadsheet over this image, and it looked clean enough to turn in. And so people kept saying, Rich, how'd you do this? I'm like, Oh, I just built this thing. They're like, Great, give it to me. Like, no, I'm not gonna give you an Excel spreadsheet. That's stupid. But you know, the truth is I had a technology background in the 90s. I worked at Arthur Anderson, I did technology consulting, and then when this became a problem for me personally, I just can't sit still. There's a rule in my company if you want something automated, give it to me twice. The first time I'll do it, the second time I will get rid of it and automate it. So that was just that revelation to me of hey, I'm not gonna do paperwork ever again. But it all centered down on where my source of truth was.
SPEAKER_03So tell us more about that. That's really a policy at your company. Um, give it to you twice, twice is not it's enough, it's not too much.
SPEAKER_00No, no, nobody's allowed to do that anymore.
SPEAKER_03I'm not the bottleneck to well, I don't mean you, but I mean if someone's doing the same thing more than one time, they should try to automate it.
SPEAKER_00I believe that's a good way to look at it. If you're doing repetitive tasks, you should be asking, can a computer do it better? And with the age of AI, we should be doing it even more. Should we continually do repetitive tasks if they could be automated or streamlined or become better? Look, when I was a consultant, I'd go to large organizations, Fortune 500 companies, and part of the job was change management. And so I'd meet with people to understand what their role was, what their actual tasks were. And the most common answer is, oh, this is the way we've always done it. Really? So you never thought we could do it differently or better or faster? Nope, don't care. Just gonna keep doing it that way. This is a mindset. Like when you have the mindset of growth, you think, how do I push for more? How do I get things done better in a more fluid way?
SPEAKER_03So um Akiro's having a bit of an audio issue. He'll he'll be back with us in uh in a second. I'm so sorry about that. So so it's funny because I started when I started my career, it was it was in marketing systems, direct marketing systems. It was very, very simil similar, where it was like I was kind of took on the job to learn how to do it, to build it. I mean, I I took on the job intentionally, I was actually in IT, not doing the job, and then decided to automate it. But I think that's kind of like an old school philosophy of you know, really to really know it, you almost have to do it. So it's I think it's a it's a great, a great perspective. So you started, you said 25 years ago, which puts us around what years did you launch?
SPEAKER_00So I produced the first version of my product in, and then I discovered after six months of people asking for it that I should build it. So we launched it officially on February 11th, and it went so well that by May of two, we said, let's incorporate a company, let's take this into market. So yeah, we're we're 24 years old at this point, and I'm more excited than I've ever been about my company just because of what is in front of us and what the potential is for it.
SPEAKER_03So that puts you, I'm trying to peg you before the start of Salesforce. So no, so say I think Salesforce launched in '99. So you're shortly after it, but the other CRMs out there at the time, I think ACT was probably the biggest one.
SPEAKER_00Oh, yeah. So I'll I'll give you some context. The first version of QUIC, because it had to talk to CRMs, it talked to ACT and Goldmine and Microsoft Outlook. And from there, we grew and grew, and we added 35 different CRMs that we could connect to or data sources. CSV was one of them, so that's not really a CRM. And Outlook's not a CRM either. But we added things like Juncture, which is a wealth management platform, Red Tail, Gorilla, Gorilla Marketing was this robust marketing CRM for wealth managers. There were a whole bunch of them, Dave. And part of what I did is I said we need to normalize how we talk to systems. Every system's architected differently, all their data is stored differently, but we need to extract that out and normalize it so that it's used in the same way, regardless of what form it's going on. Um, yeah, you know, the other thing I like to think about is I started quick before SaaS was called SaaS. And we were just then talking about the cloud. We're gonna put information in the cloud. I'm like, you mean up on servers that's somebody else's place? That's what we're talking about. So it was a fascinating time. And you're a technologist, you're probably really comfortable going to Google and Stack Overflow and all sorts of different places to find information on how to solve problems. I didn't have those options in 2002. I went to Barnes and Noble and Borders and I sat on the floor reading books for hours and hours, deciding if this book had an answer worth paying for. It's a very, very different time to start a company than today.
SPEAKER_03Yeah, um, I actually am that old. Sorry. Um, I remember I remember uh Barnes and Nobles, it was BN.com. Barnes and Nobles, yeah, they would deliver a book in 24 hours in Manhattan. It's the same day delivery, believe it or not. This is at the height of the dot com, boom. So so same thing, learn from books. It was a different time. So cloud didn't come big until I think 2007-ish. That's when it really started exploding.
SPEAKER_00I'm not sure when AWS got big, but yeah, it's definitely AWS in 2009, and they really were only out around 2000, I think. And when we joined in 2009, they had so little support for Windows, Microsoft Windows environments, which is what we were. So we were very early on, and it was hard. Man, it was hard to work with them, but that's where we've standardized. And then Azure came out, I think 2010, somewhere in there. What's interesting is that I was on Salesforce in 2000 for a company that I worked with prior to starting my company, and it was just fascinating to see like, hey, wait, you could use this web-based CRM and it's all hosted and managed for. You don't have to have on-prem installs. It made life so so much better. But uh, it was very early. It's very, very different product back then. I'll tell you that.
SPEAKER_03I mean, look, uh, Salesforce really pioneered they like to say cloud SaaS, but the truth is what they really pioneered was multi-tenant. That's really that really was the game changer with that, right? They separated the day later from the UI layer. And then, of course, later with the customizations on top of it. I was doing I was doing uh Sales Logics for a while around that time before Salesforce started killing them. Um, and the way they deployed with that you deployed to servers, but you deployed back end and front end. It wasn't really multi-tenant the same way that Salesforce was, but at the same time they called it cloud. So what the heck, right? So tell us about that. So you obviously knew about Salesforce when you started quick. Were you saying with this like a strategy that you're gonna target CRM systems, or you just I'm gonna go my first and let my clients figure it out? You take us.
SPEAKER_00We started thinking I'm an advisor, I'm gonna work with other advisors. And so there were two actual problems we had to solve. One was do we have the forms they want to use? So they would say, Hey, do you have Fidelity? Do you have John Hancock? Do you have American funds? So one of the big challenges we had was getting the documents, the content they actually wanted to create. But the other part was do we have a connection to their source of truth, their data? And so that's why we ended up building 34 or 35 different data source connections because those opened up market opportunity for us and it stripped it for customers. Because the alternative, as I'm sure you've seen many times, was hey, export your data to a CSV, upload it to our system. Oh, and then when you update your again, you have to export again and re-upload. What a nightmare! So we made these dynamic connections into their systems so that you could just simply pull a record in real time from you could open up QUIC, choose your CRM, choose your person, put them on a form, and leverage real data that you're maintaining right now in your system with no need to do the updates. So yeah, it was a big part of our strategy was to drive that. Uh, but around two years into my company, I also realized if we took the core engine out of QUIC and offered as an API, then we could sell it as a white label type of service to other companies. And our first customer, we had three, but the most name brand one everybody would know is mask. So we made one sale to serve over 5,000 users. And I thought, oh my gosh, this is it. This is so much easier. They were in charge of sourcing the data, connecting it with the API, pushing it through. We were responsible for generating the form. So that took us a little bit away from the CRM in that sense. But even to this day, I have a turnkey product that talks to a dozen different data sources, including Salesforce at multiple levels, plus Salesforce overlays, as well as proprietary ones in our ecosystem. Just because that, I mean, again, that's where everybody drives to. That is their hub for how they run their companies and their businesses. It's remarkable when I find companies who are not really leveraging a CRM. And I'll admit something. My version of a CRM when I started was Microsoft Access. It was just the database we built for ourselves. It was very klugy, but it did the job. We didn't invest in any product at that point.
SPEAKER_02Rich, quick question. What was the moment you realized that you went from an idea to having an actual business? Was it the acquisition of a large company like an example you gave, or was there a certain amount of number of users or forms, etc.?
SPEAKER_00No, Kiro, honestly, it's our first customer. It was the first customer, man. So our first customer is a woman who was a top 75 producer in the nation for American funds. And she had a staff of five people. And the reason I said I'll build the product is because of her. She learned that I had this capability for my own practice. And she called me up. She said, Hey, if you could build that for me, I will pay you money. And this is somebody I highly, highly admired and respected. So I said, Oh, okay, okay. So I built the product. We did the first install for her team, and somebody on her team's full-time job was handwriting forms 40 hours a week. She gets our product, two weeks later, calls me up, and she's honestly practically in tears. She's like, You're gonna change my life. Like, I'm putting in four hours a week now. And guess what? Two is for the form, and the other two is to update the CRM so I have better data to put on the form. Suddenly, our product was enforcing better rules and better data hygiene in the CRM because now there was a reason to do it right. That was the aha moment, honestly, is we had our first paying customer, we saw the need, we saw the transformation. I would say the second one was winning Mass Mutual because I went from, oh, I could have a desktop product that I install across the world to I can have a web-based solution in the cloud and I can make money all day long with that type of solution. So that's where we started. I hate the word pivoting because everybody's always pivoting, but that's where we said, let's shift our focus and be an API first company. So that was around 2004, was the install of that product. And then that shift happened in 2005. And to this day, we're an API-first company. 90% of our users don't even know our brand name. And I'll meet them at a conference, whatever, like, oh Rich, I don't need your product. We have this thing called the new business checklist. I'm like, yeah, that's us. We're behind the scenes on that one. It's really gratifying, Caro, because so many users are getting value. We serve, I think, over a quarter million financial professionals at this point, and so many people are getting value. The other day, my mom was talking to her advisor. Yeah, her advisor is using QIP. Very cool. So she's getting the benefit of it. 100%.
SPEAKER_02It's a very cool moment, I think, when you see people around you in everyday life mentioning your product. And I think every good entrepreneur as well, uh, a lot of these businesses that are household names today didn't start out selling the product they do today, right? So I think bit of credit to yourself there for knowing when to switch. Um, and I'm sure once you brought on that logo as well, you you were able to then pay rent, uh, which is which is a good so all that blood, sweat, and tears uh was worth it in the early years um that you weren't able, you know, that you were consciously uh, you know, not worried, but kind of worried about paying rent. Um so so you are now in this new phase of the product, right? We're in this new phase building out and leveraging um curious AI and regulated environments. It's a bit hit and miss, heavy compliance environments that you operate in and specialize within. What obstacles have you maybe faced thus far from that perspective? I assume it's not been plain sailing, just build and embed AI. I assume you have to adhere to certain standards. What are some of those obstacles and standards you've had to take into account?
SPEAKER_00Yeah, look, the first one that comes to mind is how many contracts I see now that have AI in the contract. And they want to know explicitly what you're doing with AI. Does their data touch influencing any of the behaviors of your product? And the audits can be quite extensive and it's Wild West right now. Nobody has the standard for what they should or shouldn't be doing around this. You know, thankfully, we have a philosophy. AI never touches the client data and it never goes all the way to the front end user experience. So anything we're doing with AI is to create capabilities on the back end of our product. Again, we're API focused. So when you call our API, we need to be able to produce certain amounts of data enrichment, workflows, and capabilities that nobody sees. And we're using AI for that. But there's a whole nother facet to this conversation. Where we are today, I mean, if you consider we're three or four years into this LLM world, where we are today is everybody saying we need to be agentic, we need to be pushing LLMs to do the work for us. And they're still, I don't think, the safety guards and the understandings around what this means and how to do it. And I keep hearing about company after company spending their entire budget, failing to get ROI, but more importantly, I think they're failing to put the guardrails and the constraints around how AI actually should function within their environment. So one of the things you probably should ask yourself is if you're having AI do something for you, does it do it the same way every time? Is it repeatable? Is it accountable? Can you rely on it to give you the same quality result every time? And that's up to the designer of that implementation to make that happen. How many of us have asked AI the same question twice and gotten two totally diverging answers? I mean, I know I have, but I've also worked really hard to get AI to give me the same answer every time in the context of a problem. And that is exceptionally difficult to achieve. And I don't see a lot of people achieving it, frankly. Carol, what are you seeing? I mean, you guys are in the CRM space all day. What are you seeing with this?
SPEAKER_02I think there's a race to adopt and embed AI. It's coming from the top bottom. And I think as a result, we're seeing questionable AI initiatives go into real environments, which ultimately are going to cause more headache than they're going to solve. But I think the reason, one of the reasons for that is ultimately you can ask Copilot GPT or whatever tool you use perplexity and get different answers. And I think we also are in an era now where individuals using AI in a mainstream way are not necessarily technically minded. And as a result, I still think those who are embedding AI into a tech environment should come from a software development background. They understand code, they know how to spot errors, and now we're moving into more of a AI-generated testing, AI generated code, AI first this, AI first that. So that's what we're seeing. Yeah. Go ahead, Matt.
SPEAKER_03I was gonna answer to it. Yes, I was gonna say, so from my perspective, it's a little bit different. I think the AI tools, particularly Claude, we're using to generate code which is deterministic, and that's not production ready at the time, right? So you use it as an assistant, generates code, that gets tested, verified, it's good to go to production, and then it is deterministic. So the AI version of it goes away. So that's a massive use case, obviously, in in software development. The other side of it is there's an arbitrariness to AI because there's an arbitrariness to our natural language, right? And it's actually one of the reasons why code existed to begin with, right? To get rid of the arbitrary nature of natural language, and then it is supposed to kind of I mean the the selling point is that it's going to get rid of the arbitrariness, but it doesn't, it just kind of acts more like a person, which is very arbitrary that way. So you use it for things that you need an arbitrary decision for, and in that case, it works very well. You know, I want an opinion, I don't need an exact answer every time. You know, look over these documents, tell me what are red flags, right? There's an arbitrariness to that, and it tends to be good enough a lot, and it also tends to be a lot of times where the speed increase is a bigger value lift than the loss of precision. So you say, okay, I guess it's good enough, you know.
SPEAKER_00Yeah, I mean that brings up the effect I'm calling the bulldozer effect. And people are talking about as token maxing. I just get enough tokens, I give the AI enough time, it'll figure it out. And I'm like, yeah, that's a bulldozer. You just bulldoze your way through it all and eventually get to the end of the road that you need to be on. But is it the best outcome? So let me reverse this back. Kiro, you started with the regulatory aspect. So our Customers are regulated in financial services. And we're not personally regulated as a company, but by virtue of our contracts, we essentially are like FINRA and SEC doesn't audit us, but our customers are. So we have to go through SOC 2 audit to prove that we are secure and capable and you know following principles. How does AI fit into SOC? So here's one of the rules in our company AI will never touch our production environment. We can't let it. And so now I think about the common user out there, and they're letting AI touch their production environment, their CRM, their system of records, maybe that's Dropbox or Box.net for files or whatever tools they're using. And I think as long as that AI was built in such a way that it was designed purposefully and it's backed by a company that that is their product, that is their service, you're more likely to have success than if you just go out and say, Oh, I'm gonna get open claw or I'm gonna vibe code my way through this. And if you're not an engineer, if you're not an architect, you don't know about simple security problems that are coming up and you're just pushing your way through, not realizing all the things you're breaking, rules or regulations, whatever, or creating openness and violations in your own security policies because you're not paying attention to it. You don't know to pay attention to it.
SPEAKER_02I think the word of 2026 that needs to get left behind is vibe coded. It reminds me of the unprecedented times on every email we got during the pandemic, right? Everywhere you look, it's vibe code this, vibe code that. What does it even mean, you know, at the end of the day?
SPEAKER_00Can I tell you my favorite thing about software development? We've always been vibe coding. We've always given words to an engineer and said, go build this. Like, why is it different? Just because AI goes so much faster, the compression of time makes it different. You still have to have good principles. You have to know what you're building and design it well. And that's to me, this is the biggest fallacy of vibe coding. It's not one prompt gives you everything you want, it's a really solid design with a lot of iterate checks and balances around it that get you what you want. And if you're not willing to put in that time to design up front, you should put 10 times more effort into design, especially since software can be built so fast to get the results you want. And then even then, it's not done. You still have to iterate to ref refine it and make it the way you you finally want it to be. Yes, I agree. Let's leave vibe coding out of this.
SPEAKER_03So vibe coding was actually originally a derogatory term, right? It's just I'm just gonna feel it out and and do it, which which how distorted, and then it kind of just stuck. But that's literally what it was. You know, I'm just gonna code by feels.
SPEAKER_02My version of what vibe coding is, which is some dude or gal somewhere in the world put on some house music, did something recreationally, and then a friend asked them, What are you up to? Laid back, I'm I'm I'm vibe coding, you know, having a vibe and same time. I'm gonna go with that. I think it's what it's way more interesting. Um, that's what I'm gonna believe in my head. Somewhere on somewhere coined that basically high, just doing a bit of code on on the evening and said, Hey, I'm vibe coding, and the rest is history.
SPEAKER_03Getting back to token maxing, it's funny. I was talking to a friend about a performance tuning because the cloud compute cost, which it the tokens are gonna get there too, that it's already starting, it's running people rumbling about the cost of the token. Now, people have already been complaining for a while that cloud compute is supposed to be cheaper than on-prem and it's not really anymore. I was telling him that as a best practice when I'm coding, I use a small compute because it it causes me pain waiting for it while I'm doing my development, then it forces me to optimize. And then when it goes to production, I know I'm not gonna pull out the machine, but I'm also not gonna pull out the the cost setup. Um, so for me that works really, really well. I'm not quite sure if it should put caps on your tokens and maybe force you to be more efficient. Maybe it's not a bad idea. Companies are doing that, but I don't know if that's why that's the purpose of doing that.
SPEAKER_00I look, I the way anthropic and opening eye makes money is by tokens. The more you spend with tokens, the more money they make, right? So they're out there telling everybody to just push more tokens and they're showing off internally, look how many tokens we're spending, and we're just I have 10 processes running at all times. Yeah, you have unlimited tokens because it's at cost to you, whereas the rest of us have to pay for it. And so everybody's promoting this concept of just use more tokens. And I think it's just nefarious. What is great design? It's efficient, right? Token maxing is the antithesis of efficiency. What do you guys tell your customers when they're talking about the movement of data and the storage of data and how we handle things? You're I'm sure you're talking about how to be efficient and effective with it, right?
SPEAKER_03Yeah, yeah, of course, particularly with Salesforce Project to the nose for storage. Yeah, yeah, absolutely. And Amazon developers are getting dinged for not using enough tokens. They're saying you're not being efficient enough because you're not using enough tokens. So they wrote apps to burn tokens and get their metrics up.
SPEAKER_02It's pointless. Of course they did. I think, look, I mean, any usage model, naturally, there's going to be a bias there to push it. You're right. All the postings and and you know, it's a catch 22 because you're supposed to use it to improve the tool, right? You're supposed to give it as much information and input and direction as possible. But there, therefore, you are using your credits. I think a lot of it's the better the devil you know when people talk about these vibe-coded solutions. Is a CRM perfect, whether it's a big name, Salesforce, or whatever, maybe not, but at least you know what you're getting and what you're paying for, is who knows with AI. So I think pros and cons, but in general, we're still in a wait and see phase, and there is a hype, and everybody's trying to get onto that hype, and then like we said, it's a race. So it would be interesting to if we're having this conversation a year from now, Rich, to see how you might have implemented AI into your business with the constraints of the industries that you specialize in. Has there been, before we move on, uh topic, has there been a certain use case for AI for QUIC that was a low-hanging fruit or super, super useful that you were able to embed?
SPEAKER_00So I have two answers for this. I mean, yes, there are things that we're doing that have made us way more effective. I'm in love with Claude, that's my favorite LLM right now. And it produces my contracts for customer contracts, it's proposals, and it's really just using it as a proposal generator and a contract generator. It's using templates and whatnot. And it's little things like that throughout the organization that is making life better. I'll give you another example. I encouraged my team back in January of 23 to figure out how to use AI. So my forms team came to me year after year after year. Rich, can you fix this problem we have with the forms process? It's cumbersome, it's slow, we don't understand why it has to be this way. Unfortunately, it was really, really hard to change because it had a lot of back-end steps that had to happen. It wasn't a front-end problem, it was a back-end problem. So they figured out they could get AI using a specific set of tools to do robotic process automation and therefore click the screens for them. And they took the cost down to $3 per hour, which was fantastic. Now they automated something they hated, and we got the benefit of low cost, and it's driving it really, really well. And it's still working to this day. But the second thing is I've noticed a much bigger problem, and it's a problem I've been working on since last July. And we've already used it here at QUIC, and I'm getting closer to making it more available. And that is we do everything on Amazon. So, what I've built is an autonomous AWS, Amazon Web Service software factory, and it has to adhere to our SOC2 and GDPR and all the compliance things. It has to give us control, it has to produce really, really high quality outcomes and high quality code and follow principles. If we're using something like a coding platform, it has to follow clean and solid principles. So, what I've actually built takes a design all the way through build in a development environment with near perfection, without any engineer doing the actual building work in the AWS side of things. And I did this for a couple of reasons, Carol. Number one, my team lacks AWS skills. We keep hiring very expensive consultants to do projects, and therefore we can only do a handful of projects at any given time, but maybe one or two a year, frankly, because the cost is so high. And therefore, we can't advance our business in the way that we want to. And two, we just have so many projects to do. I want to go faster, and I believe AI can help us get there. So, this idea of putting a lot of constraints around it, and Dave, to your point, it's also very efficient from a token standpoint, because it's not a bulldozer, it is a laser-focused process that employs the right techniques for the right problem to always create the right outcomes. I'm not saying it's perfect, don't get me wrong. There is no such thing as perfect. Uh, but you know, we did a project back in February with it where it took my engineer elapsed days, which included a weekend plus nights where it's not running, to just click and monitor the process, not do any coding. And the outcome was that product worked perfectly end-to-end on the first try. So that's going into production. By comparison, the same project was done a year and a half ago, really similar project. And it took three and a half people three months at a cost of $270,000. So to me, there's massive amounts of opportunity to create really refined process AI that are refined in such a way that they're constrained, they're deterministic to create the right outcomes and then save yourself time and money so you can go faster. And frankly, it's not going to replace people on my team, it's going to enhance what we can do as a company now.
SPEAKER_03Yeah, I think a big part of it is a level of documentation needed. So you're only talking about the 10 days lapsed, but I'm sure there was quite a bit of time getting a spec together to feed it in, right?
SPEAKER_00Well, because that's part of the product as well, is it does the planning for you. It's actually really fun. So if I can take you guys back for a second, I looked at the world of AI last year and I said, man, these different LLMs, they have different personalities, different behaviors, different quirks. That's why if you give the same prompt to three different LLMs, you get totally different answers. And so I started thinking, that's more like humans. So I started thinking of it more like a human and asking it questions. How many people have asked their LLM, what's the best way to communicate with you? Like inherently, why would you ask that? But I would ask that of you, Kiro. If we're gonna start working together, I'd ask you, hey, do you prefer Slack or S or you know, whatever? And we'd learn how to communicate really effectively together. So I decided to do that with AI, and that led me down a path of other things. One of those path frameworks was you always create a persona, you're like, hey, I need you to be my expert software developer, I need you to be my lawyer or whatever. I started saying, well, why can't you be a panel of experts instead? So the business planning process we go through, you start with what is your business problem? What are you trying to accomplish? Who does it serve? And then my system creates a panel of experts specific to your needs that you can change, you can add or remove. And then that panel of experts walks you through the debate on your problem to help refine it and get it clear. And then it goes to an implementation strategy, which gets another team together. Now maybe it's more of an AWS team or a database architect or what have you. And again, you get to debate back and forth with these elite experts. And it's quite it's really funny because it'll create these backgrounds. Oh, this person on your team has been a 16-year veteran at Microsoft. I'm like, no, they're not. You invented this, but it's just kind of funny. It gives a very human feel to it. So you have this really dynamic conversation with these experts, and it produces a plan, which I then take to my CTO and say, hey, debate the plan with me. What do you think? Should we change anything? So, Maz, to your point, this is why it goes faster. It's because we're using this panel to get through some of the decision making faster. And it is also constrained. I mean, we know we're doing everything in AWS, so we're kind of centered around what the tool sets are there. It's quite vast, but nonetheless restricted. But yeah, you do have to put a lot of time into the development of your design, that's for sure.
SPEAKER_02I think the good thing, Rich, is if you disagree with their opinion, you could just crop close a tab. There's no awkward in the room argument. No, I know. Well, that's the thing.
SPEAKER_00You're like, no, we're not doing it that way. We want, I want this way. Okay, no problem. We'll do it your way. We'll we'll design it your way, then it's fine. It it is hilarious. And we've all experienced how affirming LLMs are. So you have to be careful of that bias where it's like, oh, yeah, you have a great idea, great design. It's totally gonna work. And I've worked very hard to get it to tell me why it's not gonna work and where the real pitfalls are, so I don't make stupid decisions and carry on like it's gonna succeed. But this is the wild west right now. What can you do?
SPEAKER_03So getting back to AWS, do you think I was joking to my brother? My brother is actually a portfolio manager, so sometimes he asks me, like, what's going on in the industry? So it's funny, I was telling telling him that uh it's just a matter of time before Anthropic or Amazon gets sued, because Amazon bought, I think, 20% of anthropic, or they have a 20% stake, and like I think it's gonna start pitching their products for every software build as opposed to other, and you're gonna be back to the browser wars. It'll be interesting to see how that plays out if there's gonna be a bias there in terms of platforms.
SPEAKER_00That is interesting. I hadn't even thought about that. I'm biased just because that's where my infrastructure is.
SPEAKER_03Yeah, but you don't have a financial stake in the bias.
SPEAKER_00I don't have a financial stake. Man, I wish I did. It it could be like the browser wars, you're right. Yeah, we'll see.
SPEAKER_02So so moving a little bit onto the people side of AI, because there is still a people aspect, even though I think we've established in general it's good enough and we should utilize it more, but not rely on it. I think that's the general takeaway of both both your comments. So moving on to the people side in today's market, a software engineer, now that AI is here, what does that look like in your opinion?
SPEAKER_00Yeah, this is a question my CTO and I were asking last August. What is going to be the definition of engineer going forward? And I would say there's a couple of different approaches to this because engineers are not going away. Let's go back to vibe coding. It's creating a lot of garbage and there's a lot of garbage cleanup happening. There's a lot of people who are frustrated and therefore they're bringing more engineers on. Frankly, we're having a hard time hiring engineers right now. And I think that's because the whole world is hiring engineers again to clean up what AI is not doing well. So I don't think engineers are going to go away, but I do think AI in general can elevate people into higher thinking roles. So the role of an engineer should become higher thinking, more design, more architecture, more enforcement of principles that are good standards, because AI by itself doesn't enforce standards. It may know standards, but it doesn't choose to use them. You have to enforce that. So I think the engineer's job is to curate and monitor and push the AI to the boundaries that engineer needs. I think the biggest struggle we're going to face is how do you get somebody to go from entry level to senior engineer now? If a lot of the entry-level work can be built by AI and you're having senior engineers do that work with the AI to do it, how are you going to get trained well enough to become a senior engineer who can then manage the process and run a team of AI people? I suppose we could have made that argument when we went from assembly to basic and basic to you know third generation and fourth generation languages. You know, who's going to be able to do that work? It's going to be a migration problem. But yeah, I generally think the definition of an engineer should be somebody who is managing more of the process and designing more of the process to enforce the principles of the process, not necessarily writing the code. They might still write the code, they might still find it easier and faster to fix things. Kira, this brings up a whole different idea. What I'm building as an AWS factory won't be the only one out there. There's going to be others out there. There's going to be other types of factories out there. And so it's going to come to a point where you just buy a tool. Who operates the tool? Do you know who's having the most success with vibe coding right now? Non-engineers, product owners, designers, people who have just ideas. They're having the most success because they're curious and they're investing in it and they're not tied to any kind of preconceived notions of it. I'm not saying they have the most security or the most scalability, most performant systems, but they're having the most success as an outcome of vibe coding. And so there's got to be this mesh of designers and people who have these ideas with engineers who can actually make it work the right way. Oh, I was gonna say because they have lower standards. That's why. Well, there is that. I'm honestly, there is that. They just don't know what standards to put in place.
SPEAKER_02So yeah. I mean they could have they could be better thinkers and visionaries, right, of the product. Whereas historically, you you know, you do need code to build an app, right? Is it a bad thing that non-technical minds are now able to build, design, and implement a product? I think it's a great thing, but like you like you said, everything within reason there has to be a level of quality control, otherwise, there's gonna be just too much noise out there when it comes to applications and everybody's gonna coin themselves as a coder, which features.
SPEAKER_00We have a second stage coming. And the second stage is more along the lines of what I'm building. I'm super happy for my product owner to go on to Manus or Vercel or Lovable and build a prototype, an amazing prototype, a functioning prototype. But to put it into my production systems, it better go through a software life cycle. And that's where I think the second wave is. There's gonna be more and more solutions to take a prototype into the full software development lifecycle so that you have that kind of control and audit, etc. So there's another concept that I think we could address. If AI can write the code and the code ends up working, do you care what the code looks like? I'm gonna say yes, by the way. My initial response was no, I could care less what the code looks like. But what I actually care about, it's not that I read the code, is that it follows high quality principles to achieve high quality outcomes for maintenance and durability and low fragile, non-fragile systems. And that's where the vibe coding is losing right now. You're not getting to that point. You're just saying, well, it works. I lost the app, I'm making money with it, or whatever. So I think there's a fallacy in there in the second stage coming.
SPEAKER_03Do you think that when you're having your your agents or your bots or the LLM generate code, that at some point we're going to be more concerned about the next iteration of LLM's understanding it as opposed to people? Right now that you work, there's a working assumption that if the code is readable and maintainable by a person, it's also more readable and maintainable by the AI. And I don't necessarily know that that's true. It may very well be. Yeah, what are your thoughts on that?
SPEAKER_00I I think by default, the LLM's not writing the best code, it's writing okay code, it's getting it to work. I'm gonna give you an example of this. At one point early on in my process, my system, my agency system, hit a roadblock. And what I needed it to do was enhance existing steps. There were four steps I needed it to enhance. It didn't understand the word enhance, literally did not understand that word. So, what did it do? It wrote 64 steps around the four because all it understood was add. I'm going to add this step to this step to this step. It was called an explosion of so I ended up with 64 microservices to compensate for four that just needed trivial enhancement. And of course, I blew that all away. It started over and I figured out how to fix that problem. But my point is that the LLM has no judgment on this, it's not inherently biased towards high quality. So, yes, you need people to enforce these standards. You need systems to enforce these standards. And I would argue that this is something my CTO said, and I actually agree with him. Software development coding is a known quantity at this point. There's so many examples on the web to do things. It's not hard to find how to solve problems at this point. What is the new software? It's not really new software, it's just implementations of the old over and over and over again with different needs, different outcomes. So, therefore, the LLM has the ability to write that, but you have to get it to write it well.
SPEAKER_02I think one of the things that you mentioned with what does a software engineer need today, or you know, with the question was defining a software engineer now, what really stood out to me was system design. You mentioned system design a couple of times. I think we are moving away from the ability to at the speed, code fast, memorize syntax, things like that, to problem solving, product ideation, system design, like you mentioned, the architectural design. And that's where the elevational skill set comes in. So your mid-to-senior engineers are going to move more into what was traditionally coined as architectural and allowing everyone to kind of step up. But to your point, how do the juniors get to mid-level? Is it improving what were traditionally soft skills? You know, communication, problem design, use case type stuff, right? I don't know. What do you think?
SPEAKER_00Yeah, I don't know either. I have not chosen to become a professor at a university to solve this problem. And I think there's some really smart people who are going to figure it out. It's partly this transition from I'm a coder to I'm managing A2, managing systems. But I think you kind of said it as you put this the whole question. We need more people who have systems thinking. And honestly, this is one of the biggest challenges with AI in general. If you guys understand the concept of context window, and for maybe the audience who doesn't, context window is the amount of memory effectively the LLM can have at any point in time. It's no different, in my view, than RAM on your computer. If you have 32 gigs of RAM, you can run so many applications at once. So the context window for an LLM is how much it can hold in memory and therefore diagnose and use to come up with answers to the questions you're giving it. It's limited. It got really, really big a few months ago. It went five times bigger, went from 200,000 to a million tokens on Claude earlier this year. And that's amazing, but it is still so, so limited. Sarah, let me bring this back to your audience's perspective. In the world of CRMs, one of the biggest advantages right now is note takers. There's a note taker on every meeting, Fathom, Zoom has their own. There's there's 26 different ones in the wealth management space, etc. Assembly. I just actually interviewed the one of the co founders of Assembly. Super cool. They were in it before this all came out. Anyway, the the the idea here is these note takers are listening to your meetings and putting data into your CRM. Okay, great. So that's an ingestion of some data. Let me ask you is every single Conversation being put into the CRM around that customer? What about the one that you and Dave had about the customer? Did that get into the CRM? What was everything put into it? What about your business and the changing dynamics of your product set and services? What about the economics of the world? Do you think an LLM can actually know everything? It can't. And so, how do we give it enough context to help us truly make sense of the data we have to help us with the processes that we're trying to automate and know enough to give us the right outcomes or the right answers to questions? This is why the human is so important. You can intuit something about your clients, preferences, needs, you know, abilities, behaviors, et cetera, that no LLM's ever going to know unless we just convert all data into LLM data. I just don't see that happening. There's too much going on that isn't being captured. Does that resonate with you?
SPEAKER_02Definitely. I mean, I don't think every interaction and conversation should be imported into a CRM. I think giving too much context can also be a disservice, right? It's finding the balance. And I think that ultimately there's no blueprint to this is exactly what you should put in. It's all test measure learn. Every use case, every purpose is going to be different. And everybody's level of comfortability and trust is also different. For me, I'm still in the curious phase. I'm still skeptical as well. I think everybody's got different, like you say, when you invest in the topic of investing, you have different risk levels, right? And I think AI is still about that. But on the topic of hiring and people and AI, you recently had your own experience of going out to market to hire a software engineer, I believe. And some of the negatives of AI were present during your experience of going out to market, not through Third Republic. I will say that just to face this story. So tell us a bit about as a hiring manager trying to hire software engineering skill sets today with the noise of AI. What was your experience? What was your story and some of the things that you have since instilled as part of your hiring process to eliminate that risk?
SPEAKER_00Yeah, it's hard. So look, the the basic story, but the I'll tell the fun story in a second. The basic story is something around 70-80% of the applications we're getting are generated by AI. There's only 20 to 30% that are actually real applications right now. It is so incredibly overwhelming. 1,500 applications we get and a few hundred are real. It's astounding how much work it's causing us to try to figure out who's real and who's not. Um, but the fun story is fun, call it that. We we went through a process and we go through the a method of hiring, which is a very, very strict method of hiring for software for the software engineering role that we're looking at. Somebody finally got through the screening process and then went to what's called the top grading review, which is a 90-minute conversation. We're asking questions and grading the person on these capabilities that my CTO performed, and he's very skilled at this. That person got through that process. And there were two other people on the call from my team witnessing it. They were just observing, got through that process, came to me. I had a 30, 40-minute call with this person, and this is all on Zoom, of course. And I concluded this is a great fit for what we have, what we need, and culture, et cetera. And so we said, okay, we're gonna make this person the offer, but first we're gonna do the reference check. The reference checks failed, and our hiring team thankfully was very skeptical, very cautious. When they called the first reference, they heard some things that were like, This sounds robotic. This person misgendered the applicant. They're like, that's weird. But then they called the next two and had the same experience. All three, and these are people who supposedly work at Microsoft, Google, Amazon, really big name companies. All three of the references sounded robotic and misgendered the applicant. I'm sorry, he has a very male-dominated name. So there's very little chance that the name would be a misgender. Uh, the other thing was all the phone numbers for the references were VoIP numbers, and all the emails were non-domains of the companies. It was like Gmail and Hotmail. So we stopped. We're like, no, no, no, this is not right. And then I went back and reviewed the videos of the different interviews. The candidate had the identical clothing on every time, even weeks apart, identical outfit. And as you start to watch it with a skeptical eye, you'd see the person look away, think thoughtfully, come back with a perfect answer. This is why they made it through the process. Like they were so amazingly qualified. Lo and behold, I discovered 60 minutes doing this segment on North Korea, sending out applicants who are taking over people's identity to get jobs, to get the first paycheck and send it back to North Korea. And I can't validate whether this person was North Korean or not, but certainly fit the bill. And there's other red flags that you have to pay attention to. The person had only four followers on LinkedIn. Come on, if you're a senior person, you've got 10 years experience. We found the actual person whose identity had been stolen. And it was crazy. So, yeah, we've implemented new steps up front. Nobody's getting past this step without an identity verification step up front, and that should eliminate a lot of it. But we're just a lot more skeptical now. And I'm never going to give up my rule, which has always been I meet people in person before I hire them. And this was almost an exception because the person was outside of our area, nobody lived close, like different state, different city. And we were we were so excited to finally have somebody of quality. We were almost willing to overlook that. And I'm like, nope, I will fly the person out to see me in person if that's what it takes. It's a crazy world, Kiro.
SPEAKER_02It really is. I think there's some great snippets of advice there for companies because this isn't a you or quick problem. This is a global problem. It's sad because it's really only impacting those who are genuinely trying to look for jobs, right? Because uh more and more companies are not going to post their jobs and um are gonna have this kind of you're starting off a relationship conversation with a you're kind of trying to catch somebody out from the get-go, right? And if you've got somebody who's already known about an interview and so on, it's just a negative way to go about hiring. But unfortunately, it is what it is, and this is a world we're now living in. I think in person absolutely is a must. But if you're a what let's say one of the companies you mentioned at Microsoft and you're hiring a thousand people a month, who knows, right? How do you do that at scale? That's a big question mark, right? That becomes very expensive. I'm skeptical of references. You add one example. How do you know I could give my mate a number and say to you, Rich, hey, this is my former boss, Maz. I put on a voice with a talk like this, and say, Oh, good things. You've got no way of knowing that's me or not, right? So, or if it's Maz or whatever. So I think the LinkedIn presence, the social footprint is becoming more and more important in today's market for employers and also employees to ensure that you have got some kind of social proof. You're at meetups, you're at conferences, you've got mutual connections, you've got recommendations on LinkedIn, which are more valuable than references. And we talked about this in one of our episodes prior, so I won't go into too much detail. But the ID check is a good point. Physical ID, waving it in front of their face. You can spot straight away if it can't do a hand-in-the-face movement, it messes it up.
SPEAKER_00This was a real person. They were using AI to answer questions, but it was a real person.
SPEAKER_02They were just mimicking, yeah.
SPEAKER_00They were just per impersonating somebody. It was crazy, honestly. I think we are putting a lot of trust and faith in LinkedIn at this point to make sure they're keeping people real. And yeah, I and I'm grateful that they're using clear. Do you know the airport company clear? Yeah, they're using clear for identity to verify people on LinkedIn so you can get more proof that people are real. As long as they don't let AI build somebody's followership by 500 people overnight, that might help. No, it's a real problem. And I think this goes back to the whole premise of anything we're talking about. It is the human connection. The whole idea of the CRM was to create better human connections with people, not to relegate somebody to a data record. It was so that you could remember their birth dates and their important things and serve them better. And so the hiring process has to remain a human endeavor. And what we get by having a conversation like this as humans. I think you wrapped up the podcast beautifully there.
SPEAKER_02So nothing else better to add other than we say thank you for joining us today, Rich, as a guest. Really interesting story. And I'm sure if individuals have questions about your thoughts, opinions, they can check out your podcast. And also, if they're curious to learn more about Quick, I'm sure they can reach out to you directly on LinkedIn as well. So thanks for joining us today. Thank you, Rich.
SPEAKER_00My pleasure. Thanks for having me, both of you.
