Salesforce at the club – Episode 3

Vibecoding: From “this is annoying every night” to a working SumUp integration

“Vibecoding” is one of those words that seems to be everywhere right now. And as with many new buzzwords, it is fair to ask: is this really something new, or just a fancy term for AI writing code?

I think the best way to understand the concept is through a real example.

Mine did not begin with an idea for some fancy app. It started with a rather ordinary question from everyday life at the club: why is it so awkward to find out how much money has gone through our SumUp terminals?

The problem: settling up after an event

At NY.Club, we use SumUp devices among other options for card payments. At the end of an event, the individual areas gradually come in to settle up: the bar, cloakroom, admission desk and so on.

Of course, I want to know not only how much revenue our internal accounts show, but also how much actually went through the card terminals.

Until now, that meant a lot of manual work. For each terminal or area, someone had to find the relevant revenue figures and make sure they had selected the right time period.

Because, as we all know, a club night has only a passing respect for calendar dates.

An event might start on Saturday evening and finish on Sunday morning. For our settlement, the relevant period is therefore not “Saturday”, but, for example, 10 pm to 8 am the following morning. A perfect candidate for automation, really.

Doesn’t SumUp have an API?

So I took a look at the SumUp API. And sure enough, there is quite a lot you can do. Transactions can be retrieved automatically and, in principle, integrated directly into our existing Salesforce application, which already handles much of our event settlement. I had already built a few small components with Claude Code, but a real-time third-party integration is a little more complex. So I let the AI have a go.

Round 1: Just describe what I want

My first prompt was surprisingly unspectacular:

i need a new component that connects to sumup and displays the transactions + amount each terminal and for all terminals based on the event date of the event record, starting from 10pm until the following day 8am.

That was essentially the complete product description. I wanted a new Lightning Web Component in Salesforce that would connect to SumUp, automatically calculate the right time period from the event record’s date, and then display the transactions and revenue. From 10 pm to 8 am the following morning. Exactly how we work in real life.

I had also already been through several rounds with Claude Code and described quite clearly in skills what we do in Salesforce. And sure enough, the first version worked. Not perfectly. But it worked.

Round 2: Turning code into a product

And this is where it gets interesting for me. I did not sit down afterwards and start rewriting the generated code line by line. Instead, I looked at the result and described what was still wrong or not good enough.

lwc works and shows a result but i think there are some missing pieces: 1. the date/timestamp is in timezone +-0. the request should respect the local timezone and adjust it to local 22pm - 8am. 2. Terminal Information seems to be empty. Check the SumUp developer documentation if you can find more information how to get this. 3. i love the full sum on top. its great. but can you please add a sum each hour. maybe as sticky header. and the list inside a scrollable container with a fixed height. 4. as well it would be nice to see the payment method as information

For me, that is pretty much the point where “AI generates code” becomes vibecoding. I was not discussing individual methods, JavaScript functions or CSS classes.

I described how the application should behave. The AI handled the technical implementation.

Round 3: Fine-tuning

The next version was already quite usable. But of course, as soon as you start using something, you notice more things.

check the deductions component how the scroll container is created there as inspiration... make the sums each hour sticky. currently the timerange from 22 until midnight is at the very end of the list. shouldn't it be at the beginning? can you add the sumup user that has been used for the transaction? add charts with the sum each user like you did for the transaction type

What made this interesting was that the new component was not being built in isolation from the rest of the application. I could point to an existing Salesforce component and say: look at how we solved it there and use that as a guide.

That is a huge difference from traditional code generators. Increasingly, it is about more than producing code. The system can understand existing code, recognise patterns and integrate new functionality into an existing application.

And the result?

I ended up with a Salesforce component that shows, for the relevant event period, the number of transactions found, total revenue, revenue by SumUp user, the card types or payment types used, individual transactions and the revenue trend within the relevant time window. Of course, the configuration needed for secure access to the SumUp API also had to be set up.

The result now looks more like a small finished product than a coding experiment.

All transactions and revenue, directly on the event in Salesforce. No switching to another backend. No manually piecing together revenue figures. Above all, the component automatically knows which time window belongs to the club night and which bar or position the revenue can be assigned to. It saves us time every night and helps prevent settlement errors. We can also see in real time how revenue is changing and when it makes sense to close a bar.

Is this really “vibecoding”?

For me, yes. Because I mainly did four things during this development:

I described the problem. I looked at the result. I explained what was still wrong. And I described how I would like it to work instead. Of course, software development does not disappear as a result. You still need to understand what the application does. API access must be configured properly. Credentials need to be stored securely. Time zones turn out to be more complicated than expected. Data models, permissions and error cases still exist.

But the level at which I interact with the system is shifting. Instead of implementing every technical detail myself, I can focus much more on the real question: what should the product be able to do?

The real leverage: vibecoding on a platform

What excites me about vibecoding is not the idea that anyone can suddenly build any software in five minutes. That would be too simplistic. What I find much more interesting is how dramatically the distance between an idea and a working prototype is shrinking.

Small internal tools, in particular, used to be typical candidates for: “That would be useful, but it isn’t worth the development effort.” That calculation is changing.

And this is where the underlying platform becomes crucial for me. Vibecoding on Salesforce means you are not starting from scratch. The data model, users and permissions, existing processes, APIs, automations and all the business logic are already part of an established platform. This allows the AI to focus much more on the actual solution, rather than first having to build the technical foundations.

That is where I see a powerful advantage: new functionality can be created directly where data, processes and users already come together. An idea becomes a prototype faster and, in the best case, a feature that can actually be integrated into day-to-day operations.

And perhaps that is the more interesting perspective on vibecoding: AI brings speed. A strong platform makes sure something useful comes out of it.