Discover how Simon Wijckmans, founder and CEO of c/side, is revolutionizing client-side security by tackling the hidden risks of third-party scripts that traditional cybersecurity solutions miss. Learn why dynamic threats in browsers demand innovative monitoring and how c/side empowers organizations to protect sensitive data while enhancing website performance.
In a recent episode of Brand Story, Simon Wijckmans, founder and CEO of c/side, discussed the critical need to secure third-party scripts on websites, a frequently overlooked aspect of cybersecurity. Drawing on his experience with companies like Cloudflare and Vercel, Wijckmans outlined why traditional methods fall short in addressing dynamic threats and how c/side is redefining client-side security.
Third-party scripts—commonly used for analytics, marketing, and chatbots—are vital for website functionality but come with inherent risks. These scripts operate dynamically, allowing malicious actors to inject harmful code under specific conditions, such as targeting particular users or timeframes. Existing security approaches, such as threat feeds or basic web crawlers, fail to detect these threats because they often rely on static assessments. As Wijckmans explained, these limitations result in a false sense of security, leaving businesses exposed to significant risks.
C/side provides a proactive solution by placing itself between users and third-party script providers. This approach enables real-time analysis and monitoring of script behavior. Using advanced tools, including AI-driven analysis, c/side inspects the JavaScript code and flags malicious activity. Unlike other solutions, it offers complete transparency by delivering the full source code of scripts in a readable format, empowering organizations to investigate and address potential vulnerabilities comprehensively.
Wijckmans stressed that client-side script security is an essential yet underrepresented aspect of the supply chain. While most security tools focus on protecting server-side dependencies, the browser remains a critical point where sensitive data is often compromised. C/side not only addresses this gap but also helps organizations meet compliance requirements like those outlined in PCI-DSS, which mandate monitoring client-side scripts executed in browsers.
C/side’s offerings cater to various users, from small businesses using a free tier to enterprises requiring comprehensive solutions. Its tools integrate seamlessly into cybersecurity programs, supporting developers, agencies, and compliance teams. Additionally, c/side enhances performance by optimizing script delivery, ensuring that security does not come at the cost of website functionality.
With its innovative approach, c/side exemplifies how specialized solutions can tackle complex cybersecurity challenges. As Wijckmans highlighted, the modern web can be made safer with accessible, effective tools, leaving no excuse for neglecting client-side security. Through its commitment to transparency, performance, and comprehensive protection, c/side is shaping a safer digital ecosystem for businesses and users alike.
Learn more about c/side: https://itspm.ag/c/side-t0g5
Note: This story contains promotional content. Learn more.
Guest: Simon Wijckmans, Founder & CEO, c/side [@csideai]
On LinkedIn | https://www.linkedin.com/in/wijckmans/
Resources
Learn more and catch more stories from c/side: https://www.itspmagazine.com/directory/c-side
Are you interested in telling your story?
https://www.itspmagazine.com/telling-your-story
Breaking Down the Complexities of Client-Side Threats and How to Stop Them | A c/side Brand Story Conversation with Simon Wijckmans
Please note that this transcript was created using AI technology and may contain inaccuracies or deviations from the original audio file. The transcript is provided for informational purposes only and should not be relied upon as a substitute for the original recording, as errors may exist. At this time, we provide it “as it is,” and we hope it can be helpful for our audience.
_________________________________________
Sean Martin: [00:00:00] Marco.
Marco Ciappelli: Sean, what's going on?
Sean Martin: It's uh, story time.
Marco Ciappelli: I know.
Sean Martin: It's our favorite time of day.
Marco Ciappelli: My favorite story. My favorite kind of story.
Sean Martin: It's the, it's your story.
Marco Ciappelli: When we figure out what's going on. Yep. That's right.
Sean Martin: Exactly. Exactly. Well, I'm uh, I'm thrilled that I don't know that we've actually had many chats on this particular topic.
So I'm, I'm thrilled to uh, introduce our guest. Simon Wickman. Simon, how are you?
Simon Wijckmans: I'm doing great. How are you?
Sean Martin: Doing very well, doing very well. Thrilled to have you on. And, uh, we're gonna hear, uh, a good bit about, uh, seaside. dev. And, uh, looks like it's all about securing and optimizing, uh, third party scripts.
Which is, uh, slightly different than some of the other stuff we've had conversations around. So I'm excited to learn about what you guys do and, and why, uh, Why you do it is usually a story behind this, [00:01:00] and that's what we're getting into. Um, actually, if you can maybe start with a little bit about yourself, some of the things you worked on prior to Seaside.
dev to kind of give us an understanding of who you are. And, uh, and that will probably lead into why Seaside. dev exists as well, I presume.
Simon Wijckmans: Yeah, sure. So hi, I'm Simon. I'm originally from Belgium, uh, currently spending most of my time in London or visiting San Francisco because that's where the company is.
Um, basically did, I built my career from like when I was 16, I became a contractor at Microsoft to going to smaller companies, went from big to small. Um, spending a few years at CloudFlare during its growth day, growth stage when it went from a thousand people to about three thousand people. Um, then worked at Vercel for a while where I then built their front end security products.
And then I ended up building Seaside. Um, because I recognized that there was a kind of forgotten about spot in security and that's actually what executes in the browser of the user when they go to your website. That's where a lot of the data theft [00:02:00] happens and also where a lot of confusing problems live.
Um, And I was working on that before at Cloudflare, so I recognized the issue. And I also realized that large security companies that built a little side product for that space, um, were not really successful at solving that issue. So I wanted to go ahead and build my own company around that.
Marco Ciappelli: What, why do you think that was the case?
Simon Wijckmans: So it's interesting because large security companies, they often talk to their existing customers and they tell them all sorts of things that they are also looking for a solution for. And then it's rather quick and easy for them to go hire an intern or assemble a little project team to go ahead and build a very small MVP.
Then they end up reusing data that they already have, right? That works for a lot of things. But the problem with client side security is that it's an inherently different problem to solve than a firewall or something that you would get through a threat feed for. Why? Because it is a fully dynamic problem, right?
Every [00:03:00] user that uses the website fetches a third party script and that third party Can respond with a new thing anytime, right? So if a bad actor manages to pull off a hijack of some sort, they can inject a malicious script one cent of the time, specifically executing if a specific condition is met. So if a user agent, um, meets a certain requirement and it's a certain time of the day, uh, then you could get a bad script.
So then reusing. services that you use for a hundred other purposes, or just reusing virus, total straight feed, you're not likely going to actually catch the attack through that. Um, I like to give a clean example. If a small regional bank in a small European country were to get targeted with a client side attack, the bad actor could steal absolutely millions, right.
And cause a really serious incident. But it could fly below the radar of a threat feed because that threat feed provider would not be able to scan that third party script as if it's a real user coming from that particular website using that referrer [00:04:00] header. And so it's just a fundamentally broken approach.
Um, that basically any large security company that doesn't have client side security as their core focus, they've made that mistake. Um, and it just fundamentally cannot work, leaving people at risk and causing a false sense of security with companies who buy their products.
Sean Martin: So where, where does this fit into kind of the broader, uh, cybersecurity program?
Um, obviously we're talking about monitoring here and hopefully some, some blocking and tackling and protection as well. Um, but who, who typically owns this part of, of the program? Is it in, is it in development? Is it in endpoint? Is it in? Networking across across those things or where does it kind of sit?
Simon Wijckmans: Well, I would say it's more on the side of development and I mean, the slightly longer answer there is that usually the developer is the one that has to put that third party script there, but they're not the ones that have actually chosen that or have any impact on why they chose, like why [00:05:00] that tool had to be implemented and how it has to be implemented.
So it's usually the marketing team asking to add a tool, the legal team asking to add a tool, the sales team wanting to add some chat bots. Um, and these are all third party scripts and the developer then adds it and it kind of ruins the performance of their site or it breaks certain things and then they're unhappy about it.
And then a few years down their line, they figure out that those scripts are actually listening to people's login credentials and now they're on the dark web. And all of those types of incidents, they fundamentally lead back to the developer, even though that they're also a victim in this type of situation.
Um, it's funny cause the world has kind of shaped supply chain security around what the vendors have to offer. But I personally see client side execution of third party, um, like JavaScript as something that is part of the supply chain. Um, you should also be aware of what the libraries you add do in the browser.
It is part of supply chain security in my mind. But yet, if you buy any supply chain focused product today on, like, on the market, it's going to mostly talk about Open source [00:06:00] dependencies on registries like node package manager and the like. Um, and they're often great at that, but the browser is totally not in focus for those companies.
So it's sort of an, and it's not an, um, or you have to also monitor the client side scripts.
Marco Ciappelli: So Simon, before we go into what you guys do more specifically, I'm curious still about the origin story. Like you have a vision and then you, you implement it, you create a company. Have you had some moment since when you actually started the company that kind of like you kind of change your mind or adjust as you were going?
Or is it like clear paths from day one?
Simon Wijckmans: I think when I started the company, just the sheer amount of attacks that we have noticed. It has been absolutely baffling. So, um, the media doesn't really like to cover the same kind of problem over and over and over again if there's no solution for it. Um, and in fact, a lot of [00:07:00] security insights, even at very high level, executive level, um, is fueled by what goes into the newspapers.
So I think that was a clear moment. I was like, Oh my God, we're actually onto something here. Um, I think taking a few steps back, why I thought that going into client side security was a valuable thing to do. Well, we spent collectively as an industry, billions on firewalls to protect our infrastructure, to act as a perimeter, either as actually a metal box or a slightly modern version of that virtualized thing, living on an edge.
Um, but we also spend now billions on open source security, uh, monitoring. So tools that are quote unquote supposed to protect your supply chain, but they really only focus on those, um, like dependencies that live on our registry. But then equally, we don't do anything in a browser. And a lot of these attacks were like where data is being stolen.
The data is resold again on a dark web or gets used as, um, basically a piece of the [00:08:00] puzzle to get money off of businesses, uh, in order to not make it public. But it's very hard for any security researcher to trace back how the data was stolen, especially when it executes in the browser. Because there's often no data available about that.
So I just kind of saw the logic that we protect our servers. We protect our open source dependency. So that part of the code base is safe. We don't actually know what's happening in the browser and it just makes logical sense for us to, well, start using less than this client side fetch, uh, services. But you're never going to be able to avoid them in full because a lot of these services just need to be dynamic.
Um, but then at least monitoring the behavior of those in the browser for user, 100 percent of the time coming to the point that I said earlier, every request can make for a different response. So the only real secure way to deal with this problem is by not applying any level of sampling, just being there a hundred percent of the time and recognizing that this type of attack is dynamic and needs to be monitored.
Sean Martin: So you mentioned [00:09:00] some of the teams that that request these scripts to be installed. Marketing, obviously one of the more more prevalent ones I would imagine. But what is what are some of the things that that organizations are deploying script wise that you found to be vulnerable? I don't know if there's one that stands out or a few that stand out.
Because what I want to do is maybe highlight for people listening to say, or to recognize that. We probably have a script like this running and we don't have a mechanism in place to monitor and find and, and do something about most of this activity that's taking place there. So we can kind of paint that picture.
That would be fantastic.
Simon Wijckmans: Yeah, of course. So, I mean, something that I suggest to anybody is you're probably going to have a lot of scripts on your website you don't even know about. Um, so go to c site. dev, enter your site, and we'll tell you what's there. Um, the scripts I personally see being the source of the majority of incidents is [00:10:00] non traditional ad marketplaces.
So of course, if you use Google ad space, you're probably going to be fine because they've gotten their eyes very clearly on which APIs a ad can use and which ones they shouldn't, but there's a lot of these ad vendors out there that are not as advanced in their security. Um, so that would be one. Um, marketing tools by small startups is another one that I find particularly messy, um, or honestly, even any type of tracking by small startups that are not necessarily engineering or security minded.
Um, and the reason why is because, well, acquisitions happen and companies sometimes unfortunately cease to exist. And the reality is that those domains, they become an incredibly powerful tool to a bad actor. And so does their S3 storage or wherever they're actually hosting the payload of those scripts.
And when the engineers are no longer around, then slowly the information starts seeping away. Before you know it, There's actually domains living, like, that you can buy [00:11:00] on GoDaddy today that are actually implemented in third party scripts. Like, we've been sweeping up a few of those, just buying them for marketing purposes and to prevent them from actually executing bad things for people.
But that is a very clean example. A tiny startup that isn't particularly security engineering minded, that doesn't necessarily have resources to maintain the service long term. So, Well, those are quite easy targets. Um, it actually got particularly worse when Google Chrome started blocking pop ups because it's basically blocking the symptom of a malicious third party script.
Because, well, what do, what does a third party script often do? Well, a very visible thing popping up another page. Um, by just blocking the pop up, the malicious JavaScript is still there and that script can do anything very well, low profile as well, right? So like listening into data, you fill into a certain input box or, um, even mining crypto, we've got a little demo website that we built with that.
Um, you can do all sorts of crazy stuff with these third party scripts and pop ups was just [00:12:00] the most annoying one. So they blocked the most annoying one. Um, that this, all of the other stuff is still happening.
Marco Ciappelli: Hmm. That's interesting. It's like, uh, I'm thinking like you, you get your body take, uh, gets temperature that show you that you have, uh, some kind of a inflammation in the body or fighting something.
But if you don't have temperature, like, Oh, I'm feeling fine, but something keeps happening underneath. So it's kind of interesting. Are you guys using AI and how, how is involving the, in the product that you have?
Simon Wijckmans: So, of course we do. Um, AI is incredibly capable. Yeah, of course.
Marco Ciappelli: Let's have a shot. I said AI.
Simon Wijckmans: Yeah, AI. Um, so, I mean. It's incredibly powerful when it comes to parsing through JavaScript, and that is a fundamental thing when you try to understand what a piece of code does, then yeah, LLMs are pretty great. So let's [00:13:00] talk about kind of the fundamentals of how Seaside works in comparison to how other solutions in the market work, right?
So there's a couple of categories of solutions out there. So the first one is one that basically uses content security policies. I think a lot of people know what content security policies are, but basically what they are is a little header you add to your response from the server. And you basically define which third party URLs are allowed to be fetched.
So you define, I trust everything that comes from Marco. Basically, you don't define what you're getting from Marco, you're defining anything that comes from Marco with that particular URL is fine. So it doesn't understand payloads, right? And then what a lot of these security solutions do is they take any of the violations and they review them against the threat feed.
Well, again, coming to the point, thread feeds are probably not going to work for this attack vector because it's fully dynamic and thread feed vendors would have a hard time seeing the data in the first place. So that is one approach that doesn't work and you'd be surprised there's some incredibly large vendors that fully adopted only that approach.
So those you can [00:14:00] Basically throw away from the first get go, they will not be able to detect any advanced style of attack. Then a second method is, um, basically the fully client side JavaScript based approach. So where you monitor the entire behavior of whatever happens in a browser using a JavaScript.
But the problem is that it's very hard for the JavaScript of the security company to take the upper hand over the other ones. Um, and mostly if you define specific hooks, you are monitoring in the browser for user, a bad actor can very easily reverse engineer that and just not do that, right? So if you define a list of don't do these behaviors, it will trigger an alarm, then they will crawl over and under it.
And in the world of JavaScript, there's plenty of ways you can do that. So it's quite easy to be successful with that. I would say that's probably one of the more successful approaches to monitor client side scripts. Uh, there's a few companies that do that, but they're very niche and specialized. And I must say, they've also spent a substantial amount of time and money on building that.
Then there's the third, third approach that honestly is, I think the worst one of them all. [00:15:00] Um, and that's just a crawling approach. So they crawl a website periodically and tell you, yeah, all is fine. Um, but the problem is that if you're using an AWS IP address, Um, And you're crawling a website. Well, the bad actor could very easily say AWS IP, give them a clean script.
Right? So it's just, that's an like utterly bullshit approach, right? Like it's just not going to work. Um, and unfortunately there are lots of companies out there selling that particular approach. We take the much more, I would say painful approach, but it is also the really, really the only way that you have more certainty.
We're actually putting ourself between the third party and the actual user. And why? Because that way we see the code and we actually get an understanding of what is being delivered. So think about it this way, right? So either you use our node package manager, um, like build package, which at compile time, depending on your framework, rewrites these third parties, or you use our client side script that basically forces things through our proxy.
And then we also monitor the [00:16:00] behaviors client side. So we have the full code, we see it, it flows to us, we analyze it using a range of detection mechanisms, one of which is using AI, but most of them are using other types of triggers as well. Um, and then, yeah, if anything looks bad, um, we would be able to detect it and stop it and therefore that script would no longer be served.
It's interesting because the, oh, sorry, go ahead. It's interesting because the immediate next question I get is, Simon, doesn't that add latency? And then my answer to that is, well, anything in this world would add latency if you add it to the chain, if it was already optimized. I think any developer knows that the internet ain't optimized.
So, um, if you're just a little bit better than whatever that other solution is, you can do great things. So what we've seen is that by using just protocol enhancements, upgrading connections to use things like HTTP2 or HTTP3, we can already cut the little latency that our service adds. Um, and if the script is cacheable, which many of these scripts are, then we can actually make the scripts [00:17:00] faster.
And the way we cache is just a little bit more optimized than a generalist CDN. A generalist CDN has to provide support for very large File sizes up to a couple of gigabytes often. Well, third party scripts are often usually less than a megabyte or just a megabyte or two. So that makes for a way less complex store strategy where we can actually store things in memory at our edge locations, making it a lot faster.
We do not sell a firewall or bot detection in flow of requests or a rules engine or anything like that. So our CDN Pretty straightforward. It has some DDoS protection and you go to a storage later, right? It's bada bing, bada boom. It makes it a lot faster. So, and that to give you some idea, we've got an analytics script, um, like that.
We tested this with, it took 78 milliseconds to fetch it directly from their third party end point. And, uh, Um, if you put us in the flow of the request, it would only take 48 milliseconds. So that's in the case of Cacheable. In case a script is already fully optimized and we can't improve it in any way, [00:18:00] shape, or form, well then be ready to expect a five to seven millisecond latency added.
Um, but then most of these scripts are fetched asynchronously or using the defer method in the browser. So it's not actually going to be noticeable. And even for SEO, it hasn't proven to be that impactful either. So. It's, uh, yeah, I think we kind of have to be okay that in some cases, it's going to get faster in a very small percentage of cases is going to get a little slower, uh, but then at least you gain a lot of insight and security, which can prevent a much worse incident.
Sean Martin: Let's talk about you. You're right. I was going to ask about the performance and the latency and. I was going to lead it with where, where do you sit in terms of, uh, your analysis and, and your presentation of what you find and, and to your last point, um, the response to that. So, so maybe you can kind of describe where you sit in the, in the stack and then what does the response look like?
Is it, can the admins and developers control [00:19:00] what happens? Is it automated? Can they, can they tune that to what they want?
Simon Wijckmans: Yeah, of course. So we try to create, we've tried to create, it's like the lowest amount of noise possible. Um, well, because obviously there's already plenty of alerts happening. So we integrate with SIEM systems of vendors so that they have the data in the place that they want to have it.
Um, we've got webhook support, so you can get it in Slack or whichever other chat tool you use, including Microsoft Teams would have thought. Um, and we basically focus on the. Known evil, right? So I'll give you a clean example. If a script, um, sent information to API dot reputable vendor. com last week, and this week it also sends the data to a newly registered domain name with IP addresses pointing to a residential IP in Russia.
That's probably something that needs to be blocked, right? And so we've got the ability to autonomously block things where we have a high level of confidence that it is bad. And [00:20:00] so those types of very clear incidents would be able to just take action on your behalf and you would thank us after, right?
Because even if we take down that script, you may lose some functionality and usually it's some type of analytics or ad or chat bot on your website. It's not going to entirely break your website. This is going to break a very specific type of functionality. Um, but then you stopped an incident, right?
That's a potential lawsuit prevented or a potential major incident that you'd have to do months of investigations into. So in those types of situations, I think we're like the blocking approach is the right one. In cases where we're not a hundred percent sure, but it looks like suspicious behavior, you could basically ask us to either quarantine, which means at the best of our ability, put us in quarantine.
Um, continue to serve a previous version of that script, um, or just let it continue to do its thing and we just notify you and you then go into our dashboards and have a look. So one of the neat things that our solution does that none of our competitors do, we actually give you the entire source code of the script.
And you go into the dashboard, even on our free tier, you [00:21:00] can see the actual code of the script. You give it to you in a normalized, cleaned up, de minified, and if it's possible, de obfuscated version. You can actually read the code and understand what it does. Um, That is your ability to then dig deeper. We also have like the LLM explaining why we blocked it.
So it's. This script was blocked because X, Y, and Z, um, and we can even highlight pieces of the code. If it is related to the code, sometimes it's related to, like, the domain or the IP or the infrastructure or potential indicators of a man in the middle attack where multiple SSL certificates were issued in the last day.
That sort of thing. Um, So yeah, I think, I mean, it's quite a comprehensive thing and we're constantly adding new detection capabilities, but our ultimate goal is to make this a low touch product that just blocks and then notifies you telling you, hey, We've stopped a pretty painful incident for you.
Marco Ciappelli: Hey, tell me, tell me who is we?
Because I went on the about page and I see a little bit of the team and what is actually impressive is the amount of [00:22:00] investors that you have, like pretty high. High level, you know, expert that work in, in the biggest company actually that I can read. So tell me how the team came together. I'm going to go back in the origin story because Sean can get very operational.
So I want to go back to who is the company and who you work with to make it successful.
Simon Wijckmans: So last year, roughly around this time, um, I had a couple of conversations with some investors that I met throughout my career. And I explained what I wanted to do. And I mean, one of them I already spoke to in August last year, it's like, maybe I want to start a company like in two years from now, it'll turned out to be a few months later.
And I explained to him like, Hey, this is my prognosis, right? Um, we spent a lot of money on servers, uh, like infrastructure to protect our servers. We spent a lot of money on open source dependencies, la la la la. I worked on client side security in the past. I realized that most of the competitors in this space built crappy products.
Let's go ahead and build an actual good product in this space. And I already know who I want to hire. Um, in the [00:23:00] past I worked with these people, they have left Cloudflare at the time where I was, right? They've left, they've moved back to their native country, they bought a nice apartment, they're happy. Um, but they want to get back to work of course, um, I'm sure I could convince them.
Um, and so that basically ticked the box of, We know this guy, we can back channel him because these were investors that have met me throughout my career. So they knew who to talk to, who to ask about me. Um, then that also ticked the box of team, even though I was a solo founder, I had a clear path to having a capable team at solving the issue I wanted to solve.
And then, um, I mean, the problem was clear. I gave them examples of past attacks. I gave them examples of new Intel that I got. Um, yeah, and then one thing led to another and they recognize that, okay, this is probably a good time to build a company like this, especially with the compliance requirements also kicking in, in March, 2025 for a PCI DSS, so the payment card industry, digital safety standards, um, you actually have to monitor client side scripts in the browser.
Um, and so that's one of those [00:24:00] things where it's like, well, building a security company to solve a problem. Sure. But it's always great if there's also a compliance lever that actually pushes people to. Um, and so it made sense for these investors. Um, and then as a solo founder, I recognized that I needed coaching as I think everybody does anyway.
Um, And so I started like with the initial investor scribble that let our pre seed, I told him like, Hey, okay, these are the areas where I think I'm fine. And these are the areas where I need help. Which angels do you think could be helpful? They shared a couple of names and I spoke to them and then basically assembled the ultimate team of angels that I could ask anything to.
And they would have a material interest in helping me. They would get an immediate return out of it. So looking at the names, you've got people like Mike Taylor, You are currently the CFO at Gusto, used to be the CFO at GitHub, and then I think a VP of finance role at Tesla during the IPO. Oh, that's a person you'd want some help with if you need help with finance, right?
Um, and then there's folks like Dan Scheinman who are incredibly capable investors in helping [00:25:00] with, uh, go to market, actually had a full career. Uh, in the legal space at Cisco. And then he became an investor. And one of the first checks he wrote was zoom and Sentinel one and Arista networks. And so he became incredibly successful through that.
Um, and these are all genuinely amazing individuals that you ask a question, you get a response in the next two hours. And that response is the highest quality of feedback that you could ever get. Um, and so I've got 40 of those at this point where it's like, I need help with something and I get help with it immediately.
And also folks like the Chainsmokers, True Mantis, right? So if we want to work with a particular consumer brand, um, we can work with Alex and the folks at like Mantis to get an intro to these people. And these intros are usually a lot more high quality than me just trying to outbound consumers. Right. So yeah, I basically took my investors team as the extension of our founding team.
And that's also like they got the merchandise that says founding team on it at remind them that they're not just giving us money. They're invested. They're going to help us out and I'm going to make them work. [00:26:00] Super
Sean Martin: cool. And you said the magic words for me, go to market. Um, it's one thing to have a problem, even better to solve the problem.
The market has to be ready to, to pay to, to acquire the solution and, and have the team ready to, to, uh, deploy it. Right. Um, so talk to me a bit, a bit about who you speak to. I know we talked about it. This is kind of a dev solution, but who do you, who do you speak to? Who has the budget? How does it find its way into an organization, uh, where you can actually be successful in helping them overcome this challenge?
Simon Wijckmans: So. Um, I think the experiences that I've had at like ForSell, um, made me prevent a very bad mistake early days. So I recognize that the majority of companies have some type of agency involved in managing their websites or managing their security. [00:27:00] Or helping them with PCI DSS. So something we've done from day one with our product is we built our, like, just our organizational structure within the dashboard so that you could have a, an organization and teams.
And under those teams, you have websites, which sounds like a totally ludicrous thing to spend any time on in the early days of building a company. Well, the problem is if you do that later on, it becomes a much more fundamental problem and a much more painful thing to migrate. So we've done that from day one, and that allows us to integrate with the Any type of partner or agency.
So if you help your customers be compliant with PCI DSS, if you're helping your customers with security, if you're a consultant towards a company, if you're a web development agency, you can go ahead and acquire a product and add it to the website of your customer and it could protect your customer, but it could equally protect you, right?
Cause there's some, some countries around the world, um, agencies that added a third party script have been found liable. Many years after for what the third party script eventually became. So it's one of those things where we recognize it's [00:28:00] sometimes best to work with these indirect, like, platforms where people basically resell our product on our behalf towards their customers.
So we've done that. Um, we've got a free tier. That free tier is mostly there for security conscious individuals with a nice blog or some e commerce. Um, and they can go ahead and use our products and we're not going to try and immediately upsell them to a paid tier. It's honestly not even why it's there.
That free tier is mostly there because that way we get to see a bunch of scripts on websites that otherwise we'd have to try and get through other ways. And that are usually not as successful. So we just want as many people to use our product as possible. And it also solves the security issue for most, like, it's just nice to know that I can use my credit card on the web, but it's not going to get stolen on as many websites as a result of the actions we take.
We then also have a business tier, which is much more comprehensive and I think it's affordable enough. It's like a hundred dollars a month. Um, and that business tier should help small medium businesses that need some level of compliance that want some level of insights. But I mean, they don't [00:29:00] have thousands of dollars to spend on security every month.
Um, and that's okay. I don't think web security should be paywall to all the enterprises. That being said, the majority of our revenue will obviously come through enterprises. The people that actually understand that their head is on the line, their brand is under pressure, they need to have security in order.
Um, and that's where the enterprise tier comes in. So it's like, depending on the amount of traffic you have to your website, et cetera, it's an order of magnitude of a few thousand dollars a month. Um, it's cheaper than most of the side products of large security vendors. So if we get into a compete situation, we can beat them on cost and on quality, which is nice because.
Um, it's good to have both ticked. Um, but you can just go ahead and get our product, try it out. We'll happily do a POC with you. We'll explain to you how we're different towards any other solution in the market. In fact, something I've even done in the past is give them a quote unquote malicious script that we wrote ourself that they can just use in their testing of any solution they want to test.
And we're going to flag it obviously. And [00:30:00] some of the other security vendors that are good would also do that, but many of them won't. Um, and that just gives you an idea of, well, we're giving you the testing data, right? That's another major security problem. Like when reviewing solutions, do you actually have testing data that allows you to differentiate a good from a bad product?
It's particularly hard with client side security, um, because you need to have a malicious script on a domain name that's not flagged on a thread feed and actually have some traffic going through it or some weird behavior happening for it to trigger some like alert. We basically give that to our customers just to go ahead or prospect just to go ahead and make sure that they buy a product that's good.
Sean Martin: And I'm, I'm certain your experience at Cloudfire helps you, uh, and your other experiences I'm sure as well, help you really deliver to that enterprise, which is, it's one thing to. To meet the needs of the small medium business, but the scale up and probably the work you did in the dashboard probably helps, uh, with that as well scaling,
Marco Ciappelli: you know, I think is [00:31:00] I think is really cool.
And more and more. I hear a lot. A lot of companies that do address the small medium business problem. Like, like Simon, you said, honestly, it's like, that's maybe not where you're growing the company to, to exponentially, but I think it's very, it's very nice to be committed to protecting everybody to a certain level.
So that's really cool. Well, that was a good story. Much deeper than just the origin story, and I hope that you will come back and tell us more stories as we go. I know. Well, with Sean, you can be sure you're going to dive, dive really deep right away.
Sean Martin: I have many more questions, but, uh
Marco Ciappelli: I know. You have many more questions, but we'll probably ask them later.
Sean Martin: That was a fantastic overview, and, and it's a really cool solution. I'm glad, glad to see you, uh, bring this to market and, uh, to hear about your success, Simon. And hopefully people listening have Have a sense of how and where, [00:32:00] uh, seaside can fit in. And, and, uh, of course we'll include links to, to the website.
You, they can, they can drop their URL in there to get a nice peek at what's going on for themselves and, uh, and obviously links to, to connect with you. And they can, they can have their own conversation, ask their own questions of you and the team and, uh, and, uh, bring, bring this to, uh, to bear in their own organizations.
So any, any final words, Simon, before we wrap?
Simon Wijckmans: I mean, thank you very much. Very happy that I was able to have this conversation with you all. Um, and yeah, I mean, just make the web safer. Protect yourself. There's great solutions out there for free, and I mean, Cloudflare web security more accessible. You can protect your website with their free tier or spending 10 a month for a pro tier.
There's no excuse anymore for not having a secure website. Um, yeah.
Sean Martin: I love that. No excuse anymore. That's a, that's a good, good tag there. I like that. Yep. I like that. All right. Well, Simon, thanks again for, [00:33:00] uh, sharing the story with us and everybody listening. Appreciate you, uh, you joining us for this conversation origin story about seaside.
dev and, uh, hopefully more, more coming from Simon down the, down the line. And, uh, of course, stay tuned to ITSP magazine for more stories. Thanks everybody.
Marco Ciappelli: Thank you. Take
Sean Martin: care.