➡️ Summary ➡️

Chuck Liddell, founder of Valence, shares the journey of building a fully native Salesforce integration engine entirely in Apex. From writing Apex triggers for beer money in college to joining the first Salesforce Incubator cohort in 2017, Chuck discusses the hard lessons of transitioning from consulting to ISV, the technical gymnastics required to handle governor limits at massive scale, and how Valence can move a million records in 90 seconds without ever leaving the platform. The conversation covers selling into federal government and GovCloud, finding unexpected product-market fit in higher education, and maintaining integrity through a no-referral-fee SI partnership model.

➡️ Guest ➡️

Chuck Liddell https://www.linkedin.com/in/chuckliddell/

Valence https://valence.app

➡️ Takeaways ➡️

Valence is a fully native Salesforce integration app built entirely in Apex with no external servers or middleware

Transitioning from SI to ISV requires singular focus — trying to do both simultaneously is a costly mistake

The Salesforce Incubator first cohort in 2017 provided critical mentorship and connections for early-stage ISVs

Being native on platform eliminates third-party data exposure making it compelling for security-conscious industries

Valence moves a million records into Salesforce in 90 seconds using highly parallel async Apex rather than the Bulk API

Higher education emerged as an unexpected niche due to complex integration needs

SI partnerships drive significant deal flow and Valence maintains a no-referral-fee policy to preserve integrity

Building a public persona as a technical founder is essential for ISV growth even if it does not come naturally

➡️ Youtube ➡️

Watch this episode on our Youtube channel

➡️ Good Day, Sir! ➡️

https://www.gooddaysirpodcast.com/

➡️ Keywords ➡️

Salesforce ISV, native integration, middleware, Apex, Valence, AppExchange, Salesforce Incubator, ETL, governor limits, higher education, GovCloud, SI partnerships

➡️ Hashtags ➡️

#AppsemblyLine #Salesforce #ISV #Integration #Middleware #Apex #AppExchange #Valence #NativeOnPlatform #SalesforceISV

Mentioned in this episode:

Sponsorships

Advertise on AppsemblyLine to elevate your brand and connect with a passionate community of leaders!

Sponsors

ISV Forge

Accelerate Your AppExchange Success!

ISV Forge

Simplify Your Salesforce Security Review

Get clear explanations, actionable insights, and step-by-step guidance to pass your review and get to market faster.

Security Review Partner

So I'm really excited today to be sitting alongside a Salesforce legend with Chuck Liddell. Welcome to Appsembly Line Chuck.

Good to be here. Thanks for having me.

Yeah, I'm really looking forward to talking about your journey into the Salesforce space and specifically sharing ⁓ the founding story of Valence. So maybe just to kick us off, if you wouldn't mind sharing how you got into Salesforce, how you came up with the idea for Valence and what problem specifically the app solves.

Sure. So ⁓ the relatively concise version is that I started doing Apex triggers for beer money in college. And that's how I got into the ecosystem. ⁓ My dad was actually a Salesforce consultant and hired me to write some code. And she said, hey, Apex is like Java. I you know how to do Java, so you can probably figure this out. So I just started picking up like little Apex gigs here and there.

⁓ But fast forward a long time and through several iterations of stuff I was doing, and I ended up kind of running a consultancy of my own, a small group of software developers doing Salesforce work, kind of specifically focused on...

complex architectural challenges, larger enterprises that had unusual things they wanted to build. And we sort of specialized in sort of those tricky, more complex projects or existing code bases that had kind of gone horribly wrong. And they need someone to like come in and clean up. So was a small team, very focused on like highly technical projects. And as a natural byproduct of that.

we ran into a lot of integrations, right? Over and over and over, part of these monster projects was like, how do get all these things to work together? And we were sort of repeatedly disappointed with what existed for kind of two reasons. One, there's a lot of off the shelf stuff you could buy at the time, Jitterbit and Informatica and, you know, early meal soft and stuff that was sort of turnkey, but if it didn't do exactly what you needed to do, it wasn't very customizable.

So it was great if it did what you needed, but if there's something unusual or custom, then you're sort of out of luck. You'd just not use it at all. And the alternative was to write everything from scratch.

Right. You're a custom Apex call outs, know, custom framework, you know, some sort of management system for how you're going to chain things together. It was sort of a huge pain in the butt. And we really were craving a solution that sat between those two extremes that was, you know, not, could be turnkey, but it was more about having like an engine meant to be built on top of meant to be extended. ⁓ that allowed you to skip a lot of the boilerplate for integration. So the valence is an integration app that lets you move

data between Salesforce and other business systems. It lives natively in Salesforce. It's an app exchange app written in Apex. So with that context, we're trying to help people to skip identifying schemas and

wiring up the metadata, what links to what, right? What are your mappings and what sort of transformations exist and how do you handle errors? How do you recover gracefully? How do know what happened? How do you handle scale? A lot of those questions are completely identical across integrations, but then you get into like the extra layer on top of like, but this integration is to an old system that has this very unusual file format. It's like text delimited based on length, like byte length, because you have to

accommodate that, but those details, intricacies tend to exist kind of more on the edges than in the center of like the core engine that you're building. So we went to the Salesforce incubator in San Francisco and started working on the first version of the project. And that was a long intro, so I'll see what you have to think about that. Yeah.

And this was back in 2017, is that right?

Maybe you could, so first off, that's really interesting. I definitely want to talk about the fact that you're fully native. So there's zero middleware involved in Valence.

Well, it is middleware, but it's written in Apex.

Fair enough.

I'd say that makes you all unique in that you're inside the Salesforce, right on top of the platform and natively working as opposed to a lot of other vendors that live outside of the Salesforce system. But I also want to chat a bit more about this incubator you joined. I'm sure a lot of viewers and listeners are familiar with

⁓ incubators like Y Combinator, Techstars, things like that, but maybe not the Salesforce specific incubator you're referring to.

Yeah, so at the time that my consulting group, which was called Kapa Honu,

was thinking about this product, like coming up with this solution that we could reuse on different projects was sort of a reboot for the Salesforce incubator had existed in the past. And then they kind of shut it down for a while. And so they were restarting it was sort of version one of the like brand new program, new cohort of companies coming in to be part of it. And so we kind of heard through the grapevine. We're pretty well connected internally that there was this incubator was going to get rebooted and they're looking for applications for

companies that wanted to pitch. basically you would say, here's an idea for something I want to build, right? can early stage and here's why I want to build it. Here's my team. ⁓ There was no money that changed hands. It wasn't like money for equity or anything like that. But what you did get is they gave us space to work. So we worked out of the Heroku building in San Francisco. You had to commit to coming out, I think, I don't know if it was three months or six months. So you had to come out for a good chunk of time.

⁓ with a couple of people on your team and just live in San Francisco and cover the incubator every day. And they'd give you a lot of mentorship and connections, right? So if you had questions about a product feature, like you could talk to the team that built that feature in-house, right? You direct access to a huge amount of people that could help with what you're building. And then a lot of like startup coaching too, right? So there's a team of people that were very well-versed in helping startups. Mike Creeden was the main guy, very, very talented Salesforce employee, really good with startups. And so he kind of led a team of people that were

