Vibe coding: can you build the system yourselves now?

Vibe coding: can you build the system yourselves now?

It's become a real conversation in a way it wasn't two years ago: "can we just build this ourselves?" With AI tools like Claude, Cursor, or Replit, someone with no programming background can now describe what they want and have a working website or a simple booking form up and running in an afternoon. This is often called "vibe coding" — you describe the feeling of what you want, the AI writes the code, and you adjust along the way by asking for changes in plain language, not by writing code yourself.

This isn't hype without substance. It actually works, and it works surprisingly well for certain things. The question we're getting more often now, which we want to answer honestly, is: does this mean a conference hotel or event venue can build their own PMS or event system themselves, and drop the vendor entirely?

Short answer: for some things, yes, absolutely, and you should. For the system that handles guest data, payments, and operations, the answer is almost always no — and the reason has little to do with whether the code is good enough on day one.

Where vibe coding is genuinely great

Let's be clear about this, because it's easy to be either entirely dismissive or entirely uncritical, and neither is honest. Vibe coding is a real, useful tool for a specific category of tasks:

Internal tools without sensitive data — a simple overview of who's on holiday when, a calculator for catering quantities based on guest counts, a dashboard showing today's arrivals pulled from a spreadsheet. One-off needs — something you need this month for a specific event, that doesn't need to live on afterward. Prototypes — to test an idea quickly before possibly asking a vendor to build something proper. Automating an annoying manual task — for example, a small script that pulls numbers from one system and enters them into another, without touching guest data directly.

The common thread here is that the consequence of something going wrong is small and local. If the calculator miscalculates one day, you notice quickly and fix it yourself. No guest is harmed, no personal data leaks, and no payment gets charged incorrectly.

Where it becomes something else entirely: guest data, payments, and operations

A PMS or event system isn't in this category, and it's worth being entirely concrete about why, rather than just saying "it's more complicated" and leaving it at that.

Security isn't something you bolt on at the end. A system handling guest names, contact information, payment references, and possibly health information in a comment field needs to think through access control, encryption, and logging from the very first line of code — not as something added once there's "time for it." An AI tool that generates code quickly usually generates the code that's quickest to write, not automatically the one that's most secure. There's no built-in guarantee that a vibe-coded system is actually protected against the most common attack patterns, unless someone who genuinely understands security goes through it line by line.

Regulations don't disappear because you built it yourselves. Norwegian VAT handling on a day package, EHF invoicing for public-sector customers, GDPR requirements for how guest data is stored and deleted — all of this applies regardless of who wrote the code. The difference is that an established vendor has solved this once and maintains it continuously for all their customers at the same time. Build it yourselves, and you also have to keep it updated yourselves, every single time the regulations change.

Maintenance isn't something that ends once the system "is done." This is probably the single most important point, and the one most often forgotten in the enthusiasm of building something fast. Building a working version is the easy part — maybe 20 percent of the real workload over time. The remaining 80 percent is what happens afterward: libraries and dependencies that need updating when security holes are discovered in them, integrations that stop working when an external service changes its own API without warning, backups that need to be tested regularly — not just taken — and someone who's actually available when something stops working on a Friday at four.

Who owns the problem the day the person who built it leaves, or gets busy with something else? This is perhaps the most underrated risk of all. A vibe-coded system usually has one person who understands how it all fits together — often the one who built it, frequently without formal documentation beyond whatever the AI tool generated along the way. The day that person leaves, goes on sick leave, or simply ends up with other priorities, you're left with a system nobody else really understands, and no vendor to call.

A simple thought experiment that reveals where the line actually sits

Ask yourselves: if this system was down for six hours on a Saturday with full occupancy and a wedding in the function rooms, what would it cost you — in money, in reputation, in lost guest trust? And: if a guest's payment information or health data leaked from this system, who would you call, and who would actually be held accountable?

If the answer to the first question is "not much," and the answer to the second is "not relevant, it doesn't touch that kind of data," you're probably in the safe zone for vibe coding. If the answer is "that would be catastrophic" or "we honestly don't know," that's a clear signal this belongs with a vendor carrying real accountability — a contract, an SLA, someone who can actually be held responsible, not just an AI chat that helped you out one afternoon.

It isn't either-or

The sensible approach probably isn't choosing between "build everything yourselves" and "buy everything from a vendor." Use vibe coding freely for the internal, low-risk tools where it genuinely gives you something fast and cheap that no vendor would have built for you anyway. Keep an established vendor with real accountability for whatever touches guest data, payments, and the operation of the business itself. And be honest with yourselves about which category a given need actually falls into before you start building — not after it's already living in production and has become harder to say no to.

