From Spreadsheets to SaaS: How LockerLedger Started

There is a specific kind of adrenaline that hits when the padlock comes off a storage unit.

You are standing there with only a few seconds to scan everything: the dust, the boxes, the furniture shapes, the bags, the tools, the electronics, and whatever else might be hiding in the back. In your head, you are already doing the math.

What is the bid at? What can I sell? What is trash? How much work is this going to be? Is there enough margin here?

When I first started bidding on storage units and flipping items on Facebook Marketplace and eBay, I thought the hardest part was the physical work.

The hauling. The sorting. The cleaning. The staging. The listing. The dump runs. And honestly, that part is hard.

But as I started taking the process more seriously, another problem slowly started creeping up on me: the data.

The part nobody sees

Storage unit flipping can look simple from the outside. Win a unit, clean it out, sell the good stuff, make a profit.

But if you are trying to treat it like a real side business and not just an expensive treasure hunt, you have to know your numbers.

You need to know what you paid for the unit. You need to know what you spent on fuel. You need to track dump fees, supplies, labor, refunds, platform fees, and anything else that eats into the margin. You need to know what sold, what is still sitting, and what each unit actually earned.

Because if you do not know your real profit, you are not really running a business. You are just doing a lot of manual labor and hoping the math works out later.

That was the problem that pushed me to start building my own system.

Phase 1: The spreadsheet era

Like a lot of people, I started with a spreadsheet.

At first, it made perfect sense. Excel was easy to open, easy to edit, and flexible enough for whatever I needed that day.

I had columns for the unit number, auction price, item description, estimated value, actual sale price, expenses, and profit. For a while, I felt like I had it under control.

Then the spreadsheet started turning into a monster.

Storage unit inventory is not clean. It does not behave like normal retail inventory. You are not scanning neat barcodes from a shelf. You are pulling random items out of boxes, trying to figure out what they are, taking photos, sorting piles, deciding what to list, what to donate, and what to throw away.

A spreadsheet can track that, technically. But it does not make it easy.

The first big problem was using it on my phone. Trying to scroll through a giant spreadsheet on a mobile screen while standing in front of a dusty unit is miserable. It gets even worse when you are tired, dirty, wearing gloves, or trying to move fast before a pickup deadline.

The second problem was data entry. I would come home after cleaning out a unit and still have hours of typing ahead of me. Instead of listing items and making money, I was sitting at the computer trying to remember what came from where.

The third problem was trust. One deleted row, one broken formula, or one bad copy-and-paste could throw off the numbers. Nothing makes you question your whole system faster than opening your master spreadsheet and seeing a broken formula where your profit should be.

Eventually, I realized something: if I was spending more time managing the tracking system than actually selling inventory, the tracking system was broken.

Phase 2: The Python prototype

At some point, I got tired of fighting the spreadsheet.

I have an associate’s degree in computer science, and I’ve always liked solving problems with code. My day jobs have also trained me to think in a very logical, troubleshooting-heavy way: find the bottleneck, understand the process, and build a better system.

So I started building.

The first version was not some polished web app. It was a local Python project.

At that stage, I was mostly trying to solve my own problem. I wanted something that could handle the math better, organize the data better, and give me more control than a spreadsheet.

Python was a good fit for that. It let me automate the boring parts and start thinking about the workflow in a more structured way.

Instead of dealing with random spreadsheet cells, I started thinking in terms of units, items, costs, sale prices, and profit. I could write logic that made sense for how storage flipping actually works.

That early version eventually became what I was calling the Dos Bros Command Center.

The name made sense at the time because Dos Bros was the storage unit flipping side hustle Stephanie and I were building together. The tool was basically our internal command center for trying to keep the chaos organized.

And honestly, that first prototype was a big step forward. It proved the idea worked.

But it had one major problem: it lived on my laptop.

The laptop problem

A local Python tool is powerful, but it is not very useful when you are standing at an auction, sitting in your truck, checking a pickup deadline, or trying to look something up from your phone.

That was the next big realization. The system could not just be smarter than a spreadsheet. It had to be available where the work actually happens.

Storage unit flipping is not something that only happens at a desk.