helping to develop these ideas into real products. They're just trying to literally incubate better App Exchange apps and helping people with ideas get from idea to app on the App Exchange.

That is so cool. Is that incubator still around? Do you know?

It is, but it changed pretty quickly within a few years from in-person to remote. So it was only a couple cohorts that were there in San Francisco. Ours was the first one. And then a couple more after us, and then they shifted to remote. I think they're still running it now, but it's fully remote.

Okay.

Okay.

Okay, well very cool. We'll have to do some, what is the name of the Salesforce incubator? Or is it, that changed? Okay, there you go. Well, I was gonna,

Shockingly, the Salesforce incubator. At least it was at

the time. I think they did rebrand it to something with a startup and the name. Yeah.

That's what I was going to say. They probably have rebranded, right?

Mm-hmm.

Okay. And then you joined that program just as an idea based on the consulting work that you'd been doing. They helped you flush it out into an actual offering. By the time the three months or six months or whatever it was, over, what stage were you in then? Did you have your MVP? Were you still flushing that out? Did you have beta customers already?

So let's see, we had advantages and disadvantages relative to other people that were in the cohort. I'll kind of describe what I mean by that. ⁓ I, at the time, was part of an incubator in Hawaii on the mentorship side. I was helping to evaluate companies with their technology, see if they were a fit for that incubator, help to review their applications, and decide if they should be in the program or not.

So I had a lot of background and sort of context and just sort of startups in general and like how people were taking ideas to market.

Um, and because we were coming in as a technical team, we had a really strong vision for what we wanted to build stronger than most people. Most of you had kind of like, this is sort of what I want to build, but we watched in the dark and this is exactly what we want to build. Like this is, we had a strong vision based on real context from projects. And specifically it was like, we want to build something that is, um, a library, right? Really just a library for Apex developers and engine that, um, you could extend. And so we just wanted to build an app specifically that was like.

Mm-hmm.

that base layer, right, like a foundational element. ⁓ And it came from a place of frustration really, right, which I described earlier. There really wasn't this like Goldilocks problem of too small or too big. And we were just super frustrated as consultants. Like I think that if the product like this had existed, we never would have built it, right? We would have just stayed consultants and use whatever had been made. But because there was just a hole in the market, ⁓ we took it. So those are some of the advantages we had. Disadvantages were we walked in the door with an existing team of people that were consulting.

And so we had payroll needs and made a bigger team than we needed for a small project like this. And we had existing customers and existing projects. And so we really distracted while we were in the program. It was a big challenge for me specifically, was trying to continue to run a consulting company while also trying to participate in this program and help to craft the shape of what we were building our app that we were creating. And trying to balance both those ended up being really problematic.

Hmm. This is kind of a theme that's come up before on the show, the importance of focus. I know ⁓ there's a number of apps on the AppExchange that have followed a very similar path, that the idea, at least in its infancy, came from ⁓ consulting work. And... ⁓

Some companies then transitioned ⁓ fully into being an ISV rather than an SI. Some tried to kind of ride the rails between both. And I think it's very difficult. I have a lot of respect for ⁓ individuals and organizations that try to do both at the same time, because I agree it can be distracting. I think that was a good way of phrasing it. So ultimately, you did, it sounds like, drop the consulting and focus solely on ⁓

on valence, is that correct or no? Are you one of the individuals doing both?

We're no longer doing any consulting work.

Okay, okay.

⁓

But that was not an easy place to arrive. And I'll be candid, and I've told this story elsewhere too, it's not a secret. But when we finished the program, we had ⁓ a V1, right, like an early candidate of our library, and it was not good. It just wasn't what we wanted it to be, it what I wanted it to be.

⁓ Vision hadn't translated into reality very well. The technology wasn't quite right. The look wasn't quite right. The way he interacts with it was too confusing. And it was nobody's fault but my own, really, right? Because in the program, I had taken some developers with me and said, OK, we're going to work on this together. And then I...

wasn't around that much, right? I was still focused on the, customers. Part of running a small consultancy is they always want to talk to the top guy, right? When there's a problem, they always want to talk to, talk to me. So was on the phone with the angry enterprise customers about something or other, trying to calm them down and focus on the fire. So I was putting out fires every day. And because I had part of my team working on this project, they weren't billable, right? And so revenue was down, payroll was the same. I was doing a little bit of both. And so I made a couple of bad decisions and I'm sharing them because

it would help people avoid to make similar bad decisions. ⁓ The first bad decision I made was to split our attention so much and try to keep doing both. I thought we could do both at the same time and that was a mistake.

Appreciate that.

The second bad decision I made is not realizing fast enough and then trying to extend my runway with money. So I took out some business loans to make payroll so we could keep going and finish the app. So I went into debt and I burned through most of the money and realized I still had the exact same problem. I still wasn't making more money than I needed to pay my people and the app wasn't good quality. As we came out of the incubator, we were getting down into the last bit of the money and stuff. And so I was like, now I had extra debt.

Mm.

And I ended up having to the decision that I should have just made from the beginning, which is, hey, ⁓ some of us want to go build this app. And not all of us can come on this journey.

because we just can't pay everybody. Like this is something that we're to have to sort of bootstrap and reset a little bit here. So, you know, hands up if you want to participate in this new endeavor, ⁓ you're going to get paid less and it's going to take some time, but maybe you'll get some equity and some value down the road. And, if you don't, that's totally fine. I mean, we know a lot of other companies in the ecosystem and we'll help, we'll help find you happy homes. Right. So reached out to a bunch of different CEOs that I knew and different SIs and just said, Hey, I got a great team of people. They're really fantastic. They need a place to work. ⁓

and got people referred and sort of recommended. ⁓ And so we just cut way down, probably reduced our head count by 70 % and ⁓ just sort of refocused on building the app and just building the app.

Yeah, I'm sure that was a very, those are some dark days. That's a tough decision to make as a business owner. Even when it's the right one, it doesn't make it easy. Yeah.

It's hard to see in the

moment.

Well, good on you for, it sounds like doing right by your team, ⁓ helping transition those to new roles that weren't gonna go along in the journey. ⁓ So shifting gears back to the journey that you did go on, you finished the program, the apps is not where you want it to be. ⁓ You've now maybe like stopped the...

the bleeding, so to speak, by cutting payroll costs, but you still need to work on the top line, right? ⁓ Did you just go heads down into developing better features and working on the NVP, so it was where you wanted it, or did you have to transition to sales mode and start getting some actual revenue?

So we had a period where we had no revenue, ⁓ which we just kind of had to squeeze through and get past it. ⁓ We had a couple of advantages in that this came from...

a place that we knew really well. It came from the projects that we had done that were very similar. We essentially built little versions of this tool earlier in our careers, right, several times, individually for different customers, way less sophisticated versions. ⁓ But the ideas that we developed were pretty refined. And so we were able to do two things. We were able to just start over, like literally.

