54. Simon Wijckmans, Founder and CEO of cside.dev, Revolutionizing Client-Side Security

Hello, everyone, and welcome to another episode of the Security Podcast of Silicon Valley. I am one of the hosts, John McLaughlin. I am joined today with Satya Sinkovich, and we have an amazing guest, Simon Wickmits. Excellent pronunciation.

Thank you. Thanks for having me. Thanks so much for having me. Welcome to the show.

You are the founder and CEO of Seaside. Yes. A security startup. Yeah.

Seaside. Seaside. Everything from the ocean to client-side security. I love it.

It sounds beautiful. Previously, you were at Hydra. You were a product lead there. You were at Vercel.

You were a senior product lead there. You were at Cloudflare before that. And founder even in your recent history, too. Joe the Fish.

A thing that's. . . Little side projects.

Little side projects. We love side projects. I think all great engineers have little side projects going all the time. Yep, exactly.

It was during COVID. There was very little else to do. Participated in some Mozilla incubator program. Made a little thing.

Got a little traction. Went back to work after. Do you brand yourself as a security person? Interestingly, yes.

Even though I've done many different things, I would say, in my career. I think I live at kind of the intersection point between good developer experience and security done more modernly. I would say that the security industry has a tendency to do the same things over and over again, even though that they don't necessarily work anymore. That is because a lot of these large companies, they're fully enterprise focused.

I personally don't find web security to be an enterprise problem only anymore. We've got to make it accessible to people. Therefore, experience of Cloudflare and Vercel bringing that together to build a more accessible security product that people can actually use and just swipe a credit card. That's what I like doing.

What is the main pain point that C-side is positioned to solve? There's this attack factor that we've known about for a while, and that is client-side security. Basically, in 2010, when JavaScript started getting actually built into browsers, there was a sudden surge of people using JavaScript to do malicious things client-side. Before that, we already had that happen for pretty much more than a decade.

You had the Flash players and the Java players and whatever essential mod you had to download for your browser to support dynamic things. Client-side, they suffered from a similar problem. The problem space got rebranded a couple of times, so all of a sudden it was called a mage card attack because Magento had some pretty severe security problems that allowed people to inject code under bad circumstances. For a long time, client-side security was called mage card security.

The more umbrella term of XSS, cross-site scripting, was also what we have referred to. But the logic here is quite simple. It's client-side security will only continue to become a bigger problem as we protect our infrastructure better, as we protect our open source dependencies that we use better to get deeper understanding of the code we write. If we then have a thing that allows you to bypass all of that, direct to the client, direct to the browser of the user and execute things there, that obviously becomes an interesting attack factor to bad actors.

So that's essentially what we're trying to solve here. You want to solve client-side security and also just do better web security using client-side Intel, starting with third-party JavaScript. So these weird scripts you got to add, like anything from tools like Intercom all the way to maybe jQuery being implemented using some CDN that you found online somewhere your junior engineer implemented at some point. And then recently there's been a big surge of these types of attacks and it's sad to see polyfill.

io, half a million people's websites being impacted. That was a severe wake-up call. Yeah. The adoption of client-side technology usually depends on how seamless that integration is.

How do you guys approach the integration of the C-side technology into the browser? Yeah. I mean, I took some mental time to iterate through the best ways of doing this. There were a couple opportunities that showed up in the market that allowed us to do a difficult thing that is actually the most user-friendly way.

So the way that it works is you basically add C-side as one of your first scripts to load on your website. And what it does is it rewrites all of these other scripts that you use and puts proxy. c-side. dev slash in front of it.

So instead of going to google. tagmanager. com slash gobbledygook, it's going to proxy. c-side.

dev slash google. tagmanager. com slash gobbledygook. That is a bit of a pain because now as a security company, you're running a proxy.

You've got to maintain that. You've got to keep it up and running. And you could make things slower if you don't do it well. And we did the hard thing of actually implementing this as well as we could to make scripts a little bit faster.

The great thing is that as a developer, you don't actually have to change that much about how you do your job, how you interact with scripts. You can just add our script as one of the first ones to load. And magically, if one of your scripts loads another script, that other script will also be monitored and we'll keep an eye on all of the things that it does. So that's the angle we've taken.

It's definitely been more painful. There's other approaches other vendors do, but they all have their own pros and cons. And so we decided that this was the angle we wanted to take. Nice.

What's an example of one of the attacks that this will catch in Squat? Well, I think in a very recent example is that polyfill. io incident that happened. So taking a step back, polyfill was a popularly used package that people implement on their website to continue to support older browsers.

So if you had a business that had to also support that very small percentage of people that still use Internet Explorer, then there was an easy hack. You just implemented polyfill. Polyfill. io was a domain name bought by another person that wasn't really a maintainer.

It was the polyfill package. And that got implemented on half a million people's websites. All the way from large brands like Diverge, Guardian, and Hulu, and you name it. Massive websites all the way to very small little e-commerce stores, WordPress sites, etc.

