I’m not a full-time developer—to be honest, I never have been. I’ve been working as a technical product owner for years and have a decent understanding of our setups, but programming is definitely not my day-to-day job. That’s exactly why I wanted to find out how far you can go with a tool like Cursor when you simply build a small internal tool yourself—without claiming to be a “real” developer.
1) Choosing a Stack: Between Aspiration and Reality
My first instinct: “If I’m going to do this, I might as well go all out.” Back in the day (around 2010), I used to work locally with MAMP; today I know: we run Docker/Podman, with services neatly separated, everything in containers. So I took our projects as a guide and suggested a “grown-up” stack to Cursor: Postgres as the DB, Next.js for the API/Backend layer, and React for the frontend.
Cursor promptly put this into action—but unfortunately, the system kept crashing. Sometimes a container wouldn’t start, sometimes the routing was messed up, and sometimes some random secondary container would block the rest. And while our dev machines with 64 GB of RAM just smiled wearily at all this, my poor little management server was overheating: five parallel containers just to… render a homepage. Seriously?
Why It's Worth It for a CEO to Try Their Hand at (Vibe) Coding
A completely new way for non-developers to understand the challenges.
Why I'm even trying this
First lesson: “Streamlining architecture” via a prompt sounds good, but it rarely works. Cursor claims it can do it; but once a project has gone off in the wrong direction, scrapping it and starting over is almost always faster and cleaner. I completely rebuilt my budget app from scratch five times. The knowledge stays in my head—the code can go. The idea was to develop an app that automatically provides an overview of all budgets in the company by using data from our time tracking system and the various proposals. That way, I can access all relevant information without having to manually search through individual projects.
2) Prompting Aha Moment: Sometimes Less Is More
After the Big Bang failure came the next (wrong) idea: “It’s AI, after all—if I give it even more context, it’ll choose a smart architecture on its own.” And it did. Formally correct. Practically useless. Cursor eagerly got to work, adding layer upon layer, and after two hours, undoing it was more time-consuming than starting over.
So I changed course: step by step instead of a master plan. My first Cursor app that actually worked wasn’t the budget app, but a small monitoring dashboard for the team.
Sure, our teams don’t really need a monitor like that. We switched to sensible alerting strategies years ago—especially when working remotely, a screen in the office that flashes red isn’t the most practical solution. But to get started with Cursor prompting, you need a use case that’s manageable yet still delivers value. And honestly: there’s something reassuring about walking through the team room and seeing green status indicators—even though I know that everyone gets notified differently in case of errors anyway.
The prompt was radically simple: “Use this API and show me the result on a dashboard.” No architectural essay, no database discussion. And suddenly it was working: Node.js on the back Backend, React on the frontend, data storage kept very pragmatic in JSON for now, because I didn’t need persistent storage yet. Not pretty, not final—but that first real sense of accomplishment.
3) When Things Get Serious: API Keys and Working with Real Data
Once the dashboard was up and running and the first green indicators appeared, the question naturally arose: “Okay, what do I do with this now?” The next step was accessing real systems—in my case, GitLab and Uptime Kuma —so I needed API keys.
And that’s where things suddenly get exciting for someone like me, who isn’t an experienced developer: access and permissions aren’t just a side issue. Sure, as the CEO, I have relatively comprehensive account access, but I’m not experienced in handling sensitive data via APIs or databases. This is exactly where exchanging ideas with experienced developers helps immensely—so you don’t accidentally grant overly generous access or build something you’ll later regret.
My personal guardrail: read-only interfaces. I’ve explicitly told Cursor time and again not to generate any write endpoints. Even better: API keys that have read-only access on the server side. That way, I can’t accidentally modify live data in the first place.
4) Deployment: When it’s time to share with the team—and the AI gets a little spooky
The app was running locally, and yes, I was proud as punch. But obviously: It’s no use to anyone if it’s just on my computer. So the thing had to go “into the team room”—in other words, onto a server.
This is where the AI really messed up. I tried to deploy the project directly to one of our proServers using Cursor. What happened next was, to put it mildly, spooky: Cursor help itself to my SSH keys without really asking, looked up the server documentation, and even seemed to recognize which proServer had sudo access and which users were just regular users—and then started tinkering around on the server using the “right” users. Luckily, it was an empty server that I’d set up just for this purpose.
The result? Somehow the app was there, and somehow something was running—but nothing useful showed up in the browser. It never became truly stable.
In the end, I went to our DevOps colleagues. They set it up properly behind a reverse proxy, made sure it was secure, and generally took a look at what the app was actually doing. Conclusion: A production deployment using only Cursor was a total flop—I won’t do that again. Especially when rolling out new features, security > speed.
That’s exactly when it dawned on us: When people who don’t develop software on a daily basis work with tools like these, we need clear, management-friendly guidelines in addition to our existing engineering standards. So my fellow executive—who’s actually a very good developer —and I sat down and had an in-depth discussion about what’s required, what’s optional, and how we’ll handle it. That’s material for a separate blog post.
👉 If you’d like to find out how to create space for such experiments in your company—with clear services in the background and reliable guidelines—feel free to reach out to us.
👉 And if you’d like to chat with me directly about Cursor, AI coding, and the practical benefits for project managers, feel free to reach out—I’d love to share my experiences and look forward to the conversation.