Mm.

we started from the first page again, new first line of code. We just toss out the whole V1 and start again with fresh code, brand new, day one, ⁓ but all the learning, both from our industry experience and from building the first version. So the second version came together really quickly because we knew what we wanted and we just kind of were able to focus on it. So that's kind of part one that was helpful is what we knew we wanted. And then part two is we had a lot of these customers that we weren't necessarily doing projects with anymore.

Ugh.

but we knew and so it wasn't hard to get people to kind of test it and look at it and ⁓ kind of qualify it compared to their own customer use cases. So I feel like we had a lot of really good sort of iterating on market fit ⁓ early because of the connections we had had and because of where we came from as a team that helped us to kind of get it in a good place quickly.

Mm-hmm.

That's great. Well, and also, even if you had built out some integrations as an SI in the past for these organizations, I'm sure as time goes on, they need to build out more integrations, right? And so now I guess you're offering them this application that would make it easier for them to build new ones as time goes on rather than having to continue to go back to the well and hire another SI to do more projects.

Yeah.

And, know, the classic sales tool of, uh, Hey, you're getting it on the ground floor. I'm to give you a great deal. And since you've been such a great customer for so many years for other stuff, like you should get a great price on this new thing that we're building. That's a good incentive.

Yeah.

Yeah.

So that's how you got your first early customers. How did you maybe go beyond that? ⁓ How long did it take for you to get that first customer that was an unknown entity before, you know, from your consulting days? know, someone just wasn't a referral.

Yeah,

that's always the leap, right? From like your network to out of your network and doing a deal with someone that you've never met before and really had no idea who you were before you guys started talking. ⁓ I would say that word of mouth was very helpful for us early. There was a hunger for a tool like this in the market. And I think that once people started to learn that it existed, ⁓ they started to come find us. We had some pretty decent inbound.

in the early days. But a lot of it was actually kind of one layer away from our network. So it would be, you know, folks like you that are doing project work and know of us through, you know, being colleagues and peers in the SI space in the past. That would be like, oh, OK, those guys that were working on that new integration thing, I have an integration need for this project with this customer. And like, maybe I should go find those guys. So we pretty immediately started getting a lot of

deal flow, not necessarily through customers that found us directly or that we found them, but through ⁓ architects and developers and other people that were involved in projects that needed a piece of the puzzle solved. And that was the integration element.

That makes sense. Well, I mean, you've been heavily involved, I say, in the ecosystem for a long time. We were just chatting before hitting the record button about some of the sessions you've done with Don Robbins on helping developers learn the platform. So I'm guessing that...

Not that you did it for this reason, but I'm guessing that you then from all that ⁓ volunteer work you had done and giving back to the community, you then had a network you could draw on, right? Like you were saying of folks, professionals in the ecosystem that knew of you and knew of Valence.

Yeah. So, ⁓ I'll be, I'll be Frank, which is that the persona that you know, right? The one you're talking about now, the public speaker and the influencer and the person that's involved in all these projects and stuff. It's a direct result of the Salesforce incubator batch one. ⁓ or I went in and I was a technical founder, right? I'm really a CTO who happens to have started the company. I'm not, ⁓

Okay, please.

natural sales or marketing guy. I'm all about the tech and the architecture. It's exciting to me. ⁓ But in the first cohort, Mike Creedon, the guy I mentioned earlier said, hey Chuck, you need to be public. No one has any idea who you are.

And you need to establish that you are an expert in this topic. You need to establish that you are a thought leader and that you can be trusted by the community. And so you have to become a public persona for to grow, for this company to work, you need to become a figurehead, someone that up. Now, not like no posturing, it's not fake, but you need to like show people that you can walk the walk, that you know this stuff.

so I had to really transform kind of who I was because at the time I was very careful not to be that public. I liked being just a guy that ran a team. ⁓ so I had to really like change my behavior completely. And I started doing a lot of public speaking and participating in a lot of things. And it was really honestly a direct result of being told I needed to in order for my ISV to work. But I had to do it. Getting a lot of value out of it for a lot of different reasons, but that was the original genesis of it.

Hmm.

Well.

Wow, well that was really sound advice. hope ⁓ you're able to send him a box of chocolates now and again to thank him. You were very involved, I know, setting up the extracurriculars for TDX. I can recall seeing you at ⁓ Dream Forces with the sash. I'm not sure if you still wear that anymore. But you had fooled me that that's not your natural, you're naturally more introverted than that. ⁓

You took his advice to heart, I could tell.

Yeah, it helped that I had passion for things, right? Like the extracurricular, which you mentioned, was like an embedded community track at TDX for a number of years that came from my own sort of personal...

angst about there not being enough like really complex technical material for people to consume. So there's a lot of like introductory admin stuff. There's a lot of introductory developer stuff in this space. And this is, you know, years ago, things are different. This sort of pre trailhead being more robust and pre there being more content of different types. But when you got to a certain level, sort of like the advanced engineer level in the ecosystem, it became very hard to keep growing and learn new things, especially like best practices, like truly best practices that people were

adopting in the real world on complex projects. Most of the people that build the most interesting and complex things have no time to go to conferences to talk about it, right? Because they're engineering and they're architecting and they're very well regarded and very busy because they're so good at what they do. So it was really about getting people that had that level of knowledge, but also were

capable enough speakers to convey the knowledge in a way that was digestible, together to present and talk and really try to hit a higher tier of complexity in the information that's being exchanged at these conferences, just for everyone to be able to learn more interesting things that once they kind of peaked with what was already out there. So that's really the byproduct of that was just my own desire to see the marriage of complex technical and education exists better in the ecosystem.

Well, you mentioned earlier that you were getting a decent amount of inbound. And I'm curious what channel specifically, mean, were people just reaching out to you that knew of you because of you following Mike's advice and becoming more of a figurehead in the community? Or were you seeing a lot of activity like on your app exchange or just...

⁓ lead forms on your website, where were you specifically seeing that that inbound come from?

⁓ So it was a couple different ways. ⁓ We did a very basic Web2Lead form on our website early and we would get occasional like, you know, here's a little outreach from somebody saying, hey, have this use case, do you guys do this? A lot of like, you know, discovery kind of stuff of like, is this a tool that can help me with X or Y or Z ⁓ through the web form?

And the other was just where people would find us. People would find me at conferences. People would come up to me after talks and ask about the product, either because they knew to look for me there or they just heard about it in the talk in some way they're interested. So I got a lot of just word of mouth directly. People would walk up and talk to me about stuff and that led to opportunities as well.

So when you when these talks you were giving ⁓ were they sponsored talks where you were ⁓ talking specifically about the app or is it that you were really just talking about integrations and the app would be mentioned in passing or something and

So they were not sponsored talks. They're always organic talks submitted through a call for papers to a community conference or to TDX or to Dreamforce. And I tried to...