And it's still online for more than 400, 000 websites, which is pretty shocking. But what happened was that in February, that domain was sold to a Chinese company. Initially, they didn't do anything bad with it. But then on the 25th of June, we started noticing that a small amount of traffic got a different package where the JavaScript was calling another JavaScript behind a domain name of Google L9.

So it's not Google Analytics. The L was a Y. But as long as it looks similar to the legitimate domain, it's supposed to mask the legitimacy. Good old type of squad.

Yeah. So that was a good old type of squad of domain. And what it did, it redirected a small percentage of people that got that package of users to adult content websites and casinos. Only once.

So if you tried to go to the website again, you would not have the same thing happen, making it harder to raise the alarm bells. But the main thing that happened there was that change happened quite suddenly, only impacted people with a specific user agent. And then the change meant that a bad domain name was added to the script that was obviously typed and actually was already known to be a bad domain. That's exactly the type of attack that we go after and that we're able to spot.

Just in general, client-side security, there's a lot of things that you can do there. We're building detection capabilities for all of those. But we look at things in a historical basis. So things happen on a Monday versus on a Wednesday.

And on Wednesday, the script behaves very differently. That is something that basically makes us do some more digging. Interesting. So it almost smells like very AI-esque.

Yes. Yeah. So we have access to the full code. Most of our competitors don't really.

But yeah, we do. And of course, LLMs are pretty decent at reading JavaScript, relaying what it does. Maybe if you compare it to the previous state of it, how it is different and what it has changed and what that functionally means. So yes, we do use a bunch of AI.

And of course, I mean, this is a space that's rapidly evolving. I expect that there's going to be way more powerful things we can do over time with that. So this is like the dynamic version of client-side security. It's like you're in the browser.

You're right there where the code is running. You're right there. You have a proxy that you set up so that all the other scripts go through your proxy. So you get a little bit of static analysis there and what's happening in terms of the JavaScript.

But it seems like you're in a very powerful position to do a lot of stuff, a lot of good in terms of client-side security, where other solutions might actually fall a little bit short. If you only are analyzing like static code at build time, you would miss things like that attack that you just mentioned that hijack only a small percentage, only sometimes because it's dynamic, because that script sounds like it was changing. Only sometimes it would download the malicious version of whatever package was redirecting traffic to casinos and whatever. That's the real pain point of this dynamic style of attack.

A bad actor could easily say that 1% of users in a specific geography, a specific time of the day, gets the bad code. And the bad code could be hidden. It could be listening to user credentials, and you wouldn't even know. This type of attack that happened now with Polyfill was a very obvious one.

You know when you get redirected to an adult content site or to a casino. So we got away quite on this one, I would say. The attacker could have pulled off a way worse attack. But yeah, there's definitely a problem there.

And it's part of your supply chain, but it's part of the supply chain that people have forgotten about somehow. So we need to protect that. Dynamic languages have dynamic supply chains. Surprise, surprise.

Yeah, especially when fetched client-side. I mean, this is the part when I speak to engineers, I tend to ask them, do you actually know what's happening in the browser of your user? And the response to that is usually a little silence and then a, well, no. So that's the more we know, the better.

And the more we understand what the user is getting, the better. Yeah. Let's fast forward into the future a little bit. I'll let you decide how far into the future we want to time travel.

But when you look at success and you see success for seaside. dev, and it's just this amazing, successful, your entire vision has been realized and you're on the right path. What does that look like from your point of view? So as I mentioned, I know what I would like to do is make web security more accessible to people.

And I've been fortunate enough to have worked for, in my opinion, the most successful company in this space altogether, Cloudflare. I have insane levels of respect and love for the entire team at Cloudflare. If you have a couple of hundred dollars to spend on web security, there really isn't another good solution aside from Cloudflare. I would love to be in a position where we basically build web security to take into account more deeper client-side behaviors.

So we can protect web applications better against zero-day attacks, that we're no longer relying on threat feeds and glorified threat feeds and things like the NVD that had a massive backlog, right? And then we can actually look at how behaviors changed and the behaviors that lead to an attack and try and prevent bad things from happening. And so what success means for me there is that we make the web, like for a good chunk of websites, a lot safer. And so that you as a user do not have to worry about where am I putting my credit cards and what about my login credentials?

And we just build better web security. That's what I want to do. Based on what I hear so far, it sounds like Seaside is taking supply chain, moisture management into the real-time space, whereas existing tools, it gives you a snapshot of where your software was in the past in your development pipeline, whereas Seaside is continuously scanning your patterns in the browser. This is the actual real-life logic that is being executed, and these are the things that you should be concerned about.

And I imagine as time goes by, you'll be adding a lot more analytics on the traffic and on the patterns on third-party libraries that client is using. And you probably are getting close to the position where you can identify libraries that are loaded but are not used in general. Yes. So all of the above.

