From ERP Dreams to Cruise Ship Reality: Lessons from Building a Shipboard System

The Dream That Wouldn't Dock

For years, I'd harbored a vision: to build my own ERP system tailored to the chaotic, multi-departmental world of a cruise ship. With operations spanning galley inventory, housekeeping supplies, passenger services, and shore excursion logistics, the need for a unified system was obvious. But I wasn't a coder. I'd studied computer science in college, but after graduation, I barely touched a keyboard for anything more than email.

My career had taken me through enterprise digital projects, a stint at an ERP vendor, and even a Big Four firm. Along the way, I'd absorbed how business flows, how accounting entries are created, and how messy pre-launch chaos can be. In my head, I had a complete model of how a cruise ERP should work—how procurement of food and beverages should generate journal entries, how passenger ticket sales should hit revenue, how payroll for onboard staff should reconcile. But without code, the model was just a mental sandcastle.

When AI Finally Turned the Key

Then AI arrived. It was like someone handed me the keys to a ship I'd been admiring from the shore. I started building, and now that system is in beta. Purchase orders, production schedules (think of the galley's meal prep), and sales transactions automatically generate accounting entries, which roll up into balances and finally into financial statements. Even better, I've abstracted core modules into MCPs—each containing dozens of tools that act as API endpoints. Plugged into WorkBuddy, I can ask in plain English: "What's the current inventory of frozen shrimp?" and it fetches the answer without opening a single menu.

But this wasn't a smooth sail. I hit four major reefs, and each one nearly sank the project. Here's what I learned, in hopes that other cruise-line tech tinkerers can avoid the same wrecks.

Reef #1: Letting Each Module Speak Its Own Accounting Language

In my first version, I let each module generate its own accounting entries. Procurement calculated its own payables, the galley tracked its own production costs, and sales booked its own revenue. It was a mess. Balances didn't tie out. Procurement said we owed $50,000 for food supplies, but the general ledger said $48,500. Everyone was sure they were right.

The fix was to centralize. Now, modules don't create entries at all; they emit business events. A single, centralized "voucher engine" translates those events into accounting entries based on configurable mapping rules. When a purchase receipt hits, the engine debits inventory and credits accounts payable. When a passenger checks in, it recognizes revenue and receivable. All entries flow into one balance table, and financial statements are just read-only projections of that table.

The lesson: true business-finance integration isn't about stitching modules together; it's about having a single translation pipeline from business action to accounting language. Keep the rules centralized and configurable. Don't let each module interpret the world its own way.

Reef #2: Playing Model Roulette

At first, I thought I'd be clever and use different AI models for different modules—one for procurement, another for the galley scheduler, a third for passenger bookings. The idea was to pick the best tool for each job. Instead, I got a Frankenstein codebase. One model's API style clashed with another's. Naming conventions, error handling—everything was a mismatch. Fixing one module broke another, and debugging felt like trying to sail through a typhoon blindfolded.

Even worse was letting different models take turns editing the same logic. The context from the previous model was lost, so the next one would rewrite it from scratch, introducing inconsistencies. Each piece looked fine alone, but together they were a disaster.

I finally settled on one model for the entire project. Consistency beats cleverness. If you're an individual developer, don't get greedy. One model that works well is worth more than three that are smart but can't cooperate.

Reef #3: Version Control—or the Lack Thereof

In the early days, I didn't use Git properly. I saved files with names like "final", "final2", "real_final", "real_final_NO_CHANGES". You know the drill. Then came a massive refactor of the voucher engine that broke everything. I tried to roll back, but there was no clean version. I had to rewrite from scratch. That happened more than once, and each rewrite cost days of work and a chunk of my sanity.

The fix was simple: use Git religiously. Create a branch for each feature, keep the main branch clean, and only merge tested code. If you break something, you're ten minutes from reverting. I also made a habit of committing stable code at the end of each day, leaving unfinished work in a branch overnight.

For a solo developer, version control isn't optional. It's your life raft. Without it, you're coding on the edge of a cliff, and one wrong move sends everything into the abyss.

Reef #4: The Front-End Calculation Trap

Once the system ran, I decided to make it conversational. I wrapped core modules into MCPs and connected them to WorkBuddy. But I'd left some calculations—like subtotals, taxes, and invoice summaries—in the front-end code. That worked fine in the GUI, but when the conversation layer called the APIs, it didn't execute those front-end functions. The result: data mismatches. The balance sheet would show one number, but a conversation query would return another. It took me hours to realize the problem.

The solution was to move every calculation, no matter how trivial, into the backend. The front-end and the conversation layer should only pass parameters and display results. I also added a double-check: the same figure is calculated via two independent paths, and if they don't match, the entry is blocked. That's a belt-and-suspenders approach that finally made the data trustworthy.

The lesson: MCP interfaces must be fully backend-complete. If you calculate anything on the front-end, it will evaporate when called via conversation. The conversational interface actually forced me to design cleaner APIs—a silver lining.

The Real Lesson: AI Gives You Muscle, Not Judgment

Through all this, I've come to a conclusion: AI loosens the reins on coding, but it doesn't loosen the reins on thinking. Many people think AI will design the system for them. It won't. It will write the code, but you still have to figure out what the system should do. That gap—between writing code and thinking—is where the reefs hide.

None of these four pitfalls did I sail through on the first try. Each one cost time, morale, and nights staring at the screen wondering if I was in over my head. But AI does make it possible for one person to build something that used to require a team. The trade-off is that you're the only one making decisions, and there's no one to hit the brakes when you're about to go overboard.

My system is still in beta. It's not perfect—modules need polish, reports need tuning, and occasionally it mishears my voice commands. But it does something I only dreamed of years ago: it generates a balance sheet on its own. And that's a pretty good feeling.