Here’s the full story, in his own words:

When we ask SwissHacks participants what they’re hoping to get out of the weekend, the answers tend to be practical – a good project, useful feedback, connections, maybe a prize. Glody came in wanting to find out what he was actually capable of building.

He’s a student, working through his studies in Switzerland after years of consulting work at BNP Paribas and Capgemini. He’d built things before, but always inside someone else’s process.

His team won the Raiffeisen Challenge with Raivisor, an AI assistant for wealth managers. The project has since evolved into Kielis, a startup he’s actively developing today. We sat down with Glody to understand what the weekend actually looked like from the inside, and what he’d tell this year’s applicants.

Background

Consulting at BNP Paribas & Capgemini, then moved to Switzerland to study

SwissHacks 2025

Won the Raiffeisen Challenge with Raivisor — built from scratch on Saturday night

Post-hackathon

Team dispersed. Glody kept building alone, rebuilt the team with banking experience

Today

Kielis — an AI-native platform for independent wealth managers, in active development

What were you hoping to get out of SwissHacks?

Honestly, I wasn’t sure. I’d spent a while working as a consultant — technically solid work, but always a step removed from real users or real impact. Moving to Switzerland to study felt like a reset, and SwissHacks felt like a good test: could I actually build something meaningful when the conditions were right?

The problem we chose to work on came from a simple observation. Wealth managers and financial advisors are spending a disproportionate amount of their time on compliance paperwork and administrative work — time they could be spending with clients. We thought AI could help with that. That became Raivisor.

“SwissHacks didn’t just give us a trophy. It gave us the conviction to keep going.”

We won the Raiffeisen Challenge. But more than the result, we’d found a problem worth taking seriously. That feeling is what turned a 48-hour project into something I’m still working on today — now called Kielis, with a proper team and real customers in the pipeline. And alongside that, I’m building KitandaSmart in Angola, helping local businesses get online. Two different contexts, same basic drive: build things that actually work for the people using them.

What happened after the hackathon ended?

The team went their separate ways — which is just the reality of these events. Everyone has their own commitments. I was the only one who stayed with the idea.

For a while I was building mostly alone, as the sole developer, while looking for collaborators with actual banking industry experience. That kind of experience matters when you’re building something practitioners need to trust. Eventually I found the right people, and the product started to take a more serious shape.

“You stop optimizing for the judges and start optimizing for users. That’s a completely different problem.”

Raivisor grew into Kielis — covering KYC automation, compliance workflows, meeting intelligence, and portfolio analytics. We’ve started customer discovery with Swiss External Asset Managers and are working toward our first paying clients.

The gap between a hackathon win and a functioning startup is larger than it looks from the stage. SwissHacks gave me the starting point. Everything after was figuring out how to stay with it.

Did the experience change how you think about building?

It did. Before the hackathon, I had a quiet doubt about whether I could actually see something like this through — not just the coding part, but all of it. The team dynamics, the pitch, the pressure.

Building Raivisor in 48 hours answered that question, at least partially. It showed me I was further along than I thought.

“A rough demo that gets real feedback is worth more than a perfect product nobody has seen.”

The bigger shift was understanding what actually matters when you’re building a startup. It’s not about having the perfect idea upfront — it’s about staying with the idea when things don’t go as planned. Partners hesitate, users respond differently than you expected, the product needs to change. You learn to iterate rather than give up.

There’s also a personal dimension I didn’t fully anticipate. Being a student from Angola, building a fintech product in Switzerland — it feels like it carries a bit more weight than just my own project. That shapes how I approach every decision.

Walk us through the actual weekend. What really happened?

Friday went well. We had a working prototype by the end of the day and were proud of it. Then on Saturday morning, a Raiffeisen representative gave us blunt feedback: what we had was too generic. Anyone could build it. Not differentiated enough.

That was hard to hear. The energy dropped quickly. The team got quiet. We had limited time left and no clear direction forward.

Most of my teammates wanted to keep improving what we already had. So we made a different call: They would keep working on the existing version while I started something entirely new from scratch.

What I built was a real-time AI assistant for client meetings — it transcribes live conversations, runs multiple AI agents in parallel, flags compliance risks, and captures notes, all while the meeting is still happening. Within a few hours, results were appearing on screen. My teammates came over, saw it working, and joined in. The dynamic shifted completely.

It wasn’t clean. The backend struggled with concurrent requests, and we had to improvise load balancing under time pressure. But by the end, it was working — and it was something genuinely different from what we’d had in the morning.

What I remember most isn’t winning. It’s the moment during the final presentation when the judges leaned forward — not out of politeness, but because they actually cared about the problem we were describing. That’s a different kind of validation.

What would you tell someone applying to SwissHacks this June?

A few things I wish I’d known going in:

01

Sort out your team’s expectations before you write any code. Make sure you’re aligned on why you’re there. Someone needs to be willing to make decisions when the group gets stuck — not to dominate, but to keep things moving.

02

Use AI tools seriously. We couldn’t have built Raivisor in 48 hours without them. Speed matters more than almost anything else in a hackathon context. Don’t treat AI as a shortcut — treat it as part of the team.

03

Start thinking about your pitch as soon as you’ve settled on your idea. One person should own the narrative from the beginning. A strong demo with a weak story still loses.

04

Talk to the judges before the evaluation. Ask what they care about, what problems they see in the space. You’ll often learn something that changes how you frame your solution — or makes you more confident in what you already have.

05

If you build something that feels real — keep going after the weekend. Raivisor became Kielis. That only happened because we didn’t treat the win as the ending.