Everything you mentioned is technically capable. I mean, as I explained, the way that we work is we are ourselves a script. We have an NPM package. We can do great things with that.

And so the sky's the limit with that. I don't want to talk too much about future products yet, but Seaside stands for client-side. Attack starts from a client. Every attack involves a client.

And we want to use as much information as we can to prevent attacks from being successful using client-side Intel, in combination with whatever else we can get our hands on. I think people would be surprised to learn that large security companies tend to oversell how they use data. And then in reality, the much of good data is not actually being used to protect web apps. This is an unfortunate truth about web security.

There's a lot of data that can be used for better security that isn't actively being used. And yeah, we basically want to ace that space. And it's actually a very interesting space because once you move security, it's the edge security, right? We're talking about security on the client, which is moving further out of the infrastructure and logic that runs and executes the logic itself.

There are a lot of interesting products that I'm sure could be built on top of the technology that you guys are building right now. Correct. So it would probably be very interesting for. .

. Are you asking him for his secrets? I'm not asking secrets. No, absolutely not.

It sounds like he doesn't want to give out any of his secrets. Simon mentioned pretty clearly, and this is not the purpose of disclosing, but there are a lot of interesting developments in this space. There are a lot of legacy DLP solutions that rely on ACLs and on what your client is supposed to do, but you cannot really control the way data flows when it lands on a client in your browser. Exactly.

I mean, this is the thing. Once you get what we do, there's a lot of obvious next steps that we can take and that we will take. Yeah, I mean, it's prioritizing. And DLP of sensitive data is definitely a very important one for many people.

Lawsuits and also just the fact that compliance kicks in, right? PCI DSSV4 requires you to monitor third-party JavaScript on payment portals. That has an interesting side effect. If you have cyber insurance, most of the time your cyber insurer will ask you in a questionnaire whether you are PCI DSS compliant.

And if you say yes to that and then some incident happens and they find out you're actually not or you haven't done self-assessments, etc. , the result could be that they're not insuring you anymore, right? So these types of situations became worse and worse as they happened because now people that normally have to actually put the money down to help you, they're covering themselves. And so DLP is, I would say, the legacy problem there.

As soon as there's a data loss incident, cyber insurers will go above and beyond to try and find out, was the data lost in a way that was preventable? And if so, they probably should have done, but they didn't. And therefore, we're not going to cover you. Those kinds of scenarios are unfortunately common.

I mean, and then to come back to the infrastructure element that you mentioned, where we put our security hasn't fundamentally changed much. Back in the day, we would use to put a box in front of our infrastructure as close to the router as we could, like as close to a modem as we could, so that the point of entry would be secure, but basically be inside of the barracks at that point. We've moved on to more virtualized versions of that, living on the edge, often at the DNS level, proxying traffic. But it's still basically a box in front of the infrastructure looking at network packets.

The way I'm thinking about security going forward is we should use more data in regards to what happens before a bad request was made. And that essentially moves things further towards the client. Not necessarily happening on the client. Like, we do not rely on the client as our sole, like, base of detections, because if you put a list of bad behaviors in a browser, bad actors are going to know about it and going to try and avoid it.

But the reality is that there's some things we can do there that are more hybrids that allow us to just touch more bases. As you guys discover this anti-patterns that might be a first sign of malicious logic being executed in a browser, do you have a publicly available resource that can then provide this information across people who are interested in consuming the information that you have discovered? We currently don't do that yet. We will, in the next week, actually, this is a little teaser.

So by the time this goes live, it will likely be online. Have a website where you can type in a weird domain name and it will tell you what it does. Because a lot of these third-party scripts come from domain names that if you Google them, you can't actually find out what they are. So that's a little feature that we're doing.

We don't necessarily talk about the depth of the script. We talk about who owns the domain and what that tool is used for, etc. We do have a bunch of data that in the future we could potentially expose. The thing I would not want to do is give people a thread feed, basically.

Because thread feeds are not the way to do things. I do not like thread feeds. When polyfill. io happened, it took over 30 hours for a single thread feed to do anything with it.

Some of which, like literally name sheep, was faster to block than they were added to a thread feed. Yeah, there's already a lot of noise in the security space. And the point is not to create more noise, but rather gather additional context and do the overlay of information and then provide explicit thread that is applicable in that specific environment. Yeah.

That's what you guys are doing as well. I mean, I basically want to fight a false sense of security. If something is on my thread feed and it's bad, then it's bad. If it's not on a thread feed, some people think it's good.

That is not true. It's not because it's not on the thread feed. It's not because a thread feed says we don't know about it, that it is good. Unfortunately, that's how security has taught us to look at things.

If it's not on a thread feed, then sure, it is fine. That's not how things work. And I don't want to push that agenda because it creates a massive false sense of security. I don't feel like I want to contribute to that.

But on the other side, it is useful for us to share data as much as we can. But the sad thing is that bad actors also check thread feeds. So as soon as you put something on a public thread feed, you can count the minutes or hours before it is taken down and they've moved on to a different thing that is not on a thread feed. I don't like exposing all of the data.

