Last week, someone outside our team integrated Vatly for the first time.
Robin Dirksen, a developer I know well, was participating in the Mollie x Lovable hackathon. Robin has been an enthusiast since day one, helping me test-drive Cashier for Mollie years ago. He asked me if he could use Vatly during the hackathon. He felt it was a perfect fit for what he was building, and I suspect he was super curious to try it.
This was a significant moment for me. You build something for years, iterate endlessly, and then you hand it to a real developer and watch them use it.
Scary. Even when it's someone you know.
The setup
I duplicated our staging environment with a dedicated domain just for Robin. Gave him a 10-minute walkthrough the day before. Pointed him to our documentation website, which we'd recently optimized for AI consumption.
Then I went on standby. Any issue that arose, I'd be there to help. I was in Tilburg while the hackathon was happening in Amsterdam, a two-hour drive away. I wasn't able to travel that day, so I was glued to my screen instead. Dennis and Zander, our infrastructure partners at Ploi.Cloud, were on standby as well for any infrastructure-related issues. I didn't need to call them in, but it was great comfort knowing they were there.
The feeling? Excited and scared shitless.
Excited because you're stepping into uncharted territory. You know you're making progress. On the other hand: what if Vatly doesn't hold up? What if there's a critical bug? What if the whole thing falls apart?
Three bugs, zero in payment logic
Bugs happened. Three of them throughout the day.
Here's what was interesting: all three were in features I'd shipped very recently. The onboarding wizard, which I'd pushed a bit more aggressively because I deemed it non-critical. Robin signed in and immediately hit a status 500. That's what happens when you ship instead of watch your CI setup in isolation.
Yet, I will always have mixed feelings about bugs in moments like these. On one hand, this is exactly why I jumped at the chance for Vatly to be tested thoroughly during the hackathon. You can't rule out every bug with automated testing, which we also do rigorously. Some things you need to see in the real world.
On the other hand, you want it to just work.
When you've been doing software development for a long time, distress is only a small part of your reaction. You immediately kick into action. Our application performance monitoring flagged the issue and showed exactly where it was. With the help of AI, we were able to pinpoint the cause, prepare a patch, review it manually, run our integration tests, and ship it. All under 10 minutes.
The important thing: none of these bugs touched the core payment logic, and the event-sourced architecture stood its ground. It actually helped us investigate issues and bottlenecks moving forward. We have data now. It's very good to see these efforts starting to pay off.
The moment it clicked
Robin built a proof of concept for a virtual sign language SaaS. Think: a solution for places where you need a sign language interpreter to communicate with someone who is deaf. He built it in Laravel with a Vue frontend, in one day, fully vibe-coded as was the hackathon's premise.
At the end of the day, he sent me a video demo. Vatly, integrated with another product, making it commercially viable.
That's the thing about a merchant of record like Vatly: in one connection, both solutions become commercially available. For Vatly, this was the first case of someone making it commercially viable without my direct interference. For Robin, his SaaS immediately becomes available to a worldwide audience.
That's what you see clicking. That's the whole point.
Robin came in second at the hackathon awards. Not bad for a day's work.
Total guidance I had to give Robin: maybe 20-30 minutes throughout the entire day. And honestly, he probably didn't need it. It was more my own eagerness to be involved.
The AI documentation revelation
Here's something I didn't expect.
I told Robin: "We have a PHP client ready for you. I also have a Laravel client that's not entirely done yet, so I'd suggest the PHP SDK for now."
What he did instead: pointed his AI at our documentation and let it figure out what to use.
From what I gathered, he didn't even check his codebase to see what the AI had done. It just worked. Probably direct HTTP calls from his Laravel backend, which is fine.
The whole developer experience is shifting. As a developer myself, I'd prefer to see an official Vatly SDK getting used. But apparently it's not a necessity anymore when AI can read your docs and make the right calls.
This changes how I think about prioritizing SDK development. Documentation might matter more than SDKs now.
What changed
After this hackathon, my focus has aggressively shifted to shipping.
I had a PR for dunning (the retry logic for failed subscription payments) sitting for a month. Not because it wasn't ready. Because it wasn't the highest priority to review. After the hackathon, I went over it one more time and merged it.
New rule: every PR either moves forward or gets killed. No more sitting. No more "we'll get to it."
You can't catch everything with code reviews and automated testing. Some things need to ship to learn. The hackathon proved that bugs surface fast in the real world, and when your architecture is solid, they get fixed fast too.
Velocity over perfection.
The reaction that matters
During the presentations, Robin told me the first reaction from the audience was: "What's Vatly? Why are you integrating with a competitor during a Mollie hackathon?!"
When he explained that Vatly was actually the missing layer for SaaS sitting on top of Mollie, both the jury and the public became more interested.
The reaction wasn't hype. It was a calm, rational recognition: "Of course this is coming."
I'll take that over hype any day.
PS: Robin is now validating his sign language SaaS. It's more promising than the niche might suggest. Making services accessible to everyone shouldn't be optional, and Robin's making it easy. If you're interested, reach out to Robin.