There are couple of different goals here. One is to be a thought leader, like Mike Creedon said in the beginning, right? I needed to talk about something with comfort and skill and demonstrate that I understood the topic really well and share knowledge. Part two was I just wanted people to learn cool stuff. We've done a lot of really technical, interesting things in our careers and with the app, and I really wanted just people to know more. So was very motivated for them to learn.

⁓ and then third, I needed to mention valence to have balance exist as just sort of like part of every conversation I was having in a way that wasn't like a sales effort. Like I wasn't just pushing balance on people. wasn't like hyping it, but, ⁓ I had kind of a rule, which is that if I give any talk.

that didn't involve valence in some angle that it wasn't an appropriate talk for me to give because I was trying to make everything I did about like helping to build my product and build my company. So I'll give you examples. I would give talks about, you know, integration challenges that exist in the ecosystem. I would give talks about specific features like scaling and apex in an asynchronous fashion, parallel processing kind of stuff. ⁓ I give a talk.

Last year, the year before, ⁓ about our syntax we came up with for sort of describing schema in an indirect way. So if you ⁓ have like a nested list with nested objects inside the list, like how do you describe which entities in the list you're interested in? Is it a singular or is it a couple or is it a pattern that has to be matched within the list? And so we came up with our own like a syntax for describing, we call it property path, but it's a syntax for essentially just reaching into a structured data set and referring to elements within it.

⁓

And it has sort of like a indeterminate and then like a resolved form, very similar to like XML path and other stuff. So I give like a really sophisticated talk on how we design that and why we design that and what did it do for us. ⁓

And that's real. That's all about valence. It's a valence feature that we invented, but really it's more than that. It's about how do you solve hard problems and here's a hard problem, here's how we solved it. So I always try to find a nice balance of like, this is about what we do and what we build, but also it's really interesting and helpful.

Very cool.

I've sat in the audience of some of those talks actually. That last one you were discussing, I remember that Cactus Forest, ⁓ which you're actually, I believe, very involved in that conference as well. ⁓ So good stuff. So, okay. ⁓ Now I'm curious, like, fast forward to today. ⁓ Where?

without naming names, I'm curious like what kind of industry or market you're focusing on. Are you looking more like SMBs? Because I feel like your tool is very horizontal in that it could work for anybody. And it also could work for organizations of any size across those different industries. So I'm curious if you're specifically looking at ⁓ SMBs that don't wanna go the mule software route, ⁓ or are you working in very large enterprise organizations as well?

So ⁓ I'll describe that really thoroughly, because I have good read on that after years of trying to answer that exact question. You're basically asking our deal customer profile, right? What are they like? And so I'll answer that. And then we probably should talk a little bit about the architecture. We haven't gotten into it yet, but building something like this sophisticated on top of native APEX has real challenges that I think are worth ⁓ talking about. But OK, so let me answer the ICP question.

Right, what's your ICP? Yep.

Yeah.

We have sort of an interesting.

Like you said, we're very horizontal. Like being just plumbing, being just infrastructural glue to connect sales or other things is both a blessing and a curse because we're sort of usable anywhere. But because we're usable anywhere, it's a little hard to articulate the product vision for people. Right. I like, what are you guys, what is it for? It's for anything, you know, but like, what kind of things can you talk to? We can talk to everything. Like it's just, it's almost too generic to be approachable. ⁓

So we have done a lot of work with messaging, try to just explain why it's useful. And we've had to sort of niche it down a little bit. So I'll give you an example. ⁓ We ended up with a lot of higher ed customers that I could not have predicted ahead of time. I'm not even quite sure how we fell into that, but schools started coming to us to connect to all these like really cranky education space systems, like Ellucian makes a bunch like Banner and... ⁓

It was like a student information database. I forget the name of it. And then they did like a ⁓ centralized API gateway called Ethos, which had a very complicated schema, like extremely structured in a way that's like irritating. Like it's a hindrance. ⁓

And so schools would have a miserable time trying to connect. And there's only a couple providers that specifically were working in the hybrid space and integrations, and they were not great. I won't name names, but I heard a lot of bad stories about what people were doing in the space. And so we started doing these connections to things like ethos. And it was complicated, and a couple things happened. One, it improved our product.

because we had never dealt with a schema so complicated and it made us change how we architected schema. Like a lot of the schema stuff we have in like the multi-dimensional property path type stuff, a lot of that came out directly out of ethos being such a pain in the butt. ⁓

So we kind of worked with a bunch of higher ed schools. And then once he's do a couple, they all ask each other like, Hey, how do you connect to ethos? And they're like, yeah, we use these guys and it's really easy. So we started to get this like chain of customers, like in a specific domain. then, I mean, ultimately I'm talking about sort of niching down and focusing on messaging in a certain market. So then we started saying, Hey, higher ed customers, we are the perfect solution to talk to your student information systems.

And that's approachable, right? That's a message that the people in that space like understand. So it took us a while to kind of figure out where those were for us. Like what are the little markets where we make sense and kind of coming back to your original question. I think that we fit best at sort of two ends of customer size.

Mm-hmm.

We're very good for smaller groups where this is their main integration. It's all they're gonna use. They're not gonna connect to other, not gonna use it like big middleware. They're not using Kafka or anything. They don't know like messaging exchanges or anything like that. They just wanna connect Salesforce to some stuff.

two, three, four systems, one has to do with money flow, one has to do with like inventory or something. And just that kind of gives Salesforce the data it needs for them to be successful. So that's like customer A is like small, this is the central thing they're going to use. The thing of Salesforce is for their main system. ⁓ And then we kind of jump up the scale. I mean, obviously there's different use cases, but another really common use case is at a very large organization level, like enterprise scale or government level ⁓ where

There's an entity, a team, there's a silo somewhere in that organization and they really want to have agency over their own integrations. And part of ⁓ what's appealing to having Valence run natively on the stack is that they have control, right? Control is power, especially in large organizations. And so if you don't have to deal with central IT, if you don't have to open a ticket every time you want to change a field mapping, but in your team can do it themselves, they can just fix it.

Hmm.

then

that's a huge win. actually, interestingly enough, that is the exact same marketing strategy that Salesforce used back in like the nineties when they first like really coming out and selling their whole pitch, like the whole no software thing was a repudiation of central IT teams and saying, Hey marketing, Hey sales, you don't need central IT. You can run your own CRM and you're going to manage it yourself in a web browser and your team that understands the data and how to sell gets to control it. You don't have to ask IT for anything.

Hmm.

do it yourself. It was a huge change. Like it was a ecosystem shift to pitch them as like, hey, you don't need tech people. You could do this yourself. And so we're kind of in a way we're making the same pitch is like, hey, you're a huge organization. You know, you're the federal government, you're the Department of Commerce, and you don't want to have to like wait six months to have stuff happen. You like to have it happen in six hours. So like, you we get these like, teams within a larger team ⁓ that end up using us for their

org to talk to central IT stuff, right? Talk to the APIs that central IT does put together.