I do like a good cat and mouse game. I don't have a problem with that. That's kind of something that I weirdly enjoy, a cat and mouse of security. The reality is as soon as you make it obvious that you know something, they will do everything they can to avoid being detected again.

But are you the cat or the mouse? Or it depends on the day. It depends on how you look at it. It depends on the day.

I mean, it's funny. I saw this when dealing with bot detection, right? If you build a bot detection tool and you give customers an API or a block page that they then use to make it super obvious that you've been detected, then guess what? The whole bot community is immediately on the lookout for a way to bypass your latest detection capabilities.

The best security vendors out there for bot detection, they're a little smarter. They tell people, here's an API, but don't make it obvious. Because if you make it obvious, we're just going to end up chasing the whole community of botters out there. You just don't want to deal with that.

So in my opinion, you've got to be a little stealthy about how you detected something, whether you detected it, and when you detected it in order to be successful. Because if you just put it all out there, yeah, I mean, bad actors are smart engineers. So I just really don't want to be chasing attackers. There's sometimes many hundreds of them working together on something.

We're a small seed stage company. Okay, so you're the cat. You're the cat. I would like to think so most of the time.

It sounds like, yeah, more often than not. So how big is the team? So currently, there's five of us full time and a bunch more contractors, six of those. But we're growing the team massively.

So we've got six roles open right now. Principal and senior engineers, but also business operations manager because I am a solo founder. So getting an extra person on board to help me keeping that business going is definitely going to be welcome. And even an account executive role that I'm looking to hire for starting sometime in September.

All right. Yeah. So who's your typical customer? Yeah.

It's funny because it is quite a broad spectrum. We've worked with all types of companies from consumer brands to e-commerce platforms themselves to online accountancy services to crypto exchanges. Basically, everybody has this issue. If you use third-party JavaScript, some people are more familiar with the problem than others.

Some people are more aware of the problem and really need to fix it because of their compliance requirements. But yeah, in general, when I talk to people about this, I don't want to sound cocky here, but we do tend to create a bit of an urge because we explain people the risks that they're under. They sometimes, I would say most of the time, have done some research into supply chain security. And then they're like, oopsies, there's an area of supply chain security that we haven't quite covered yet and it is a blind side.

So very broad, I would say. Do you find like that PCI DSS compliance requirement gets you a lot of traction or initial conversations or interest? It's a similar situation to GDPR, I would say. So three to six months before GDPR compliance kicked in, a small percentage of people actively cared about it and were doing what they had to do.

And then the 12 months after, there was a sudden crackdown by some company, like by some regulators around the world to go after companies that weren't compliant. And nobody wants to be the story. So at that point, a bunch more people care about it. I do not think that Seaside as a company, the success of our business is going to rely on PCI DSS.

PCI DSS is one compliance element that is pushing people into the direction of securing this. It's not going to be the only one. I expect there's going to be more of these. And just in general, I think we need to be a little self-regulating at times and understand that if we use random third-party domain names, that we should keep an eye on them.

That we can't just have them render whatever they want in a browser of a user. So PCI DSS for me is a hook to talk to people that are more like compliance checkbox driven, that look at things as, yeah, I've got 20 projects to do this year. PCI DSS is one of them. It's an easier conversation starter with them.

I tend to work most with actual engineers right now that understand the technical elements and the risks of this actual thing and don't necessarily need a compliance reason. A lot more people are a lot more aware and cautious about security in general and data privacy. Hence, companies that try to grow their user base have to consider that fact. They have to consider that our user base is now more conscious about the security aspects and security controls.

Hence, we have to provide all of the additional layers of security to make sure that we can continue building trust with our user base. So the landscape of security is definitely changing. It's no longer just the checkbox for the compliance, but rather you have to have basics covered in order to have the business in the first place. Completely agree.

The risk is that, unfortunately, people haven't, I would say, indexed this problem as one of their basics yet. But there's definitely some changes happening there. An attack like Polyfill gets this subject on people's radar. So, in a way, I think we got very lucky that attack wasn't worse or impacted people in a more stealthy way because it acted as a good wake-up call to people without people actually getting harmed.

I mean, casino website pop-up, close it and you're fine, right? Your credentials being stolen, going after all of the places where you reused your credentials, resending all of your accounts. That sounds like a bigger pain. Credit card information being stolen sounds more horrible.

I mean, imagine that attack, but like only 1% was being redirected to adult websites and then another 1% had their information secretly scraped. You don't know what you don't know. Exactly. I mean, there's been attacks in the past where IoT devices, so user agents of IoT devices were used as the qualifier for sending a bad script or not.

And so, all of a sudden, there would be a bunch of crypto mining happening on a fridge, right? Or on your Tesla browser or something like that. This is the sort of stuff we're putting up with. It's not necessarily the most harmful thing either.

