A few weeks ago, I built myself a little app. Not because I want to take over our developers’ jobs or suddenly get back into the day-to-day work of coding. But out of curiosity—and for a very practical reason. Until now, our budgets had been managed in an old internal system that was becoming increasingly inflexible. Changes were difficult to implement, the system was cumbersome to use, and in the end, it was clear: we needed something new. So I asked myself: How far could I get on my own today if I worked with modern tools like Cursor, which use AI to help me with programming?
The result was a budget overview app that has turned out to be surprisingly useful for me. But even more exciting were the experiences along the way. I’ve never been a developer myself, but I worked with various programming languages in school and during my training, and I’ve brought technical expertise to the table as a product owner for many years. I’ve only ever been able to program in a very rudimentary way—and that’s exactly why it was exciting to get my hands dirty again after so long and see how the possibilities have changed.
As soon as you start translating a problem into code—even with just a little code of your own—you stumble upon all the questions that developers usually ask. Suddenly, there are these little edge cases that you hadn’t even considered before. Suddenly you realize that a term like “used” isn’t at all unambiguous—does that mean ordered, billed, or already paid? And suddenly it becomes clear that a seemingly simple decision actually entails half a dozen dependencies.
This renewed shift in perspective left a lasting impression on me. Over the past few days, I’ve come to better understand why developers sometimes insist so strongly on precise definitions, and why a small change is often not so small after all. It’s a bit like switching to the other side of the desk: You feel the friction, the attention to detail, the weighing of options—and as a result, you gain a much clearer view of what happens in everyday life.
Of course, Cursor was a huge help. In fact, I didn’t write a single line of code myself for this project; instead, I “discussed” everything exclusively with Cursor. The editor took my descriptions in natural language, made suggestions, generated code, and adapted it. That’s how the app came together step by step—without me having to type a single thing myself. It was exciting because it allowed me to focus much more on the logic and the requirements, rather than on syntax or the details of the programming language.
Limits of DIY Solutions
However, there are also limits to “tinkering,” for example, in the area of authentication. It was clear to us from the start that we would use the internal Keycloak service. There are no experiments, no shortcuts, and no makeshift solutions there. Authentication is a core system that must be stable, secure, and auditable. For me, this was a valuable contrast: on the one hand, the playful, rapid approach of low-code methods; on the other, the need for clear, robust services. For me, the opportunity lies precisely in this balance: Companies can create a stable foundation—identity, logging, data platforms—and allow a flexible layer of experimentation on top of it.
And this, to me, is a crucial point: For such experiments to even take place, there needs to be a conscious effort to enable them within the company itself. Giving employees the opportunity to try things out within clear boundaries opens up a vast space for creativity and learning. When the underlying architecture is stable and the playing field is clearly defined, ideas suddenly emerge that would never have been seen in traditional project settings. We support companies precisely in this: building this stable foundation in a way that provides security—while simultaneously leaving room to dare to try something new.
Specialist: Keycloak
Our specialists will guide you through your Keycloak project from start to finish and support you with their many years of experience and expertise. Even after successful implementation, our specialists will remain available to assist you with ongoing operations, customizations, further development, and training. Our specialists offer you:Consulting & DesignMigration & IntegrationCustomizationOperationFurther DevelopmentWorkshops & Training (Remote or On-site)
More About Authentication
What remains after this experiment? Above all, a new understanding of roles and processes. I can formulate requirements more precisely because I’ve experienced firsthand where the pitfalls lie. I’ve seen how prototypes make discussions more concrete and help avoid misunderstandings. And I’ve learned just how much respect the actual craft deserves: clean code, well-thought-out architecture, and patient attention to detail.
Small apps like these can be useful in a wide variety of areas. They help improve your own workflows, simplify analyses, or optimize business processes on a small scale. But as with any software, the real work only begins once it’s deployed: How often does the app need security updates? What happens to user feedback? Who steps in if the app suddenly stops working? An app that’s up and running on the server is far from truly “production-ready.” That’s why we’ve established internal guidelines for this as well—and as always, the rule is: You build it, you run it. But that also means these little helpers can disappear just as quickly as they were created. And that’s perfectly fine—as long as they provide real added value in the meantime.
But there are risks, too. Managers who build things themselves run the risk of getting bogged down. It’s easy to think an app is “almost done” just because the interface looks nice—and overlook the fact that entire layers are still missing underneath. Without clear guidelines, shadow IT can also quickly emerge—and no one wants to maintain that. And last but not least, it’s important to keep roles clearly defined: A CEO remains a CEO, even if he writes a few lines of code now and then.
Conclusion
Still, for me, the experiment was worth it. It changed my conversations with the team, sharpened my perspective on architecture, and showed me how important it is to create space for experimentation without jeopardizing the foundation. I’m not suddenly going back to being a developer—but I’ve gained something that makes my job as a CEO better.
And perhaps that’s the most important insight of all: It’s not about being able to do everything yourself. It’s about understanding what happens when others do it—and creating the right structures so that your own team can also experiment, learn, and grow.