Very cool. It turns out the same playbook that Marc and Parker used in the 90s is still relevant today. Very cool. Okay, well, you mentioned wanting to talk a little bit about the architecture, and I do want to get into that a little bit, building native on the platform.

Go figure.

⁓ you brought up the Department of Commerce. Are they a Valence customer today?

Yeah, so we've sold into some really large enterprise organizations that are commercial, and then we've also sold into the federal government. And we've been trying to sell into state governments and local municipalities and stuff too. But we kind of fell into that. We get a lot of deal flow through SIs, and an SI that worked in public sector came to us and said, hey, we'd really like to use Valence. Do you support GovCloud?

And we said, I don't know. Let's go do some testing and see if it works in GovCloud. And we had to make some small changes, but we were able to make a GovCloud compatible version, which is now the only version. The valence works in GovCloud just like it works in regular cloud. ⁓

Ha ha.

But it was really kind an interesting challenge to do sort of the business side of it, right? Because working as a software vendor with the federal government has a ton of hoops you jump through. So there's things like there are certifications you have to do. One was called FedRAMP, which is like the fast one, but it costs $65,000 to even get started. And it's like all this is like a ton of stuff. It's super complicated in public sector. But part of what was so compelling for this use case is because we were fully native on the stack, we really didn't have to deal with some of the paperwork that our vendor

had because we just didn't have the same infrastructure, we have the same use cases. And so when we were brought in, we're not FedRamped, but Salesforce themselves are FedRamped. And because we're fully native on the platform and we're an app exchange app, we were able to sort of ride the coattails of that and be like, okay, well, you know, this is good enough because it's essentially just a plug-in for something you already have vetted and approved. So that helped us open a bunch of doors and get through them.

And then beyond that, we had to sort of prove some security things to the federal group.

explain why we weren't going to be a risk factor. And so we did like a security audit with them about our product and they're asking questions like, okay, you know, what do you, what's your archive policy for our data? And my answer is we don't see your data. It's directly from your GovCloud org to whatever you're talking to. And they're like, okay, but like, how do you, ⁓ how do you handle like the transfer of our data? Like what's your authentication strategy when you transfer our data through your system? And do you encrypt our data at rest? And I said, we don't see your data. It doesn't go through our system ever. ⁓

And like, well, how do you secure this or that? And the answer was like, no, we don't do that. No, we don't do that. No, we don't do that. So it's incredibly straightforward security review because we were just like not a vulnerability that was being introduced, right? Cause we were just core stack and we've always been very security conscious and we really don't want to like open up. So you, for example, you can't call into Salesforce and get data from balance. It doesn't have a public API in any way to get data. You can call it and give it data.

You can drop off real time data, you can't get data. There's a lot of about Veonce that we wanted to make very approachable for people.

Mm-hmm.

Um, so that really helped with the, with the FedRAMP thing. And the other part that helped was they were able to do a, what's called like a single source document, which, uh, essentially said that we were the only vendor that could satisfy this need. If you want an ETL middleware tool that can handle big volume and it's native on stack and doesn't use an external executable, there's literally one vendor that you can use. It's this vendor. Um, so we got to skip like a whole bidding process and stuff on the federal government work. And so, uh, really we just sort of like scooch through a bunch of different

⁓

like angles and stuff that are normally big pitfalls but the fully native piece and our security posture really helped a lot.

Yeah, the single source doc sounds like you avoided a lot of procurement headaches that normally go along with federal contract work. You mentioned you had to change the application to work or tweak it ⁓ to be compliant with GovCloud. What is the process for ⁓ getting a GovCloud demo work? Was that easy to do or did you need then like Department of Commerce to hand over a sandbox or something? Or how does that work?

Yeah, definitely.

⁓ You can get it

from Salesforce directly just by saying like, here's what you're working on.

The Salesforce AEs for public sector are pretty clued in. Like we were pretty immediately introduced to the AEs that were involved and they were able to help us get resources and stuff, right? Cause they're very interested in making sure they're very familiar with how complicated it is to do public sector. And they're very interested in like helping things go faster. So we got access to GovCloud pretty easily. And then we just had to kind of kick the tires a bit and look at things. And some of the examples of stuff we got caught up on is like different TLS behaviors, like some of the authentication of the way you actually mechanically do like cert management, like call-outs and stuff.

Okay.

a little different. So we were able to kind of navigate that and nothing that we added for that wasn't something that was useful in the original tool as well. So we just folded all that back in.

Mm-hmm.

Cool. Well, and so I'm curious too, ⁓ staying fully native, obviously a lot of benefits. I imagine there are some headwinds that you face as well, namely in terms of governor limits. So I'm curious, like, what kind of architectural dark magic did you have to employ to get around those?

Yeah,

so there's a lot of skepticism, not from our team, but from the outside looking in when we first got started about is this even a feasible thing? Like, can you do large scale data manipulation natively on stack?

And governor limits are a huge factor. So the analogy I like to use for people with this is like the old the duck swimming in the pond, right? Where like the duck looks very calm on the surface and then underneath the legs are kicking really really fast. ⁓ There's a lot of work probably early version of valence. I think 70 % of it was just code written to handle governor limits gracefully. ⁓

Mm-hmm.

So when you run Valence, you can just throw data at it and it's just going to eat it and not care. ⁓ You don't have governor limits really when you're working with Valence, not because they don't exist, but because a lot of Valence is architected to handle them for you gracefully. So I'll you an example. There's 10,000 data rows you can write into the database in a single transaction, right? That's a 10,000 DML limit, very familiar to people. If you gave Valence 15,000, 20,000, 30,000 rows of data in one go, Valence would automatically chop it up and it would put 10 in the first transaction.

and

then would pass the rest to another transaction later in time. And then it would do 10 more and then do 10 more. So it just, knows that that's a governor limit. It would have exceeded if it accepted what you gave it offhand and it chops it up and handles it properly, right? There's a lot of examples like that, like little metadata things. Like if you send a one or a zero in to imply.

True or false, right? A lot of external systems use integers as they're true false. If you write a one to a Boolean field in check, a checkbox field in Salesforce, you're gonna get a DML error. It's gonna say, hey, that's a one. That's not a true or false Boolean value. But like our product automatically will say,

We can see the metadata, the field you're writing to, it's a checkbox field, and we can see that we're holding a numeral, or we're holding the letter Y, or the letter N, and we know there's like an implied truthiness to that, and we're gonna just go ahead and convert it to a Boolean value for you. So there's a lot of stuff to sort of handle the nuances of the way governor limits work, the way asynchronous stuff works, and just the way the Salesforce intricacies of the way the metadata works. We use a lot of custom metadata types. It's very configurable and sort of deployable.

Hmm.

But one of the big challenges has been scaling it. And I think that maybe at this point, we're probably one of the most advanced use cases of asynchronous Apex that's ever existed in the platform. And that's like a big claim, but the amount of platform bugs we've discovered and shared with the PMs ⁓ at scale is kind of crazy. I think we were the first people to ever count to a billion with feature management. So feature management has an integer value you can share.