Yeah, maybe your electricity bill goes up a little bit because your fridge is using more compute. I mean, the reality is you can do a lot of crazy things here. Anything a good web developer can do with a browser, a bad actor can do with a third-party script. So, the expectation from my side is that people should be more thoughtful about how they use third-party scripts.

And browsers become more capable every day. We add more features to them to do more cool things for front-end people to build cooler things. Bad actors then obviously have access to better tools as well to work with. So, yeah.

And I'm so sorry. I apologize for this. The question around the PCI DSS, it was a little bit of a litmus test almost to try to see if your go-to-market strategy was more top-down-ish or more bottom-up. And from the gist of it, it sounds like you're a little bit, you take advantage of both, but you're a little bit more engaged in the bottom-up-ish.

Yes. I mean, the bottom-up is where we get the most useful feedback from people, where I get to make our detection capabilities better, where people are very honest about this is great, this is not great. At this stage of the company, I mean, we're building Seaside to be a company that we can go and talk to anybody, right? At this stage, the most valuable people to us are getting the individual developers to talk about us, give us feedback.

And so, you mentioned you're a solo founder. That must be incredibly challenging in its own ways, I guess. You do away with a certain number of challenges, and then you get a whole other bucket of challenges as a solo founder. But what's your typical day look like?

It's funny because I've not, I mean, in the past I've had projects with other people, but I think the co-founder journey is more challenging in many ways that you cannot control. And so, I actually spoke to a very senior, amazing VC that was friends of a friend. And I asked her, I was like, hey, what should I do about this? Should I be going out of my way to find a co-founder?

Or can I just do this on my own? Like, I homeschooled myself. I've done a lot of things in my life on my own from my bedroom. And the response was, finding a co-founder that you haven't worked with before, and that might result in, like, in a founder breakup, is a worse thing than just being a solo founder.

And knowing what you can do, and then surrounding yourself with other people to help you. And then, of course, as soon as you can afford it, get somebody to help you on an operations side, which is a current stage we're in right now. My day-to-day is literally a bunch of everything. I mean, I've got to do everything from making sure that our compliance is in place, and that we are working towards getting a bunch of good customers, and keeping our engineering going, and product, and our website doesn't work in some areas.

And hiring now, all of a sudden, it's literally everything. But I'm lucky to have the team that I have, and some of them are ex-colleagues of mine. Some of them are people that I know from my broader network. I knew very well who I was hiring, and what that would give me as extra work or less work.

And so far, people have really been great. Is your brother in tech, too? My brother is not. Your brother is not in tech?

Okay. All right. So it wouldn't make any sense to invite him to work at Seasites. No, he's got an amazing job.

He works at Nike. He does a bunch of sports things in his life, and he works at a sports brand. So I would say he found the job for him. So it's perfect.

It's actually an interesting subject because in a lot of security-related discussions or engineering-related discussions, what I've noticed is often when you bring someone outside without the bubble mentality of tech and security into the discussion, can often bring up interesting points that a group as a whole has not considered in the past. Yeah, definitely. I mean, I think that's a general thing in life. If you bring people that are not necessarily as familiar with the subject as the specialists, they will ask very simple questions that we do not ask ourselves enough.

I mean, and that's the thing about, I mean, we made a very basic video to explain in what they call in Dutch, basic language, and anybody could understand what this issue is and why we're solving it. My grandparents understood it. My mom understood it. Everybody understood it.

And that's how we should be talking about complex things so that people actually are becoming more familiar with the security risks out there and know also how to put pressure on the companies that they buy things from to do the right things. The fact is that the general public knew how security works nowadays. On some areas, they would be really excited and feel very safe. But in other areas, they would feel a little scared.

I mean, explaining the thing again of thread feeds, the fact that there's literally companies out there that are spending their whole days on Twitter looking for people to complain about things to then add it to a list of naughty things that should be blocked. The fact that is still an industry and that we heavily rely on that as security companies, that's quite shocking to the general public. And I personally think we shouldn't be doing that anymore. We should be way more like on board and hands on.

The security companies plus Santa Claus at the North Pole, both with naughty lists. There you go. I mean, block lists and things like that. I just call it a naughty list.

People get what that means. I like dumbing it down and using simple language to describe like complex topics. It's more inclusive. Can speak to more folks that way.

I mean, even my baby niece gets what I do as a result. So that makes it more fun. Absolutely. And if she understands what you're up to, maybe the world can be a little bit safer in the future.

Exactly. What's the best day that you've had so far at Seaside? The best day. The absolute best.

On top of the world. Maybe you closed around. Maybe you hired someone that you just really needed and they played hard to get. It's been some incredible highs for building this company.

Actually haven't been that many very deep lows, but I'm sure at some point that will happen. And I think we'll all work together and make it a good day anyway. I mean, being able to hire the first few people that I looked up to in my career and I had as amazing colleagues. I was obviously high.

