From Lovable and Excel to Your Dream Product

Have You Ever Built the Workaround but Not the Platform?

Have you ever solved an important workflow with a mix of spreadsheets, small prototypes, and clever internal habits, then realized the business had outgrown all of it? Maybe the calculations work, but only if the right person maintains the sheet. Maybe the prototype explains the idea, but it cannot support a whole team. Maybe everyone can imagine the dream platform, yet the actual workflow is still scattered across files, formulas, and conversations.

That was the position this client was in. Their team had been using Excel sheets, internal know-how, and small Lovable experiments to solve real problems in planning warehouse racking and slotting. The workflow was practical, but it was fragmented. Calculations lived in spreadsheets. Process knowledge lived with specific people. Visual understanding of the finished layout required experience, interpretation, or separate tools. Rollout timelines were assembled from a mix of data, manual planning, and repeated communication.

That kind of workflow often looks messy from the outside, but it is usually full of product logic. The spreadsheet formulas describe rules. The columns describe important entities. The repeated manual edits show where automation can help. The Lovable prototypes show what the team wished the software could become. The communication patterns reveal which decisions are collaborative and which ones should be standardized.

The goal was to turn those fragments into a full platform: a collaboration app where users could automate slotting calculations, visualize a racking layout before installation, inspect capacity per bay, understand load and access constraints across the aisle, and build timelines for each phase of the rollout. It needed to support operations thinking, not just present data in a nicer wrapper.

From Prototype Features to a Shared System

The client had used Lovable to create small features that emulated parts of the workflow. Those experiments were useful because they expressed product intent. A small calculator showed what the team wanted to automate. A rough planning screen showed which fields mattered. A visual prototype showed where the team wanted more confidence before racking entered installation.

But small apps are not the same as a platform. They often solve one moment in the process without resolving the relationships around it. An operations platform has to connect the slotting inputs, the racking model, the capacity data, the review process, and the timeline. It has to support collaboration across people who care about different parts of the same layout. It also has to reduce spreadsheet risk by making important logic visible, repeatable, and easier to audit.

We approached the project by separating the workflow into product layers. The first layer was structured input: the information users need to define a layout and its operational constraints. The second layer was calculation and derived data: dimensions, capacity per bay and level, load indicators, and other outputs that had previously depended on spreadsheet logic. The third layer was visualization: a way to see the finished layout and inspect it in context. The fourth layer was planning: rollout phases, timelines, and collaborative review.

The Interface Had to Make Complexity Readable

For this kind of product, a dashboard alone would not be enough. The interface needed to help users reason about a layout before it existed physically. That meant the visual system had to balance dense data with spatial understanding. Users needed to see a finished racking layout, inspect details, and move between summary and precision without losing trust in the information.

The production stack was selected around that requirement. Vite gave the app a fast foundation for a custom front-end. shadcn and Tailwind CSS made it possible to build a consistent interface language without slowing down the team with generic UI decisions. Zustand kept the client-side product state understandable as users moved between layout configuration, visual review, and timeline planning. Supabase provided the database and collaboration foundation. Three.js powered the visualization layer, where users could explore the racking and understand the output of the system in a more direct way. GSAP supported interface motion where transitions helped users understand context shifts between views.

The result was not just a 3D viewer. It was an operations workspace. Users could visualize the finished layout, review capacity per bay and level, inspect load and access constraints, and connect those decisions to timelines for each rollout phase. The platform gave teams a shared place to discuss the layout before installation, which is where many expensive mistakes are easiest to prevent.

Replacing Spreadsheet Dependence Without Losing Expertise

The aim was not to erase the client’s expertise. The aim was to encode the most repeatable parts of it into software so the team could move faster and make fewer manual mistakes. Excel had been useful because it was flexible and familiar. The platform needed to preserve the value of those calculations while making them easier to use, easier to share, and easier to connect to the rest of the operations process.

That meant treating automation carefully. Some calculations could be fully automated. Some needed to remain inspectable. Some outputs needed visual explanation, because a number alone is not always enough for an operations review. By connecting slotting calculation, visualization, capacity breakdown, and timeline planning, the app made the workflow more legible for everyone involved.

The Result

In four months, the finished direction became a collaboration platform for warehouse racking planning: part calculator, part visualizer, part planning tool, and part shared review space. It took the team’s Excel sheets and Lovable experiments seriously, then rebuilt them as a coherent system with a modern web stack.

This kind of project shows how internal tools become strategic when they are designed around real operations logic. The valuable source material was not polished. It was a combination of spreadsheets, prototypes, conversations, and repeated operational habits. By turning that material into structured software, the team gained a clearer way to automate slotting, understand layouts before installation, coordinate rollout phases, and collaborate around the same source of truth.