It's become a real conversation in a way it wasn't two years ago: "can we just build this ourselves?" With AI tools like Claude, Cursor, or Replit, someone with no programming background can now describe what they want and have a working website or a simple booking form up and running in an afternoon. This is often called "vibe coding" — you describe the feeling of what you want, the AI writes the code, and you adjust along the way by asking for changes in plain language, not by writing code yourself.

This isn't hype without substance. It actually works, and it works surprisingly well for certain things. The question we're getting more often now, which we want to answer honestly, is: does this mean a conference hotel or event venue can build their own PMS or event system themselves, and drop the vendor entirely?

Short answer: for some things, yes, absolutely, and you should. For the system that handles guest data, payments, and operations, the answer is almost always no — and the reason has little to do with whether the code is good enough on day one.

Where vibe coding is genuinely great

Let's be clear about this, because it's easy to be either entirely dismissive or entirely uncritical, and neither is honest. Vibe coding is a real, useful tool for a specific category of tasks:

Internal tools without sensitive data — a simple overview of who's on holiday when, a calculator for catering quantities based on guest counts, a dashboard showing today's arrivals pulled from a spreadsheet. One-off needs — something you need this month for a specific event, that doesn't need to live on afterward. Prototypes — to test an idea quickly before possibly asking a vendor to build something proper. Automating an annoying manual task — for example, a small script that pulls numbers from one system and enters them into another, without touching guest data directly.

The common thread here is that the consequence of something going wrong is small and local. If the calculator miscalculates one day, you notice quickly and fix it yourself. No guest is harmed, no personal data leaks, and no payment gets charged incorrectly.

Where it becomes something else entirely: guest data, payments, and operations

A PMS or event system isn't in this category, and it's worth being entirely concrete about why, rather than just saying "it's more complicated" and leaving it at that.

Security isn't something you bolt on at the end. A system handling guest names, contact information, payment references, and possibly health information in a comment field needs to think through access control, encryption, and logging from the very first line of code — not as something added once there's "time for it." An AI tool that generates code quickly usually generates the code that's quickest to write, not automatically the one that's most secure. There's no built-in guarantee that a vibe-coded system is actually protected against the most common attack patterns, unless someone who genuinely understands security goes through it line by line.

Regulations don't disappear because you built it yourselves. Norwegian VAT handling on a day package, EHF invoicing for public-sector customers, GDPR requirements for how guest data is stored and deleted — all of this applies regardless of who wrote the code. The difference is that an established vendor has solved this once and maintains it continuously for all their customers at the same time. Build it yourselves, and you also have to keep it updated yourselves, every single time the regulations change.

Maintenance isn't something that ends once the system "is done." This is probably the single most important point, and the one most often forgotten in the enthusiasm of building something fast. Building a working version is the easy part — maybe 20 percent of the real workload over time. The remaining 80 percent is what happens afterward: libraries and dependencies that need updating when security holes are discovered in them, integrations that stop working when an external service changes its own API without warning, backups that need to be tested regularly — not just taken — and someone who's actually available when something stops working on a Friday at four.

Who owns the problem the day the person who built it leaves, or gets busy with something else? This is perhaps the most underrated risk of all. A vibe-coded system usually has one person who understands how it all fits together — often the one who built it, frequently without formal documentation beyond whatever the AI tool generated along the way. The day that person leaves, goes on sick leave, or simply ends up with other priorities, you're left with a system nobody else really understands, and no vendor to call.

A simple thought experiment that reveals where the line actually sits

Ask yourselves: if this system was down for six hours on a Saturday with full occupancy and a wedding in the function rooms, what would it cost you — in money, in reputation, in lost guest trust? And: if a guest's payment information or health data leaked from this system, who would you call, and who would actually be held accountable?

If the answer to the first question is "not much," and the answer to the second is "not relevant, it doesn't touch that kind of data," you're probably in the safe zone for vibe coding. If the answer is "that would be catastrophic" or "we honestly don't know," that's a clear signal this belongs with a vendor carrying real accountability — a contract, an SLA, someone who can actually be held responsible, not just an AI chat that helped you out one afternoon.

It isn't either-or

The sensible approach probably isn't choosing between "build everything yourselves" and "buy everything from a vendor." Use vibe coding freely for the internal, low-risk tools where it genuinely gives you something fast and cheap that no vendor would have built for you anyway. Keep an established vendor with real accountability for whatever touches guest data, payments, and the operation of the business itself. And be honest with yourselves about which category a given need actually falls into before you start building — not after it's already living in production and has become harder to say no to.