• It happens at facilities.
• It happens in garages.
• It happens in driveways.
• It happens in storage spaces.
• It happens while you are loading, sorting, listing, messaging buyers, and trying to remember which unit something came from.

If the data only lived on my laptop, then the system still had a wall around it. I had built a better engine, but it was bolted to the floor.

Phase 3: The web app decision

That is when the project started changing from a personal tool into something bigger.

I realized that if I was running into these problems, other storage unit flippers probably were too.

• The spreadsheet problem.
• The inventory problem.
• The photo problem.
• The expense tracking problem.
• The did this unit actually make money problem.

Those are not just my problems. They are part of the workflow.

So I started thinking differently. This did not need to be just an internal tool for Dos Bros. It needed to become a real web app that could work from a phone, tablet, laptop, or desktop.

That is when the name LockerLedger started to make more sense.

A locker is where the flip starts. A ledger is how you track the money. That was the product: a cleaner way to track storage unit flips from bid to profit.

Moving to a modern stack

Moving from a local Python prototype to a web app was a big shift.

I started building LockerLedger with Next.js, React, Tailwind, Prisma, and a database-backed structure. That gave the project a real foundation instead of just a local script.

The goal was not just to make something that looked better. The goal was to make something I could actually use in the field.

I wanted to be able to open the app on my phone and see my units. I wanted to track inventory with photos. I wanted expenses and sales tied back to the right unit. I wanted reports that showed whether the work was actually paying off.

The web version made that possible.

It also forced me to think more seriously about the user experience. A spreadsheet can be ugly and still function. A real app has to be clear, fast, and easy enough to use when you are tired after cleaning out a unit.

That became one of the biggest design goals for LockerLedger: keep it clean, keep it practical, keep the important numbers visible, and do not make the user fight the tool.

What changed

The project has changed a lot since the early spreadsheet days.

At first, I was just tracking numbers. Then I was trying to automate calculations. Now LockerLedger is becoming a full workflow for storage unit flipping.

• Track units you are watching, bidding on, won, lost, or cleaned out
• Save facility details and pickup deadlines
• Add inventory tied to each unit
• Store item photos, notes, condition, and estimated value
• Track expenses like fuel, dump runs, supplies, fees, labor, and refunds
• Record sales and platform fees
• See profit by unit
• Use AI scanning to make inventory faster
• Keep tasks, calendar dates, and reports in one place

That is a long way from a spreadsheet with too many columns.

The reality of building it

I will not pretend the transition was easy.

There have been plenty of late nights where one bug took way longer than it should have. There have been moments where fixing one thing accidentally broke something else. There have been database issues, route issues, save bugs, layout bugs, and plenty of why is this not working moments.

But every time a core piece started working, it made the whole thing feel more real.

• The first time inventory saved correctly to the database.
• The first time AI Scanner pushed items directly into inventory.
• The first time a unit’s expenses and sales tied back into the Money page.
• The first time the dashboard started feeling like an actual command center.

Those moments kept pushing the project forward. Because this was never just about writing code. It was about building something that solves a real problem I kept running into.

Why I’m building LockerLedger

LockerLedger exists because storage unit flipping is messy, and spreadsheets only get you so far.

There is a lot happening in one flip: bidding, pickup deadlines, sorting, inventory, research, photos, expenses, sales, fees, and profit. When all of that is scattered across notebooks, phone photos, spreadsheets, and memory, it becomes easy to lose track.

I wanted one place to bring it together. Not because I wanted a flashy app. Because I wanted to know my numbers.

• I wanted to know what was still sitting.
• I wanted to know what sold.
• I wanted to know what each unit really earned.
• I wanted to stop guessing.

That is the reason LockerLedger is being built.

Looking ahead

LockerLedger is still growing, and I am still polishing the early version. The MVP is just the beginning.

There are still features to tighten, workflows to improve, and real feedback to collect from storage auction buyers, resellers, and flippers who deal with this same chaos.

But the direction is clear now.

LockerLedger started as a spreadsheet because I needed to track the work. It became a Python prototype because the spreadsheet was not enough. And now it is becoming a web app because the workflow needs to be available anywhere the work happens.

From bid to pickup. From inventory to sale. From expenses to profit.

That is the evolution of LockerLedger. And I am excited to keep building it.