And in Salesforce, it's 18 characters is like a number field, right? And you can choose where the decimal point is, but the 18 characters is kind of your limit. And then the actual integer value, like as a bit representation is like 4 billion or something, right? If it's signed. And so you're pretty good on like big numbers, but we had, we were counting like rows of data moved just as a very high level metric. And our first customer that moved their billionth row of data.

broke the stack, like hardcore gacked their stack at an extremely low level and broke their org and the orgs of other people on their pod. And it was because there was like an undocumented hidden limit of 10 characters in one of the internal APIs. And no one had ever sent a 10 character or longer integer value to the FMA system.

Everyone's counting to like 100. And so we counted to a billion and we broke everything. And I have probably 30 more stories like that.

my gosh, I was laughing because I remember they like updated the help docs to warn ISVs basically of this limitation I think eventually. But this is like if McDonald's like... ⁓

Yeah, we felt that for them. Every shot

said, Hey, is this something that you've seen before? And they're like, No, how did you break it this much? Like it really broke the org.

So this

is like McDonald's counting how many Big Macs they've served and then on the billionth one, suddenly all the grills go down and the fryer stopped working. All because of like some, it's so funny too, it wasn't even like quarter the product, it was just sort of like a metric that you're probably showcasing your value to the customer. You look at how many rows you've moved. ⁓ that's funny. Well, thanks for sharing that, those war stories.

Yeah.

Yeah.

We've been doing this a long time.

I'm sure that there were some late nights and headaches from doing gymnastics to get Apex to do all these data integrations. But now that it's working, mean, another thing that's amazing is... ⁓

that I would think is a sell for you to your customers is that there's not yet another vendor you have to trust with the data. I mean, you already trust Salesforce. You must already trust whatever other partner you're trying to integrate Salesforce with. There's no valence server that's gonna be storing all of your data that you also have to trust, unlike some other middleware companies that are off platform.

Yeah, so I guess starting on the business side, right? Like what's the use case? What's compelling here? And being fully native on the stack has some immediate advantages, which you already started to point out, right? One of the major ones is there is no middle piece, right? It is your org talking to your other system. ⁓

We don't have a server, there's no uptime, we don't archive your data, we never see your data. Your data goes from your own org that you control into something else that you control. So that is an extremely appealing proposition to really everybody, but especially people that are security conscious, HIPAA, PII, financial. mean, nobody wants to be loose with their data, but there's certain industries and certain types of companies and groups that really, really, really wanna be careful with their data. So that's very compelling. And...

Mm-hmm.

That's really our main distinguishing factor when we first got started is that we really wanted to focus on Salesforce as an ecosystem for a couple of reasons. So the integration space is incredibly saturated. There's a ton of middleware out there that has been for years and years and years. There's just generational after generation of different integration products that come out in the market. And the vast majority of them are really an any to any connector.

Salesforce is one end of either, it could be the source or the target, and you can connect all kinds of different things to all kinds of different things. Salesforce is just one of the possible lists of things. And that's great. And our tool is not that. And we knew from the start that we were sort of eliminating a huge potential market by saying Salesforce has to be on one side of the connection. ⁓ Technically, you can move things between A and B through your Salesforce org.

but it's a weird use case, it's not really a great fit for us, right? It's really about getting data into Salesforce and get data out of Salesforce. So by saying that we only focus on the Salesforce ecosystem, we're reducing our addressable market by a huge factor, but we also create a point of differentiation that cannot be matched by the larger groups because they can't go native and still satisfy their original goal of like any to any connection. So not only does it create kind of an interesting moat.

but it allows us to really focus on the weird complexities and nuances of this specific product. So Salesforce has a lot of little oddities that we're all pretty familiar with, right? Things like multi-select pick lists and how do you set them and read them, you know, the different data types that exist, the weird constraints around lookup values and master detail, right? And like...

Just all kinds of different little nuances that exist and you have to accommodate when you build integrations. so if you're from the outside looking in and you're just using like the bulk API, there's only so much you can do. ⁓ but if you're on the inside, then you have so much more flexibility. And part of what we wanted to do was make a product that was very, very, very easy to use. So we haven't talked a ton about like product vision, other than we wanted to solve a problem. But our goal was to have two equally valuable things exist co-exist in our product. One is that should be incredibly easy to use.

should be able to be non-technical, walk in, open it, and figure out how to build data connections and what's happening and do transformations. It should be turnkey easy for anybody that was savvy about the data that was in the work. So your BAs, your admins. At the same time, it needed to be extremely extensible. have a very sophisticated plugin architecture that's part of the library. And so you can build all sorts of complex things on top of it that do custom transformations, custom behaviors, talk to weird endpoints. ⁓ But the rule one.

of it has to be easy to use still applies. So part one of the challenges that we always have in this ecosystem, and I'm sure this is going to resonate with you, is if you start to build something custom, you know, a Visualforce page, a Lightning Web Component, an Apex class, you have to then accommodate everything, right? You have to do the UI. You have to, you know, make it feel and look similar to something else. And then if Salesforce updates a feature somewhere else, yours is an update and you have to come back and change it, right? You're kind of wholly responsible. You can't be like a little bit responsible. And part of like the goal with things like LWC is like to help you to

Mm-hmm.

be a little bit responsible. You just do this little widget and the rest of the UI is up to Salesforce, right? And then the admin can decide how to drop it on a page and how it should behave and stuff. So there's a similar philosophy of it should be extremely extensible, but everything you extend should still be accessible declaratively. It should be sort of self-evident what it does. So an example would be if you have like a filter, which is a transformation element for us that injects new fields into the record.

then we have a way for you to describe what you'll be doing as far as schema goes. And we surface that in the mappings as if it was an actual database field. They'll see like the name of the field, the data type, and that comes from us forcing extensions to like self-describe their behavior.

Hmm.

Well, I can tell you you're passionate about this and you definitely, you said you're a CTO that happened to found a company. ⁓ You still have the technical edge I can tell. ⁓ Okay, so I'm curious too, like, how would you, are you partnering today with SIs to go in? Because you mentioned earlier that now you don't do any consulting and...

One thing that I've often found in Salesforce integrations is, plugging the two systems together is just half the battle. And then you get into things like, okay, ⁓ external system has pushed in a bunch of contact records, but that kicks off a ton of automation flows.

God help us process builders. Apex triggers that were built for beer money. So I would imagine in your world, it's almost like a force that keeps pulling you, attract you in, that keeps pulling you in to do consulting work with onboarding a new client. I'm curious how Valence manages that. If you're partnering.

know, valence experts to go in and do onboarding with clients or if you've somehow been able to circumvent all of that basically that is described.

So ⁓ it's very attractive to do consulting on top of Valence, right? It's right there. You're doing the basic plumbing and they need XYZ extra thing and that's money sitting right there you could have if you just were willing to do it. And I often talk to our team and say that we are recovering consultants. We need to not reach for that. ⁓ yeah, it's a hard line I'm trying to maintain.