We did a nice offsite with the team a few months ago, seeing everybody come together and just, yeah. You have a remote first team. And yes, we're fully remote. I mean, there's a lot of chatter about whether that is the right thing to do or not in the entire industry.

My perspective is that if people have worked for 10 years and they had a good career so far, then likely they're going to want to move somewhere that they have space or whatever that they need. Right. If some of them get kids or some of them just want to move back to their home country and buy a nice flat, then they can. Right.

So meet people where their life makes sense for them. That's more my attitude. But a moment I was very happy was when the whole team came together. They got along very well.

There was a really great chemistry. Even though those people never saw each other before, it was like they've known each other for a long time. That was a big high for me. I remember the first engineering kickoff we had where I brought everybody into an actual Zoom call and we spoke about what we were going to work on.

Remember, that was basically the best one I've had in my whole career. And then afterwards, I realized why that was. It was because I brought my favorite people that I worked with before together and basically built that super team. And yeah, it worked out.

So those were all moments that I was very excited. I mean, more recently, we haven't announced this publicly yet, but we closed on around. Don't worry, we won't tell anyone. I won't say anything I'm not allowed to say yet.

Okay. There will be a big announcement in September. But bringing people together that I've looked up to so much in my life that have really shaped the entire industry, that have invested in people that created new categories, it's been an experience like I couldn't have imagined. I'm a 26-year-old born in Belgium.

When I looked out of my window, I saw fields with sheep and cows. The fact that a couple of years later, I'm here building this company with some of the best people in the world. It's pretty exciting. So yeah.

That's amazing. I really feel the passion and the love and the care about the people that you work with. And so that's spectacular to see and to hear, but also to feel. Thank you.

I don't know what to say. Nothing to say. Of course, the next question after the best day is what was the most challenging moment that you've had? And then how did you find the strength or navigate that complex challenging moment and come out on?

I mean, let's put things in context here. So we've had a long wait list of people that wanted to use our product. We've got enterprises that want to use our product. We've been very thoughtful about who we let on when to make sure that we don't make a major website go down.

And that if we have a bad day, that it's not the worst day. Right. So as a result, we haven't had incredibly bad days yet. I would say one of the worst days for me personally was that polyfill day, which ended up being in retrospect a rather positive day because you got people to talk about the risk.

But that was literally the one day that I was going to take off to take a break and relax. And literally Murphy's Law, something that very rarely happens just then. So that for me personally was tough. Like we haven't had major setbacks aside from that.

We will at some point. We are building a proxy service that proxies a bunch of, I would say most DOS or DDoS detection algorithms would flag us all the time because of the high level of concurrency that we got to deal with. I expect at some point there will be a really bad day. But we're doing everything we can to prevent that going to extreme lengths.

And the fact that the team has also gotten the experiences from their previous jobs to prevent that gives me some level of confidence that if we have a bad day, we'll be set up to recover from it fast. I think we've been incredibly lucky. Knock on wood, it remains that way. But we'll see.

That's great. I mean, if you want to, I guess part of your marketing strategy, if you want to get more people to talk about these bad things to happen, you could just take more days off. And then more bad things will happen. I'm very bad at taking days off.

I enjoy my work too much. But yeah, apparently if I take a day off, that's, yeah. Yeah. I mean, I think there's also something to be said about like mental health and prioritizing that and making sure that burnout is a thing that doesn't happen.

But at the same time, you balance that with, okay, you're building something. This is, you're bringing something new into the world. You want to give it the best shot that it possibly can. And you're dedicated to it.

And not only that, but now there's like when there's investors, like there's other people's money on the line. And now with employees or contractors out, also other people's livelihoods in the hook too to build a business. No pressure. The biggest moment of relief I've had was when that new round, we got to an agreement on that one.

Terms were signed. I got the right people on board that I also back channeled heavily to make sure that they would not put us all in prison for failing. Right. Because that is, I mean, it's important to know who you were working with there and how they responded to other companies that didn't quite work out.

Right. The fact that I could look at the bank account and be like, okay, we've got, here's a fun way. The people that I hired to join are going to be fine for the next few years. Right.

That is, that was a moment that I had like a massive feeling of relief. I've personally gone through burnout stages in my career. I know what it feels like. I personally found that for me, it's often not necessarily the amount of work, but the level of friction that you have to put up with in executing the tasks you got to do and the things that you care about.

To give you a simple like explanation there, it's if you're in security and you're trying to build a thing that protects people, if then the whole organization turns against it because for them it's not a priority. When your job is to prevent bad things from happening, that's incredibly exhausting on a personal level. Like you just really don't feel like your organization understands your role. You feel disappointed because you know that your job is going to be that when this inevitably bad thing happens, you're going to be the one on the call explaining to people, oops, sorry.

Yeah. And it's just those types of situations I'm very familiar with and they create like immense harm to people. So burnout, massive problem, creating a low friction environment for people to do their best work, making sure people are personally invested in what they're doing. And that people respect each other on that basis and know that everybody's there with the best possible intentions.

