The Story of Planner: The Operations App We Built, Broke, and Buried

Part 1 of 2. How my first product got built, got hated, and got shut down, and why that was the right call.

It was 2021. I was 25 years old, in my first real years of product ownership, and I was about to learn that shipping software is the easy part.

D-Marin had an operations management application called Planner. The idea was solid: standardize how inspections, maintenance and daily tasks were carried out across marinas in different countries. The web app was where you defined tasks and templates, set shifts, and managed the crane schedule for dry dock, among a lot of other things. The mobile app was where field employees actually did the work they were assigned.

It worked. For the first time, D-Marin had a global standard for marina operations. That is not a small thing when your business spans multiple countries, languages, and teams who have been doing things their own way for decades.

My job was onboarding new marinas, building the KPIs that measured employee performance, and, the part nobody puts on a job description, making sure people actually used the thing.

The rollout was the product

I learned early that a feature does not exist until someone in a marina, in the rain, at 7am, uses it correctly.

Preparing a marina for go-live looked like this. We would sit with heads of departments, marina managers and country directors to understand how they actually worked. We would go through their paperwork, the real inspection sheets, the ones with coffee stains, and cross-check them against our operational standards and the manufacturers' guidance. Then we would build the task library: what the task is, how often it happens, what the checklist contains, whether it needs a photo, whether it needs a comment, what kind of response each step requires.

You can imagine the number of meetings.

Then came translation. Every task, every checklist item, into every local language, with Google Translate, because there was no LLM back then. Then we would sit with native speakers in each country to check whether any of it made sense, and fix the parts that did not. Then upload, train, go live, and monitor the KPIs with weekly calls to make sure things were really happening and not just being ticked.

Traveling to each country for rollout and training was probably the best education I could have had. I saw the same product land completely differently depending on where it landed.

Some teams loved it. Their effort was finally visible and measurable, and the structure made their day easier. Other teams, people who had worked in that marina for over twenty years doing it their way, hated having an eye on them and being asked to report into a phone.

That was the first time I really understood that culture is a product variable. Not a soft one. A real one, with a measurable effect on adoption.

Where it genuinely shined

The crane schedule. The dry dock chief could plan the lift and launch schedule, define the health and safety checks the team had to complete before each operation, and require photos during the work. That killed a mountain of back-and-forth phone calls, Excel sheets and lost information: someone misplacing a paper, or nobody checking the boat's insurance before a lift. Real risk, removed by a feature.

The ML boat detection. We put cameras at the marina entrance and trained a neural network to identify boat type and detect arrivals and departures. The camera took a photo, classified the boat, and sent it to Planner's backend, which created a task for the sailors. For an arrival, the sailor saw the image and recorded where the boat was moored. For a departure, they were simply informed.

From a data perspective this was the good stuff. This was the first year after CVC acquired D-Marin, and the management team was new to the business. Suddenly we had peak arrival and departure times, and average duration per operation. That fed resource allocation, budgeting and occupancy management, decisions that had been running on instinct.

Somewhere in there I also got to watch mega yachts being lifted out of the water on a Tuesday afternoon, which I am not going to pretend was not a perk.

Product, for me, was never "talk to engineers and designers and ship." I had to execute what the software promised and make sure people used it. Every feature had a direct, measurable, physical consequence.

The part that hurt

It was not all good, and I would be lying if I told the story that way.

Asking a sailor to complete tasks on a phone while standing in a dinghy, in high season, with a queue of customers waiting, is a design failure. It was genuine extra effort with no reward for them, and they let us know.

We were also too focused on how employees spent their working hours. It felt like micromanagement. I am not saying it was, but in product, how something feels is what you are actually shipping.

Underneath all of it, we had a technical debt problem. Fast development without a mature engineering process, feature stacked on feature, until the answer to "can we add this?" was "not without changing the architecture." We were looking at an architectural rewrite, a UX redesign, and infrastructure-level changes. With no in-house developers, we already knew what that meant financially.

So I worked with the engineers to define the target state, map what was missing, and build a roadmap to get there. For UX we had nobody, so I became the nobody. I took every course and read every article I could find on UX and design fundamentals, and started producing mockups grounded in qualitative and quantitative research with users across countries.

Then I asked the question I had been avoiding

Everything was in place except the one thing that mattered: how did users actually feel about the product?

Without a baseline I could not measure any improvement, and I could not define what success even looked like.

So I built an anonymous survey in Microsoft Forms and distributed it across the marinas. Questions on UX, performance, accessibility, how much the app helped in daily work, and what we were doing badly. Hundreds of responses came back, in every language we operated in.

Analyzing it was brutal. Translate everything into English (Google Translate again, and I would like the record to show that I earned my LLM subscription), read every comment, segment them, and try to hear what people were actually saying underneath the complaints.

The eNPS came back at -37.

It was a bad number and an honest one. Even where we were clearly helping operations, the feeling of micromanagement and individual task assignment was something people genuinely resented. The UX and performance scores confirmed what we already knew.

Around the same time, the engineering estimate landed for taking Planner to the standard we had defined. Roughly half a million euros.

Killing the baby

So: a product with a negative eNPS, structural technical debt, no in-house engineering, and a 500K bill to fix it.

I built the case with the director I had been working with on the project, and the conclusion was uncomfortable but clear. We could rebuild the entire product, redesigning the task management logic from scratch and keeping everything Planner had taught us about what worked and what did not, with FutureMind, a partner we were already working with on the marina management system. For roughly 10% of the cost of repairing Planner.

We could also do it properly this time: one real product team, with a professional UX designer (even though I was getting decent, thank you very much), and a proper engineering setup.

Which meant recommending that we shut down an application the company had already invested heavily in building.

That was hard on two levels. Emotionally, because it was our baby and we had raised it. Strategically, because I had to walk into a board of directors and make the case that killing it was the responsible decision, not an admission that we had wasted three years.

The boardroom

The executive session was a full day at a hotel in Athens, and I was asked to present first.

I am not inexperienced at presenting. Honestly, I am usually overconfident about it. This was different. I was stressed as hell about how to phrase it and land the message with the board and the CEO, even though they were all genuinely good people and not at all the suit-and-tie types you would imagine. I was close with most of them and had already secured support from two of them before the meeting.

It still was not easy. Pre-alignment gets you a fair hearing, not a yes.

We presented, we discussed, and the decision was made: shut down Planner within three months, and during that window rebuild it, starting with an MVP covering core functionality, with a clear roadmap for the rest.

Big promise. Bigger commitment.

What Planner actually taught me

• Adoption is a product feature, not a rollout activity. If your plan for adoption is "training," you do not have a plan.
• Standardization without empathy reads as surveillance. We optimized for management visibility and paid for it in employee trust. Both are real users.
• Measure the feeling before you fix the thing. That -37 was painful, but it was the only honest starting line I had.
• Technical debt is a product decision, not an engineering problem. By the time it shows up as an invoice, you have already made the decision. You just made it by accident.
• If nobody owns UX, you own UX. Go learn it.
• Sunk cost is a storytelling problem. The board did not need to hear that Planner failed. They needed to see what it bought us: cost savings in operations, lower opex through real maintenance and inspection scheduling, effective resource allocation, and a hard-won map of what the next product had to be.

Planner earned its keep. It just was not the product we needed next.

And that is where StarFlow was born. I will write that journey in the next post.

Peace out.

Michael