and so on. I like that.

do as I work, we don't do consulting. And so.

At the same time, nobody ever does integration by itself, right? People are building new integrations as part of process change or business transformation or evolution of how their systems work. And so there's always other work. It's never just, ⁓ drop this in place and we're done. It's, how are we going to use all this data? What's the data for? What's the new tools we're going to build because we have this data. So it really lends itself to being part of a larger scope of work. So it really lends itself to being an SI project, right? It lends itself to being something that consultants or an internal tech team is focused

Mmm.

on building something and this is just a part of that build. So we do a lot of collaboration with SIs and internal tech teams.

And just sort of guide them. We really kind of are one layer removed from a lot of our customers in that a partner will pitch us. say, Hey, here's some integrations that we like, you know, can have Dell Boomi or Informatica or Valence. And here's like the pros and cons and the prices of each one. they put them in the SOW and they say, we recommend Valence, the Bull Star Neck Suit or something, right? So the customer says, yeah, let's go with your recommendation. ⁓ So we signed a contract with the customer directly. And then the SI does the implementation really often, like we'll help. there to answer questions for the

the S.I. or for the customer. We always like to try to help the S.I.s look good. So they come to us, they ask us a question, we help them understand something and then they go back and talk to their customer about it and they look very knowledgeable and we're happy to support them in that way.

Mm-hmm.

So a lot of our onboardings are done in partnership with SIs and a lot of the deal flow comes from the direction of the SI. They just bring us a customer. Occasionally we people walk in the door directly that have complex needs that we have to kind of turn the other way and like find an SI to partner with on it. We have a few that we like that are used to doing valence projects that I'll reach out to and say, hey, know, this seems kind of like in your wheelhouse. Do you want to talk to this customer and maybe pick up this project? But that's definitely

Mm-hmm. Mm-hmm.

the bulk of the sort of SI collaboration is inbound. And the other thing we've done actually is because we're so like plumbing and foundational, we're also appealing to other app builders. And so another angle for us has been essentially being

Mm-hmm.

co-branded. I don't let people white label us, but we'll do like kind of minimal presence facing customers. So they'll name some product and then it'll be like in partnership with Valence or powered by Valence, right? And they'll sell an actual product that connects the thing. So we have a partner that works in the manufacturing space as an ISV and they do a ton of big customers, right? Like Stanley Black and Decker and Whirlpool and all kinds of like Volvo.

manufacturers globally ⁓ and they help them with a bunch of like complex manufacturing stuff. And so this particular partner that I'm thinking of essentially resells Valence. They have the ability to sub license it as part of their product. So when they sell their SKU, it just comes with Valence built in. The customer pays them for the SKU and then they pay us like a negotiated fee for like the sub license.

And so for customers like that, ⁓ when I say customer here, I mean my partner, we actually have a self-service portal available at our website where they can log in with a code that represents them as a partner. And they can see all of their contracts that they've built for us, like all their shared customers. And they can see invoices that are due if they're paying us directly. Sometimes people pay us directly as a partner. Sometimes the customer pays us.

So they can see sort of what monies do. They can see where things stand. They can register orgs. So we use the feature management app in Salesforce, which is a way to push features like Booleans, integers, and dates back and forth between orgs. And so we can essentially activate an org, extend the expiration date to match the contract date. ⁓

and set the parameters, right? Because Valence comes in a few little configurations. It's pretty much one size fits all, but there are some parameters that are involved. So the partner can fill out this form and essentially register an org ID that will propagate automatically through the system and will provision them in the Salesforce PBO, Partner Business Org, where our LMA, License Managing app is installed. And it'll actually like the license for that install. So the customer can...

alphabet soup.

So our partner can find a new customer, sign them up.

fill out an application form that will automatically create a contract. So we use service contract in Salesforce. So it'll create a service contract with the appropriate information on it. It'll set up the invoices. It'll invoice the partner. And then they can go in and provision the org and install Valence. And they can have a contracted install of Valences properly provisioned with the right parameters and the right expiration date without anyone at Valence lifting a finger. And I like that.

That is amazing. Chuck,

honestly, that's a product in and of itself, I feel like, that a lot of ISVs would like to have because this is a go-to-market play that a lot of ISVs go after, which is partnering and sub-licensing their app through ⁓ resellers. I feel like a lot of folks would love to be able to not lift a finger and just pull open Salesforce one day in their partner business org and see some new deals.

Yeah.

So, um, I have it hooked up to Slack and so it would be like a new contract and I would like, look at my Slack. We're like, Oh, Volvo is a customer now. Cool. Like I didn't do anything other than build a great app. Um, but part of what is nice. Oh man, I clearly lost my train of thought there. Um, Oh, right. So the productizing, um,

That's amazing.

One piece of this that I didn't mention is the COA channel order app that you use to report your revenue to Salesforce so they can get their cut, right? And they have ⁓ like an API and Apex for the COA and it's pretty clunky. ⁓ We also automated our COA integration so that when the customer, when people do these contracts, it reports it to Salesforce correctly as well. And that's all automated. And specifically the COA like little integration we built, people have told me that like that should be a product. You should be.

Sure.

ISV should be able to just click a button and have their service contract map into their COA order and everything adjust appropriately. And then when the contract cancels, you have to cancel the COA order. having that all in sync is really challenging.

Yeah, that is, I'm on board with the post. think that could be a product. Sign me up. Well, very cool. I'm curious. I know you mentioned you have like a, you know, pre-negotiated rate for like the ISV in the manufacturing space that's sub-licensing. For, I did want to ask for the SIs that are bringing you in kind of ad hoc to deals. How do you have any like...

referral fee or like revenue share there or is that just ⁓

Yeah, this

comes up a lot, right, in our space. Something that people are always asking each other and asking themselves. And I have a pretty strong policy on it, and I'll describe it. And some people agree and some people won't. But I don't think referral fees are appropriate for this sort of thing. I think that regardless of whether it does or doesn't, it gives the perception of influencing a decision.

Mm-hmm.

And I never want people to feel like a valence came to them because of a kickback or some other, you know, just less than above board manner.

And so my stance has always been we don't give people any money for bringing us leads. We don't give people any money for referring us and using us in their projects that people will use our product because of the best fit for their project. It's going to help their project go smoother. It's going to reduce risk for them and their customer. And it's going to make things go faster. It's like they're going to get money, right? They're going to get benefit and value here, but it's not going to be from my bank account. It's going to be from the use of the tool and how it's going to accelerate and catalyze their success.

Mm-hmm.

⁓ And most people accept that, right? I've had SIs be like, hey, you know, what's your referral fee? And I say, we don't have one and here's why. And some of them will say, yeah, okay, that makes sense, worries. And some will be like, no, I don't wanna work with you. And I was like, well, I don't wanna work with you. Like, if that's a precondition, I'm not sure we're a good fit for each other.

Hmm.