I think that helps a lot. But yeah, founder burnout, only a thing. Just make sure that you surround yourself by the best possible people. Get investors that understand it.

One of my investors called me when I was going through our last round and explained to him that I was tired, that it was a very intense two week period of talking to everybody from meeting to meeting. He says, don't worry about it. Everybody gets sick when they go through this. So just know that this is normal.

You're doing it right. And it worked out. And yeah, if it hadn't worked out, then this is the kind of job we're doing, right? Like we try to build something new.

Not everybody gets it. That's okay. And in the end, it makes you a better entrepreneur, better founder. It does.

Better leader. I think you hit a very important point, which is friction, always distances, actions. And it sounds the product that you guys are building is removing a lot of friction, which is present today in the client side security. Hence, Seaside is an excellent name, I have to say.

I didn't even come up with it. But yes, I was calling the company Client Side Development Inc. as a legal name. And then someone told me, hey, Simon, you should consider calling it Seaside.

I said Seaside. Yeah, like the letter C slash side. I'm like, that's actually really cool. Then there we go.

But yeah, I mean, to come back to the burnout point. I don't think necessarily this has been a cause of burnout documented anywhere yet. But the reality is that client side security is an unowned area at many companies. And usually that means it's going to come down to the front end engineer that actually put the code there, even though they weren't the one that requested it.

So the marketing team is trying out 15 different tools and they all give them to a developer over Slack, Discord or Linear or whatever. And the front end developer then implements it and, oh, one goes wrong and it becomes their problem. And that's because of the lack of governance and the lack of process and the lack of ownership of who does that. And ideally, Seaside is one of those tools that a developer just goes, I don't want to be liable for any of this stuff.

I don't want this to be my problem. I'm just going to go to my boss, swipe the credit card. It's cheap enough. And we're going to just use Seaside.

And this is a problem that is not necessarily mine anymore. There's now a tool that will deal with this problem for me. If that makes an engineer's day better, that would be a great win for me. There's another interesting technical aspect of this.

You mentioned Google Analytics and there are a lot of other tools. It just loads the script, but you don't really have the version control of that script. And each time you load a browser, you don't really know what changes have been made since the five seconds ago. And I'm sure it's an interesting problem statement in itself.

And you guys are positioning yourself to take a step of this problem. And a lot of frameworks and regulation compliances speak specifically around the dynamically loaded JavaScripts in a browser. So that in itself is an interesting friction and problem point that could be addressed with something like Seaside. If you had an abundance of time, say you were not running Seaside today.

In a fake make-believe world, what other security domain do you think is ready for innovation? I love this question because there's just so much we can talk about there. I find that my mind naturally goes to the risks of our own physical security as work-from-home employees. Because, I mean, I'm going to take another trip down memory lane.

One of my previous employers used to rent office space at WeWork and Square, etc. And they had very tight physical security guidelines. Yet I was surrounded by Hikvision cameras because of those co-working spaces using Hikvision as our camera vendor. Just a bit of a problem, right?

There's been a few companies that have done great work at revolutionizing the space. Companies like Ferkada. But I still think that it's not a problem solved and that it's not accessible enough to people. Making sure that the tools that you have in your house are listening in on you.

Making sure that where you go to work in the morning isn't being counted, monitored, etc. Making sure that those tools are not incredibly prone to attacking. And that people can't just SSH their way into the box and do bad things. That I see as an interesting problem.

So you'd be surprised how massively behind that entire industry is. Most CCTV DVR boxes you'll find anywhere in the world will run the firmware that they were once shipped with in the beginning. Some of which are just literally publicly known to be open to anybody to do bad things with. That I find an interesting space.

I'm not saying that is a high priority problem. But it's definitely something that we should be more aware of. That whatever we put in our house, in our apartments, in our buildings, in our offices. As IoT, which includes security systems, themselves can be security problems.

Other areas that I find interesting. There is this whole movement towards putting more things in clients. Making web applications accessible offline. That is in the realm of Seaside, right?

I find that a really interesting space. Because we're just storing more sensitive stuff in browsers. And basically making them like native apps that work offline. That I find a particularly interesting space as well.

Yeah, that's just honestly. Google companies that IPO 10 years ago. Look at their product. Go build a better version.

It's really not that difficult. Because at the end of the day, a lot of these security companies have lost their employees. That really push the company to innovate. And they just haven't innovated.

So you can actually just build better versions of their stuff. And build a good business around it. In other words, there's a lot to innovate on. Enough to go around for quite some time.

Okay, so Simon. If you could go back in time. Meet your younger self. Two questions for you.

Would you? And if you would. What would you tell your younger self? I homeschooled myself.

Since I was 14. Yes, you mentioned that. You homeschooled yourself. So I was actually.

I was homeschooled for a bit as well. But not by myself. It was an interesting time. Because I was going through.

