The story
How I ended up building it
A technical engineer in Cape Town, a BSc that isn't finished yet, and a problem nobody wanted to do by hand.
The problem
Security has a paperwork problem.
Every week the world publishes hundreds of new vulnerabilities. A handful of them are actually being exploited right now, out there, today. Fewer still are on software your client is actually running — at the exact version that's actually vulnerable.
Finding that overlap is the job. All of it. And doing it by hand, across every machine in every business you look after, every single day, is not hard — it's impossible.
So mostly, people don't. They patch what they remember. They tell the client they're covered. And then they hope.
The obvious move is to buy a tool. That's where I got stuck.
The vulnerability-management platforms on the market were expensive — priced for enterprises with a full security team to run them, not for the kind of business I actually look after. And for all that money, they weren't reliable. They'd flag a machine that had been patched a week ago. They'd report at company level when the only question that matters is which machine. You'd end up doing the verification by hand anyway — on top of the licence fee.
You can't hand a client a report you don't believe. And you can't ask them to pay for a tool that guesses.
It cost a fortune and it still couldn't tell me the truth. So I built one that could.
The build
So I built the thing that does it.
It started as Vuln-Watch. Pull the feeds. Match the versions. Flag what's real. A narrow idea, built to kill one specific kind of guessing.
It grew into Vikelus — the platform F1 IT Solutions now runs across its client base. On one side: CISA's catalogue of vulnerabilities attackers are actively exploiting, new critical CVEs, and the exploit-probability scores that separate the genuinely dangerous from the merely scary. On the other: the live software inventory of every machine we manage. In between: the match, the ranking, and a staged patch workflow that ends in a report you can hand to an insurer.
The idea was mine and so was the build. I designed the architecture, wrote the version-matching engine, the proof pipeline and the reporting, and I run it in production. Every decision in it is one I have to live with at 2am, which turns out to be an excellent way to make decisions.
It's now its own thing. I co-founded Vikelus with Reza Marvasti, who runs the growth and partner side while I keep building the platform.
A dashboard that says “protected” and can't show you why is just a nicer way of hoping.
That sentence is the whole product. Anyone can render a green tick. The green tick is worthless unless something underneath it can be checked, argued with, and proven — which is why Vikelus verifies the installed version, on that specific machine, and not a vendor's word for it.
The rule
Never fake a finding.
It's written into the project's house rules, and it's the one I'd defend hardest.
The scores Vikelus produces go onto reports that business owners hand to their cyber insurer at renewal. There is a permanent, quiet temptation in this industry to close a finding because it's noisy, or old, or inconvenient — to make the number look better than the reality.
We don't. A finding closes when the machine is actually fixed and the installed version proves it. Not before. If that makes a score look worse this month, the score was always worse — you just hadn't been told.
The same instinct shows up in the patch workflow: nothing significant touches a server on one person's say-so. Two engineers approve it. It is slower, and it is the reason nothing has gone sideways.
The grind
Studying while building.
I'm still finishing my BSc in Cybersecurity and Networking at Eduvos. I'm doing it while working full-time as an engineer at F1 — and while running a platform that other people's businesses depend on being right.
I mention it not because it's impressive, but because it's the honest shape of the thing. Vikelus wasn't built by a team, on a roadmap, with a budget. It was built in the hours around a job and a degree, because the problem wouldn't leave me alone.
The upside of learning the theory and shipping the practice at the same time is that neither one gets to stay comfortable. The textbook has to survive contact with a real client's real fleet on a Tuesday. Usually it does. Sometimes it very much does not.
The stage
The hard part isn't the exploit. It's the explaining.
Most security advice is written to sound impressive to other security people. Which is fine, except that the person who actually has to decide whether to spend the money is almost never a security person.
So when I talk — to a client, to a room — I do the opposite. No jargon. No scare tactics. No acronym soup. Just what's actually at risk, what it would genuinely cost you, and what to do about it on Monday morning.
If a business owner can't repeat back what's at risk and what you're doing about it, you haven't explained anything. You've just performed.
What's next
Still building.
If you want a second opinion on your security, a look at Vikelus, or just to argue with something I've said here — I'm easy to reach.