Yeah, I mean, it's all about finding a good fit. goes both ways. I I have interviewed some founders that say they do offer it, but that the vast majority of SIs end up saying they'd refer not to anyways, just to remain impartial. Yeah, yeah, but so it's nice, but it's nice that you just kind of remove that from the table maybe so that. ⁓

Same thing, right? Integrity from the other direction.

you know full out that every org that has Valence installed is basically because it brought value to them, not because it brought value to somebody else's pocket. ⁓ Very cool. okay, so I do want to ask you, ⁓ kind of looking a little toward the future, how has Valence been thinking about strategy now with AI, ⁓ either with Agent Force or ⁓ LLMs outside of the platform?

Yeah, so I would say that our team is sort of an interesting combination of extremely tech savvy, right, like deeply technical and knowledgeable, really expert level in a lot of domains, and also deeply skeptical. It's an interesting but useful combination. So I would say that we really understand sort of the, I'm going to say integration here, but I mean sort of the

putting things together of AI and other tools, right? Like how do these things collaborate and how do you get value out of them? And I think the vast majority of our use cases, ⁓ there's not really great value from the AI engines that exist today, simply because you want it to be incredibly deterministic, right? You want data to go from A to B, you want to go the same way every time, you want it to map the same way every time, all the transformations that happen the same way every time. So like the fact that...

Hmm.

the fundamental value prop of our tools that it's very consistent ⁓ is not a good fit for like AI in the tool level. But where it does become handy is in like the building of the extensions and the outer layers, right? Like, okay, you want to connect to, you know, the QuickBooks API.

Mm-hmm.

Well, you can use, you know, Claude code to help you take the valence documentation for how to build a connector, take the API documentation for specific API and, and some examples of good adapters that have been built. have some open source ones on GitHub. You can take all those elements and feed them into an LLM and build your first connector in five minutes. And then you can tune it and clean it up and work from there. So like the layers on top of the engine of like how you interact with it, ⁓ do become possible to accelerate through AI. ⁓ so we're.

Thank

Not planning on servicing anything directly to customers anytime soon. But we have thought about sort of how can we use AI to ⁓ speed up onboarding and to sort of help with sort of post hoc analysis of data movement. Right. Like sort of here are your trends. You usually move this much data in this way, and this is unusual. Here's some spikes in your behavior of your data that you may not be aware of. Right. And like you used to get a thousand records a day from the system and now you get 10 as of two weeks ago.

Mm-hmm.

I like that is a heuristic that you might want to go investigate. ⁓ So kind of that too, sort of like a health check, sort of analysis, conclusion drawing effort on the other side of like, okay, now everything's moving, what do you think about it?

Mm-hmm. Well, OK, this has been ⁓ really interesting. I feel like we should probably wrap up pretty soon. But ⁓ before we do, we're coming up now, I guess, on the 10-year anniversary of Valence. So I'm curious ⁓ if you were able to have a conversation with 2017 Chuck. ⁓ What advice or maybe warnings would you give to him?

Mm-hmm.

⁓ well, don't take out a business loan to make payroll. If you're splitting your attention between two things, just pick one thing to focus on. That'd be a big one. ⁓ I would say that believe in yourself and stick to your vision is a big one. And I mean, it seems kind of, you know, classic, but the, we went to the incubator and describe what we wanted to build. I want to build a

middleware beefy ETL tool natively in apex and we literally had executives that worked at Salesforce say this is a dumb idea. This won't work. It's not possible. Informatic integer bit didn't do it this way for a reason. Right. And we got a lot of people saying like this is not going to work. But we believe that it would that we thought we could figure it out. And we did figure it out. And we're really, really good now technologically. ⁓ So, for example, because we're not

outside the API layer, don't use the bulk API to move data. are inside Salesforce pulling data in and pushing data out. We are way faster than the bulk API, like orders of magnitude faster, because we're highly parallel and we're just have a totally different model for how it's architected. ⁓

Yeah,

I heard a quote of you can do like a million records in how long was it again? That's unreal.

90 seconds. It's my demo jam demo. As I move a million

leads into Salesforce in 90 seconds. That breaks. Absolutely. So I think part of my advice to an older, younger version of myself would have just been like, hey, you have strong vision here and it's grounded in real projects that you've done and you know what you want to build and just stay focused on that. ⁓

That's unreal. Also, I'd love to have a million leads, by the way, but it's just a move.

I also got really distracted. So we did a lot of mentorship along the way. And I got really bought down in a lot of like, sort of the artifacts of a startup, right? Like building plans for this and plans for that. And, you know, all these iterations of testing product market fit and like a lot of that's really valuable and some of it's really not.

I really got bogged down in too many people's opinions, too much advice from different sources, and too many like things, exercises, stuff I was doing when really what I should do is just build a product that I knew I needed to build and then iterate with the feedback from real customers that were using it or interested in using it. So there go. That's my answer.

Alright, well if anyone listening wants to get in touch with you or maybe try out Valence for a project they have, what's the best way of reaching out to you or learning more about the product?

So website is valence, V-A-L-E-N-C-E dot A-P-P, valence.app. My email is chuck at valence.app if you want to reach out directly. Valence is free to install on the AppExchange, right? You get a 30 day trial, pretty standard AppExchange stuff. You can put it in the sandbox or DE or scratch or just play with it. ⁓ We have open source filters and adapters online. You'll find them on GitHub at valence dash various things, valence dash filters, valence dash adapters.

But the documentation is really robust. So it's pretty self-serve as far as like getting up and running and kind of playing with it. That's intentional, right? We want technical people to be able to just touch it right away on their own and figure stuff out. But we're always happy to talk and help, you know, dope out more complicated situations and things to handle. We've seen...

every iteration of weird integrations that exist, right? Synchronous, asynchronous, delayed, circular, like chained, but not knowing in advance how many pages you're going to have, knowing in advance how many pages you're going to have, but each page is like handled differently and like nested. There's like every variation under the sun. At this point, we've seen, done and have ideas and opinions about. So a lot of what we do with just like what people reach out about is like, how do you do X? Is this possible? We have a lot of conversations like that.

I love it. Well, I know another space where you and I have a lot of conversations is in the Good Day Sir Slack. So as ⁓ good members of the Good Day Sir Army, I feel like we should mention that that Slack workspace is out there for anyone else who wants to maybe commiserate with Chuck on their integration woes or just geek out on some of these integration topics.

Yeah. So good days for podcasts.com and it's a really great podcast by some guys, John and Jeremy that, ⁓

very technical, understand the ecosystem really well and don't sugarcoat what they see, right? They call it how they see it, really fun. If you're someone that just wants to hear the real deal and as a great Slack community that's built up around the podcast, but also become kind of its own thing. Just a lot of people collaborating and sharing stories and answering questions and being social with each other. And you can join that through the website. It's I think the website domain slash community, if I remember correctly, but you'll find it on there.

I think,

yeah, I think that's right. Well, Chuck, thank you so much for joining. Really loved hearing your story. Best of luck to you and the Valence team.

Yeah, thanks. been great to talk.

Cheers, bye.