I mean, the traditional public education system in Belgium. Which at a certain point didn't allow me to bring a computer to school. It was even so bad that the government defunded. Like computer infrastructure in schools altogether.

So yeah, it was quite a bad. You homeschooled yourself so you could gain access to computers. Big chunk of that, yes. Also the fact that I just really didn't find the average person my age at that point to be that particularly interesting.

And there were just really great people that I could spend more time with outside of school. I mean, I grew up in Belgium. Very random place. There wasn't really a system for that.

We figured out a hacky third door approach to do it. That's the sort of thing I did. But that put a lot of strain on me personally because I was a weird one. I was doing something that people didn't quite understand.

But I had to go back to younger Simon. I would just tell him, trust the process. Because everything I've done, the most painful jobs I've had to do, the most stressful times, including some really bad experiences at work, they all led me to become a better version of myself. When I was at Microsoft, I relocated from Belgium to Dublin, living on my own when I was 18 in a very different environment, going to the office very early in the morning, leaving very late in the evening.

It was a weird time in my life because I wasn't really enjoying that specific job I was doing at the time. But it taught me so much. So trust the process. And that's also what I try to tell people now is like 18, 19-year-olds talk to me and ask me stuff for our building on startups.

I tend to tell people if you really feel very deeply about a problem you're going after, it's probably not a bad thing to go work in that industry for two years. So you get the inside scoop of that space. So trust the process. Everything I've done in my career, in my life, has to an extent helped me with what I'm doing today.

And if I had spent two more years working somewhere and learning about more things, I probably would be an even better version of myself. There is a golden moment that you feel like you're close enough. You can go do something. I felt that way a year ago.

But yeah, I mean, trust the process. That's when you started Seasides, a year ago. It's the 2nd of January. But basically, this time last year, I started speaking to a VC or friend that knew somebody and just high-level started to network about it.

But like a year ago today, I felt, okay, Simon, you've got this experience now. You've done these things. You should now start thinking about whether you want to go work somewhere again and maybe get a more senior-level job or put this to work and start your own thing. At that time, I decided, let's go get a more senior-level job at a very early-stage startup and try and make that more successful.

And then six months later, I realized that actually, I would love to just go do something myself now. The investment space was also getting better. So investors were actually looking to invest in people again and start pre-seed funding. That wasn't quite the case, I would say, this time last year in the summer.

So yeah, it was also timing of the market, I would say. If you could speak directly to the listeners of the show, is there anything that you would ask them if there is anything that our listeners could potentially help with? This is going to sound ridiculous, but it's true. Sign up to Seaside and tell me what you think.

I would love to hear people's perspectives on how we're doing things, what could be better. Seaside isn't really open source, but I would love a culture of feedback similar to the open source community, where people can tell us Seaside would be 10x better for me if it did X, Y, or Z better, or I tried this and it didn't do what it needed to do for me because I expected it to do something else. I'm just very receptive to feedback. So the smart listeners of this podcast, their feedback would be very much appreciated.

We will put a link to the call to action in the description. So look for that in the description. We'll also put a link to your LinkedIn so that people can funnel all of the great feedback that they'll have. And really, it's not like simple onboarding.

You just have to include your JavaScript package in the page that's going to be loaded. Yeah. You're pretty much done with the integration, right? That's the high-level version.

Something like that. Exactly. I'm totally butchering it, but. .

. No, you're right. Add our thing and let the magic work. That's the idea.

Perfect. Perfect. I love the simplicity. I love the simplicity.

Thank you so much for coming on to the show. It's been an absolute pleasure to have just a super warm, open, authentic, friendly discussion. Thanks for sharing vulnerable moments with us. Would you like to leave our listeners with any words of wisdom?

Oh, firstly, thanks so much for having me again. It's been great to talk to both of you. I mean, I think a big hurdle that I had to jump basically in December last year was you can always continue to look to learn more and more. But sometimes biting the bullet on a problem you faced is worth just starting your own company around.

So my little word of wisdom to people is don't be too harsh on yourself. That's other people's jobs. And go try and build an actual company yourself. Go build a better product.

Go make a better internet. Use your skills. Go do a thing. Use your skills.

Go do a thing. That's great advice. It's great advice, actually. Don't worry about it.

Don't take things too seriously. Use your skills. Go do a thing. Simon, thank you so much for your time, for your insights, and for sharing with us your journey.

We are super excited for the future for you and for the company. Thank you very much for having me. It's been an absolute pleasure. And thank you to all of our listeners for tuning in to another episode of the Security Podcast in Silicon Valley.

I'm one of your hosts, John McLaughlin, and I was joined today with the other hosts, Sasha Sinkovich, Simon Wickmans, the founder and CEO of Seaside. This is a wide security production, and stay tuned for another episode. Thank you, everyone. Thank you.

Thank you. Thank you. Thank you. Thank you.

Thank you. Thank you. Thank you. Thank you.

Thank you. Thank you. Thank you. Thank you.

Thank you.