Rimon Hanna of Serpent from Tekunda, a Salesforce ISV and PDO, shares how years of feeling the daily pain of Salesforce delivery — untracked changes, change sets, and clunky CI/CD — led him to build a DevOps platform that makes Git effortless for technical and non-technical teams alike. Starting with the ISV and package-development workflow, Rimon explains how Serpent grew to serve system integrators and customers as the market pulled it in directions he never planned for. The conversation digs into usage-based pricing, partnering with SIs, competing with change sets and DevOps Center, and how AI now resolves merge conflicts and cherry-picks features that once took hours.
Serpent treats source control as a given, not an option — no change should live untracked on an org or someone's local machine
The platform lets non-technical admins follow Git without having to learn Git, with a standard mode and an expert mode for different personas
Serpent started with the ISV and package-development workflow before expanding to org development, where the number of user personas explodes
The biggest competitor is still change sets — a 2025 Salesforce Ben survey found 42% of admins still rely on them
Listen to how the market reacts instead of getting tunnel-visioned on your original plan — the second-biggest interest came from system integrators, not customers as expected
Usage-based credit pricing instead of per-seat lets SIs adopt Serpent across boutique teams and pass costs to customers per project
A tiered partnership program (silver, gold, platinum) gives SIs revenue share on both first-year and renewal subscriptions
DevOps Center often funnels users up from change sets, but its limitations push teams to look for a vendor that does more
Serpent AI resolves merge conflicts in 95%+ of cases, including notoriously tricky flow conflicts, and tests the result before deploying
AI-powered cherry-picking turned a customer's nearly three-hour manual change selection into a single explained prompt
The Serpent MCP server lets AI coding assistants work through Serpent's gates and checks instead of deploying directly to an org
Release as fast as you can and iterate — smaller packages also clear security review more easily
Simplify security and permissions for Salesforce admins & consultants.
Secure your data using head-to-head user comparisons, AI summaries, org-wide integration audits, and analyses that can span across time or even between separate orgs.
Gain Powers & Save Hours.
Visit Permissions Assistant on the AppExchange to start your free trial today.
Today I am joined on Appsembly Line by Rimon Hanna of Serpent from Tekunda Welcome to Appsembly Line, Rimon.
Rimon Hanna (:
Thank you. ⁓ a pleasure to be here and thank you for having me.
Scott Covert (:
Yeah, I'm looking forward to getting into your story. So first off, maybe you could share a little bit about ⁓ Serpent, of what problem it solves, who it's for, ⁓ and how you got into the Salesforce space in particular.
Rimon Hanna (:
Sure. ⁓ I guess the journey starts with how I ended up in Salesforce in the first place. In two thousand eighteen I was working at a company, Folkscura, which is ⁓ an Asabloid subsidiary. And there they they were using Salesforce and I was as a user exposed to it and they were having some challenges in their service department, ⁓ dealing with so many cases coming in and they need someone to help them out a bit. I was not aware of what Salesforce is at all at that moment, except, you know, what I saw.
And yeah, I helped them out, made like an automation that helped them reduce the number of cases by 93%, thankfully. And they were able to pick up their operations more successfully. ⁓ but while, you know, delivering on on that improvement and many other things later on over the years, that's when the pain point of
Salesforce delivery started growing and growing and growing. And I tried to fix that with multiple approaches at the beginning, like getting to know the Salesforce CLI, which was called SFDX, at first, and ⁓
Scott Covert (:
Mm-hmm.
Rimon Hanna (:
It was still a bit immature back then, but we still try to write like GitHub actions and scripts around it and but it it lacked a lot of things because even if you wrote those scripts and they were like created an ⁓ an a spotless CI C D, you still lack collaboration with non-technical people, your stakeholders, your testers, your like how do I trigger that? How do I see this? How can I access this org?
Wh where's the latest version? Is it on this sandbox or or that scratch org? ⁓ so the the those kept accumulating and I tried to use some of the tools out there and felt like if you're specially specifically doing package development and and ⁓ and basically as an ISV, there's not something that was really supporting that workflow. And that's what we were doing. We were doing a lot of our projects as ISV and then I was like, okay, maybe something needs to give. And that was the inspiration behind Serpent.
which is as was born as a Salesforce DevOps platform for ISVs and then grew to also support customers and system integrators and other use cases. And
The main I would say like the main thing that differentiates Serpent is that we always say s like Git or in general like source control should not be optional. It should be a given. Something that happens every everywhere and it needs to be your main source of truth.
Scott Covert (:
Hmm.
Rimon Hanna (:
n no change should live on an org somewhere or someone's you know local device or like those like untracked changes should never exist. And with that methodology and that like mission at hand, we built Serpent that makes it really easy to follow Git without having to learn Git, which is a huge learning barrier for a lot of people in the Salesforce ecosystem. And much like any Salesforce team, our team was filled with different backgrounds, not all
software engineers that are comfortable using a CLI and working in VS Code. So using Serpent, we were able to empower everyone to not even think about Git, they think about what they want to do. I want to deliver from point A to point B and it takes care of the rest.
Scott Covert (:
Mm-hmm. Yeah, I I I think a lot of ⁓ folks listening to the call that have ⁓ dealt with deployments are probably nodding along. ⁓ some going back to the days before even the CLI. ⁓ this has long been a problem. People wanting to get away from change sets. back in the day was ant migration scripts. ⁓
then as as you mentioned, moving to to GitHub actions to the CLI. ⁓ very cool. It's interesting that you ⁓ you first tackled the ISV use case. ⁓ I think that's ⁓ that's probably unique ⁓ among players in the space. ⁓ would you say that ⁓ migrating to a traditional Salesforce deployment use case was challenging? ⁓ or would you say that the you you took on the the harder ⁓ user story first and then it was easier to migrate.
⁓ or or augment the other use case.
Rimon Hanna (:
Great question. I would say they're different, ⁓ not harder or easier, ⁓ especially because the user is different. Like the the person you're building this for is very different. Like ⁓ if you're an ISV, you have a different release process completely than traditional org development. And ⁓ a product development I come from a product development background, like mobile or back-end or whatever, but and and and it kind of mirrors what the ISV has to go through a bit.
Scott Covert (:
Mm-hmm.
Rimon Hanna (:
with the exception that it's mostly on cloud rather than local machine first. And that was an easy bridge to take, but then finally getting into the shoes of like the consultants and the functional consultants, the configurator, the admins, the different personas you have, because it finally it as soon as you go into the like the org development or traditional Salesforce, then the number of per personas or users basically explodes. And you have to curate for the whole
Scott Covert (:
Mm-hmm.
Rimon Hanna (:
range
starting all the way from you know the junior admin that is still learning how to deliver on Salesforce all the way to the architect and the developer that might be able to easily work in VS Code and wants to stay without in that environment. So that inspired for example creating like a standard ⁓ mode and an expert mode inside of Serpent.
It also inspired creating a VS Code extension and an MCP server for connecting your AI coding assistant. So like a lot of like design and feature decisions were driven by how to curate for the different personas in one platform. And I think that was the biggest challenge we had to tackle.
Scott Covert (:
Mm-hmm.
Hm. I would I would imagine ⁓ it's also like like you mentioned, not only are there different ⁓
user personas but there's also just different challenges in general. I think ISVs kind of deliver they have a a known build for their package, right? Whereas ⁓ in a Salesforce org, there could be any number of simultaneous projects going on, other people pushing and deploying to production that maybe the folks that are using Serpent aren't even ⁓ aware of and so they you you need to worry about conflicts because production has changed since you last pushed to it and
⁓ I in the ISV world, if it's ⁓ a second gen package, then it's all source managed and you're not even really worrying about the the org deployment per se, as much as you are just merge conflicts of the source itself. Was that was that a challenge too, ⁓ in addition to the the different user personas?
Rimon Hanna (:
I couldn't agree more. Actually it was a a massive challenge because
we built Serpent around ⁓ source format, which is very familiar for the ISV world. It's how you track your changes and and put them in a repo and how you publish everything. But in the org development, everyone is more familiar with the metadata API. ⁓ either if you have CI CD or you're using any of the tools available for you out there, they're mostly geared or designed around the metadata API format, including chain sets, by the way. ⁓
Scott Covert (:
Mm-hmm.
Rimon Hanna (:
⁓ so the thing is
It's quite a mindset shift to also i introduce people to that too. So there's a bit of education that we do also ⁓ when we bring in a new customer and new users. And we explain the benefits because also with the source format it's a bit more human readable and you can review a lot of it. It's easier to resolve conflicts, I would say, and detect changes between orgs. So most of the engine of Serpent is designed around using that source format. ⁓ so it also has
We have Serpent AI, which is an assistant that helps you resolve conflicts. And if people are collaborating and working on the same flow, flows are especially very hard to debug with conflicts, and you don't have to worry about that for you. The AI agent would actually try to resolve the conflict for you, test it and make sure that it's now deployable after the merge, conflict resolution, and that it ⁓ it reviews it afterwards to make sure that it didn't lose any context from both changes. ⁓
Scott Covert (:
Mm.
Yes.
Rimon Hanna (:
And it works for like 95% plus cases, which is quite high, if you can imagine. And you only have to deal with the remaining five. And ⁓ there's a lot of other like use cases where making sure people
Are empowered to focus on building features rather than ⁓ I missed something here. For example, like dependency analysis, which is also something is capability that is both easy to trace in source format, but also very easy now handled not just by static analysis but by having an AI agent that can say, like, hey, something is miss missing. Also, like doing dry runs for deployments and saying, like, hey, you're missing a dependency here. Maybe go back and select.
selected ⁓ from your sandbox. Yeah. So that's that's what we've been tackling this problem with.
Scott Covert (:
Very cool. Yes. th I think DevOps is a problem that ⁓
everyone ⁓ needs a solution for so it's very cool space to be working in. I could continue geeking out over the the technical aspects, but I want to pop the stack a little bit ⁓ and just ask. So when you were getting started, obviously you lived through this pain yourself, right? ⁓ in your work. And so was that enough for you to know that this was was an itch that a lot of a lot of folks out there in the Salesforce ecosystem needed scratching needed scratched or ⁓ did you do any sort of validation?
Rimon Hanna (:
Definitely.
Scott Covert (:
before you started building Serpent.
Rimon Hanna (:
Well well definitely we're in a lot of validations. So we actually went to the Salesforce Reddit community and started asking them questions ⁓ and figuring out who else still has the pain, who is using what tools, what are they missing out of those tools, what setup they have they are using running their own CI C D or still using chain sets. And I don't know if you know that the Salesforce Ben ⁓ research that came out saying that ⁓ forty two percent of of like Salesforce admins are still using
Scott Covert (:
Okay.
Mm.
My heart bleeds for them.
Rimon Hanna (:
Yeah, definitely, definitely.
and even developers, there's still a decent amount of developers using chain sets until today. ⁓ I was with a call with someone yesterday is like I had to learn chain sets for the first time. He actually got spoiled and started the other way around with like proper DevOps, but then he joined a team that doesn't have any setup and none of them know how to use anything else other than chain sets. And that's where we're coming in, we're trying to help them, you know, bridge that gap. But he had to learn chain sets to be able to
Scott Covert (:
Mm.
Mm.
Rimon Hanna (:
cope with the team delivery workflow. And I think that that's just going the wrong direction. But thankfully he he was familiar enough to know like, well we need to change this. And he's slowly doing the change management across his organization to bring the team ⁓ to to Serpent.
Scott Covert (:
Interesting. So you me you mentioned Reddit ⁓ was a good source for validation for you. I'm curious how you went about that because I've heard from other founders ⁓ that the Salesforce Reddit is a great space to jump into, but that it's all you also have to be careful about, you know, c being too salesy. ⁓ how did you approach jumping into that community and did you get a warm welcome? ⁓ even though you're you're coming from with like a business use case eventually to build an app or or
You are you were you already active in the space beforehand, so you kind of had that that goodwill ⁓ built up?
Rimon Hanna (:
It's a mix of both. So we actually had to learn the hard way.
I didn't understand like this this specific subreddit is even more sensitive to like anything that could be remotely considered a sales pitch, although it might not even be like that far off. Like someone might be asking a question and you're honestly answering, but the answer includes your product mentioned in it and it immediately is flagged as sales. So you have to be careful about that, with that subreddit speci especially. I think Salesforce is doing ⁓ a lot of like overwhelming sales
pitches everywhere which we all are familiar with but that meant like that means that community is a bit more careful
⁓ and and pushes back. So we had to learn like ⁓ we we're part of the community already for quite some time. So we were contributing and asking questions and already for a while and that earned us some rapport but we fell still into the mistake of maybe pitching or something like this. So now we fo mostly focus on really solving people's problems. Sometimes like saying like if you want more info, just like you know, DM me and I'll I'll I'll tell you about about that. And that's what I mentioned
Scott Covert (:
Mm-hmm.
Rimon Hanna (:
maybe serpent. ⁓ but also like regardless of s Reddit or even through our blog posts, we're always trying or LinkedIn, we're trying to always share useful information. So when Salesforce for example was changing their security ⁓
Scott Covert (:
Okay.
Rimon Hanna (:
requirements especially around connected apps and they were retiring old connected apps approaches and introducing like external apps and there was like like there was a huge change there. The thing is when they started introducing that ⁓ people were given about a very short window to fix it with very limited documentation about how to fix it. And we were super affected by it. So we quickly fixed the problem ourselves through manual research and trial and error and then we documented how we fixed this and shared it with
Scott Covert (:
Mm-hmm.
Yes.
Rimon Hanna (:
community and it it had an overwhelming positive response. So this is one of the ways where we we make sure people recognize us as someone is that is there to support them through their Salesforce journey either as a an ISV or as a as a customer or and as an a system integrator regardless if they choose Serpent or not. Because that's the goal at the end, right?
Scott Covert (:
Mm-hmm. That's interesting.
Sure, sure. ⁓ I mean I it makes sense that you you mentioned the Salesforce Ben survey, and unfortunately forty two percent of admins leveraging ⁓ change that's not certain not sure when that what what year that came out ⁓ but regardless obviously it seems like educating your your user slash buyer is is a key part ⁓ of running running Serpent. And I'm I'm curious,
Has that been been a challenge ⁓ that you have to educate ⁓ admins to get away from change sets or do they all feel the pain? I I'm like, you know, is your biggest competitor another DevOps tool? Or would you say your biggest competitor is just an admin doing you know, continuing on the path that they've been on and saying, honestly, change sets are fine for me?
Rimon Hanna (:
I would say it's the biggest competitor really is Chainchet still.
And the second one being ⁓ other DevOps tools. and the reason for that is the there's still a lot of teams, so you don't really feel the pain that much when you're a single admin, unless you're a single admin that doesn't ⁓ feels the pain of I have to keep track and select and etc. And you do big releases, so you still have to remember what you're selecting. ⁓ but if you're always like doing in maintenance mode basically and you're doing small changes here and there, then ⁓
I've met with someone like I don't really feel the need for something like this. It just takes me five minutes to deliver the new change that I get anyway. ⁓ because I know exactly what I built. ⁓ so it needs also exponentially grows as your team grows. The moment you're like three people or something, then you run into conflicts, you run into like people changing something directly in production or in another sandbox, and you don't know who's delivering what and so and and as as that complexity the as the team grows, the
Scott Covert (:
Sure.
Rimon Hanna (:
complexity grows. I think that's the biggest pain point. And there's still a lot of teams out there that are still big numbers with a lot of people that are on chain sets today. So th that was very surprising. And to answer your question about when the survey came out last year, 25. Very recent. Yeah.
Scott Covert (:
⁓ okay. Wow.
Wow, that's surprising that still so many folks are leveraging it, but ⁓ goes to goes to the power of inertia, I suppose. so okay, so that makes sense at a certain s at a at a micro size, perhaps, you know, single admin doesn't feel the the squeeze for for a DevOps tool. But before we turn the microphones on, you actually did mention that
Rimon Hanna (:
Yeah.
Scott Covert (:
Serpent is is targeting more enterprise level customers anyways, which probably makes sense with ⁓ given that the micro ones don't feel the need ⁓ don't feel the pain as much. ⁓ I'm curious ⁓ how has your go-to-market strategy ⁓ been targeting these large enterprise customers?
Rimon Hanna (:
great question. I think ⁓ like any other product at the at its first launch, we've been online for more than a year now. And
I would say the challenging part is finding your niche and your fit at the beginning. And ⁓ first we of course launched within the ISV ecosystem and we started expanding outside because we started getting like interest out automatically that we didn't even plan for. ⁓ and funny enough, we would thought the second biggest interest would come from customers, but it came from system integrators.
Scott Covert (:
Hmm.
Rimon Hanna (:
And the
reason for that and and it's the most important thing that I'm trying to say with that lesson is listen to how the market reacts rather than getting tunnel visioned after your original plan. As an a new product or like a new company trying to or a existing company trying to launch a new product, you also have to be quick to pivot depending on market reaction. In this case, the reason for system integrators is that
⁓ a lot of the they personally usually don't want to pay for a tool, but if they had to, a lot of the competitors are extremely expensive based on number of seats, which they cannot justify because they're building something for their customer. ⁓ but they want to improve their quality of delivery and they want to improve how fast they onboard new team members. So a tool would make that a lot easier, a platform, something that can support different dimensions. But then we have a partnership program that makes it really easy for
system integrators to also bring serpent to their customers once they're exiting the implementation for example especially that at this point if the the customer has internal team they're already familiar using serpent from the system integrator and they tend to like the boutique system integrators start at like 25 30 people if you multiply 25 30 people by I don't know $300 per month you get a sizable bill per month while at serpent we don't bill per
Scott Covert (:
Mm.
Rimon Hanna (:
user we bill per usage credits so it's around like how much releases you've done how much deployments you've done and that makes it more like dynamic if one customer doesn't you know as a user I don't consume much I'm not using much I have one customer ex commu consuming too much for me okay then maybe I need to think about ⁓ billing that customer for the usage because it's all tracked per project and you can have we have the concepts of projects so you can you know link it to your project management as well like JRA or notion.
Scott Covert (:
interesting. Okay.
Mm.
Rimon Hanna (:
And you can check like in that project, I consume that much credits on Serpent. Maybe I need to pass that cost to my customer.
Scott Covert (:
Hmm.
That's very I could definitely see how an SI would want to sign up for that. Interesting that your pricing is usage based rather than seat based. I think it's a good time for that too. ⁓ maybe a few years ago ⁓ that would be harder for the market to wrap their head around. But I think with all these AI models and the push towards ⁓ usage-based metered pricing, ⁓ I think the I think the average user can wrap their head more around
as opposed to seat based. ⁓ so I could definitely see how, especially in an SI, if it's all tracked, how they'd want to jump on jump on serpent and leverage that with their customers. I've heard I've heard a lot of ⁓ ISVs talk about partnerships with SIs in particular as a useful growth channel. ⁓ and you mentioned that the y you can kind of get
Rimon Hanna (:
Mm-hmm.
Scott Covert (:
a bonus customer from that when they roll off of their implementation projects if they ⁓ if their end customer decides to keep serpent for their own DevOps use down the road. When do you have some sort of ⁓ referral ⁓ agreement for SIs ⁓ in that use case or how does that work?
Rimon Hanna (:
Mm-hmm.
Yeah we do. So we have like a
w something we built early on already in the first few months of launching Serpent is ⁓ a solid partnership agreement with ⁓ like three tiers silver, gold and platinum and ⁓ depending on the market the partner is being on boarded on, we can either on board on already silver or gold. Sometimes we skip. And you have to to maintain the tier you have to refer a certain amount of customers per year. or you can grow up a tier of course. And with
With a decent amount of referral, ⁓
revenue share for both like first year and renewals as well. So they they they if they keep engaged with the customer and they help us stay there as well and they are bringing us also like more business, they're also growing their business and they're also kind of taking a discount, maybe even making a profit over that partnership. Because at the beginning they discount their own subscription basically until it's zero and they're getting more money ⁓ out of that partnership. Yeah.
Scott Covert (:
Mm.
Mm.
It's I love I love strategies like that. That can be a win-win for everybody. So that makes a lot of sense. ⁓ I wanna talk a little bit about ⁓ the the unique space you're in given that Salesforce does have their DevOps center ⁓ platform. Has that ⁓ product been
caused any headwinds ⁓ for you and your team? Do you have customers that ⁓ you're trying to or or or I guess leads I should say that you're trying to get ⁓ onto Serpent off of DevOps Center? ⁓ or has that been yeah challenge for you when you're you're in these discussions?
Rimon Hanna (:
Well, it already came up in the market research because DevA DevOps Center was already launching ⁓ its first beta back then. And
Scott Covert (:
Mm-hmm.
Rimon Hanna (:
The thing is like actually linking up to a question you ear you asked earlier and maybe I didn't fully answer it, is that in the market research we realized that a lot of the pain points we had was not solved at all and a lot of people had them. So ⁓ and and I think another validation that came is that there's a lot of more niche competitors that are trying still to try and solve their problem because no no big market shareholder has finally solved that main problem. We're hoping to be that one. ⁓
Scott Covert (:
Mm-hmm.
Rimon Hanna (:
trust but ⁓ basically like this main workflow oriented delivery that does git in the background and enforces source tracking right otherwise it's a waste of time if you consider source control as as a backup but anyway we noticed that
DevO Center users tend to start come from chain sets to DevO Center first because yes, it's free, it's available, it's also like first party to third party. So everyone's like, okay, it's a no-brainer, let's give it a shot. And then after a while of trying DevOps Center, they're like, wait, I'm missing this and I'm missing that, I'm missing that. Do I look for a vendor maybe for those extra things? They look for a vendor, then realize that the vendor can also do what DevO Center does. And I think
Salesforce is not prioritizing DevOps Center that much because it's a free product. So unless they come up with a commercial plan to monetize it, it still is an afterthought.
Scott Covert (:
Mm.
Mm-hmm.
Rimon Hanna (:
And that's
why it's not growing as fast every year. I was wondering if we should keep investing in Serpent or Pivot, if they are going to push DevOps Center, like as far as out the whole market share. But it turns out like for now it's not, and if they do, then they're gonna release it as.
Scott Covert (:
Sure.
Rimon Hanna (:
So then you're back to competing as just another third party.
Scott Covert (:
Gotcha. Okay. So that's interesting 'cause I I've talked with some ISVs that have th that that sort of play in the same space as a Salesforce offering. And they've mentioned that they don't exactly feel the love from AE's and S E's because they they'd rather push ⁓ clients toward the Salesforce add on tools. in the case of DevOps, given that doesn't lead to any additional revenue for Salesforce, it seems like more of an even playing field. ⁓
Rimon Hanna (:
Definitely.
Scott Covert (:
Yeah, so
Rimon Hanna (:
Exactly.
Scott Covert (:
very cool. And c could you give viewers and listeners an idea of the the size of of Serpent today in terms of employees, ⁓ customer count?
Rimon Hanna (:
So we're thirteen people, ⁓ mostly developers. and ⁓ we have ⁓ like across UAE, Egypt, US and the Netherlands. And ⁓ we have customers all over the world. ⁓
Like I'm sometimes still surprised the signups we get ⁓ are from regions we have not tried to target at all. So s that's quite positive. I'm happy with that. And we have ⁓ over sixty customers at the moment using Serpent ⁓ on day-to-day basis.
Scott Covert (:
Wow, that's great. And that and that's after only just a you said about a year and a half or so? Wow, that's that's some great growth. Okay, so what are you doing? ⁓ you mentioned the Reddit community. Is that where the majority of these these leads are coming from? Or are you doing any outbound? What's your what's your lead gen, your main growth channel spin for lead gen?
Rimon Hanna (:
Yeah, yeah.
So R Reddit was great for the initial private beta testing and getting some signups early on to check it out and get some feedback. And then ⁓ later on it became more of like a marketing channel. So like not that high number of leads, ⁓ growth. but in terms of ⁓ sales we're doing direct sales mostly and ⁓ going to events, a lot of the Salesforce events, the community events.
like maybe thinking about going to Dreamforce again this year, ⁓ not entirely sure yet. ⁓ but the smaller events were very effective because you get like a like ⁓ a cozy conversation vibe where we actually get to know each other and the conversation kind of rolls on naturally where you don't not forcing any cell or anything, you're just mentioning what you're working on, right? And
Scott Covert (:
Mm.
Rimon Hanna (:
people might get curious and ask more questions. You also get curious about their building and you learn from each other and you help each other grow. So I think that that that's the biggest channel for us.
Scott Covert (:
Hm, very cool. Yeah, and and would you say I know initially you were building for IS the ISV use case. what is your customer split right now? Would you say you're still mostly building for ISVs or has the the kind of c Salesforce customer ⁓ user persona taken over?
Rimon Hanna (:
They have a bit. so they're about now sixty percent. So now our ISV user base is about forty percent. And I can imagine as we grow that's that will still be even more imbalanced because just the numbers. ⁓
Scott Covert (:
Okay.
Rimon Hanna (:
But ⁓ but we still wholeheartedly support the ISV process and keep growing that part because it's where we come from and we are actually a user ourselves. from like Serpent is part of Tekunda and Tekunda is also Salesforce ISV and a PDO. So we build a lot of products on Salesforce and we use it day to day to be able to deliver.
Scott Covert (:
Mm-hmm.
Gotcha. So that's this that explains the the ⁓ experience and the the lived experience of dealing with Salesforce DevOps and the challenges there. if you're a PDO, you're building packages all the time. Very cool. Okay. you mentioned that the team ⁓ size about thirteen today, mostly developers, ⁓ and yet you're also targeting a lot of enterprise. Do you have any ⁓ sales or biz dev ⁓ team members that are helping go after those those larger
Rimon Hanna (:
Definitely.
Definitely.
Scott Covert (:
Customers.
Rimon Hanna (:
Yes, so we have we are for business development, ⁓ so myself included and someone in Egypt, someone in UE, and someone in the US. And we have someone that's also joining on a part-time basis here in the Netherlands.
Scott Covert (:
Very cool. And were those w did you first start hiring first of all, how long into the Serpent's history did you realize it was time to start hiring and growing the team? And ⁓ second, which hires did you make? Did you hire up developers first or did you immediately start building out this the biz dev folks?
Rimon Hanna (:
⁓ definitely the developers first, especially that we started before the AI coding era. So like we launched about ⁓ a year and a half ago, but we started development of the MVP three years ago, right? So it was before the AI assisted coding, so ⁓ you needed a development team to be able to deliver a product and bring it to production. And we had two first hires which were two engineers and they helped build the first version of Serpent that came to the market and then ⁓
Scott Covert (:
Mm, okay.
Rimon Hanna (:
we kept adding engineers, engineers and then just before go to market, that's when we started looking for business development and we actually had our first business development hires joining a few months after launching.
Scott Covert (:
Very cool. ⁓ yeah, so so you since you brought up AI, ⁓ you had also mentioned that it was ⁓ there's some AI features in Serpent today. But I'm curious if could expand on how AI has changed kind of your strategy for Serpent. ⁓ obviously it's impacted your roadmap given you have some AI features embedded. Could you speak to that a little bit?
Rimon Hanna (:
Sure. ⁓ it it definitely changed a lot of things. It actually changed also our first of things, ⁓ changed our ability to deliver faster. So like feature to production now sometimes takes ⁓ a few days. we actually release every day.
Scott Covert (:
Mm.
Rimon Hanna (:
We've always had this like mentality of releasing every other day ⁓ from day one, but it made it a lot easier to release even more within the day, zero downtime for the user and getting features delivered directly to them. Sometimes we deliver those features behind feature flags so they they're not disruptive to the user experience. but a lot of the times they just because they're new features or extra sections in the web app, so they they don't really intervene or disrupt the
the the existing user flow and it changed our roadmap in a sense that we realize we can do a lot more than we could before. And then that that's just amazing benefit for everyone involved. So the first problem we solved was ⁓ the conflict resolution. It was a no-brainer. Like it's just ⁓ so many people don't even understand how to resolve a conflict manually in the Silver ecosystem and just that takes care of it.
I mean, even if it made a mistake five percent of the time, then you can you're dealing with five percent mistake rather than dealing with a hundred percent of it. And ⁓ if I talk about also other use cases, there is ⁓ and that's the one I'm ⁓ the happiest with because it came from a customer. We were talking with a customer and they expressed a pain where they spent three hours manually selecting the autodetected changes out of SMBox.
Because there were multiple people working on the same sandbox and they had three features on there. They wanted to cherry pick basically one of those three pick features. And although already Serpent makes it really easy to detect changes on the sandbox because it auto detects the changes and you don't have to select manually any metadata types like ⁓ any other tools would ⁓ would need. In this case
Scott Covert (:
Mm.
Mm-hmm.
Rimon Hanna (:
All the changes were too many. They wanted to cherry pick and they spent two and a half hours almost three doing that manually. We released a feature that uses AI where you explain your feature to it and it will cherry pick it for you.
And select the features and you can still review it and you know make any modifications if something was wrong, but most of the cases 100% right and you just it also shares like confidence on the selection and why it made that selection based on your explanation. yeah.
Scott Covert (:
wow.
This
is very cool. I can I so I can picture on the development side in Git going through these exact same challenges. I remember the first time doing merge conflict resolution in Git. It was very very daunting. and then you know, I've I've done you know, gone through ⁓ cherry picking Git commits before.
Rimon Hanna (:
Yeah.
Scott Covert (:
⁓ and that can be that can be a pain. And that's just at the at ⁓ at the source control level with Git. ⁓ I can't imagine an admin going through those same pain points ⁓ that maybe is looking at through the lens of just the Salesforce UI. That sounds ⁓ unbelievably frustrating. So it's very cool that you're ⁓ building out solutions to that using AI. That's very, very, very cool.
Rimon Hanna (:
Yeah.
I would say like the the last thing is that personally I use every other day whenever I'm working on a Salesforce project is the MCP server. So for people that are not familiar with MCP, it's the Model Context protocol and it's a protocol developed by ⁓ like developed for AI agents to be able to communicate with APIs. And we have a serpent MCP and why is that available? How is that different for example than just using Claude or codex
Or whatever with Salesforce Cli. Well, Surf4CLI would just immediately deploy or might make a mistake or something like this. It doesn't go through the gates and checks that Server already has. So it wouldn't plug into a workflow that involves other people. It's still directly communicating with an org and it could cause mistakes. It can also deploy things you don't want to deploy, etc. So using the MCP, it's able to still plug into that serpent workflow and other people that are still using the web interface.
Scott Covert (:
Mm.
Rimon Hanna (:
They can use the web interface while a developer or an architect can just work directly with Cloud, for example.
Scott Covert (:
wow, that's very cool. ⁓ okay, well so obviously
Coming from a PDO background and obviously building for ISV use cases, ⁓ ISVs are near and dear to your heart. We got connected actually through ISV Forum ⁓ of prior guests to the show, Andre van Campen. Maybe you could share a little bit about ⁓ your involvement in ISV Forum and how that's helped you grow Serpent.
Rimon Hanna (:
Of course. ⁓ I got to meet Andre about a year ago, ⁓ maybe a little bit over that, at one of the Amsterdam user groups. And ⁓ yeah, we had a click from the beginning and we stayed in touch and I attended a lot of those events here locally in Amsterdam and that's when he introduced me to the ISV forum. And ⁓ just recently actually this summer I got invited to ⁓ a
co-host the ISV forum in London and speak about the challenges that we have as an ISVs to deliver on the platform, go through security review and and app exchange listing and and also how to be able to deliver using Serpent and Clean Git ⁓ and you know DevOps for ISVs. And it was a like an amazing experience and connected with amazing people there and stayed in touch through the WhatsApp group. ⁓ and
I think that's what I was mentioning earlier, that the best part in the SelfRooks ecosystem, it's his communities and how you can learn from each other and add to each other's value. And I think that's how I got introduced to ISV Forum and how it became a ⁓ a contributing thankfully a contributing ⁓ member and hope to keep doing that.
Scott Covert (:
Yeah, I love that story. ⁓ obviously I completely agree. that's one of the main motivations for starting this podcast, actually, right? So with that, ⁓ we should wrap up. So but before we do, I I wanted to ask if you had any in in the interest of community, do you have any advice to ⁓ kind of early stage founders of ⁓ ISVs that are viewing or listening right now? ⁓ some some lessons learned through the trenches.
Rimon Hanna (:
I think the most important one is released as fast as you can. ⁓ even of no matter how small what you have is. If it's if even if it's in your mind not complete. I know a lot of us struggle with that. I still do until today. I'm not gonna say I I'm perfect at it, but
Even if you think it's too small, sometimes it's valuable enough for someone to already buy it or validate it. ⁓ but also for security review, the smaller the package you wa you go through security review, the less the chance they will mu find anything to flag. So very important release as soon as possible and and then iterate, iterate and be flexible to learn from feedback.
The faster you change and and and manage feedback and listen to your your potential users and customers, ⁓ the better you're building a product that actually people use.
Scott Covert (:
Yeah, I love that. Well, ⁓ that's that's very very s good tactical advice. thank you, ⁓ Rimon for for joining Assembly Line today. If folks listening want to get in touch with you or learn more about Serpent, what is the best way for them to do that?
Rimon Hanna (:
Well you can also connect with me on LinkedIn, Rimon Hannah, but also our website tukunda.com ⁓ slash serpent or check out serpent uh.cloud. these are all different channels. ⁓ find us on LinkedIn as well. Alright.
Scott Covert (:
Great.
Yes, we're ready. Well thank you again. ⁓ really appreciate you you joining today and best of luck to you and the the serpent team.
Rimon Hanna (:
Thank you very much for having me, Scott. It was a pleasure. Have a great day.
