How I built RigReport and shipped a working fleet management system for my sailing club
I didn't set out to build software. I just wanted to help solve a real problem.
At my sailing club, there was a recurring challenge: we needed a reliable way to track and verify all our boats and equipment: what the club owns, where it is, what condition it’s in, and which boats are ready to sail. Sometimes, before borrowing a club boat, members would rely on half-remembered damage reports and word-of-mouth updates. It felt inefficient, confusing, and avoidable.
In my head, the solution seemed simple. I could build:
A small app. A quick form. Problem solved.
I’ve built apps before, and it has been a relatively easy experience.
But my assumption didn’t last long…
What I Thought Building an App Would Be Like
Expectation: Make a basic tool, maybe tweak it a little, hand it over, move on.
Reality: Build a real product and get pulled into an ecosystem of tools, decisions, errors, mentors, and late-night troubleshooting.
I started by using the prototyping skills I’d learned in my Inertia class. Within a few hours, I had a rough demo: a simple site where people could log in, see the fleet, and report damage. It wasn’t fancy, but it worked.
When I showed it to my mom, she was impressed.
Then the community sailing board she’s on asked to see it. I presented my demo to them, and then again to the board of my sailing club. They loved it, and they asked for more.
Suddenly, this wasn’t just my idea anymore. It was becoming a shared project.
They wanted tracking beyond boats, for sails, dollies, and equipment, plus information like registrations, values, and insurance policies. They sent me a spreadsheet full of fleet data. This “small tool” was slowly turning into something much larger. It was exciting to get to work on the improvements.
Where Reality Hit Hard
Up until this point, I’d built controlled projects; small websites, contained simulations, things where I controlled most of the moving parts.
RigReport didn’t work like that.
This app needed memory.
It needed to handle multiple users.
It needed to store photos.
It needed to stay online without crashing.
And it needed to run on free or low-cost tools.
Which meant I wasn’t building a website.
I was stitching together an entire ecosystem.
Frontend. Backend. Storage. Hosting. Email. Background services. A tool whose only job was to keep the server awake so it wouldn’t “fall asleep.”
Thankfully, I didn’t have to do this alone. My dad helped out (while he doesn’t have much experience building websites, he does understand most of the code). I also used Claude Code as a sort of AI mentor.
Navigating all these tools felt less like coding and more like connecting parts of a machine that I barely understood.
The Learning Curve
I made mistakes. A lot of them.
At one point, I struggled trying to debug a deployment error, only to realize I had clicked “bot” instead of “project.” You should’ve seen the look on my dad’s face after we learned the problem. It was just one word that caused a total failure and cost us 3 hours.
I constantly found myself staring at walls of code, trying to find a single line to copy, hoping I wouldn’t break something.
It was frustrating. It was slow.
But over time, I started to understand.
I still can’t write complex code from scratch, but I can now read it (some of the time). I understand patterns. I recognize error messages. I know how to poke at a problem until it goes away.
From Tool to Platform
Once the app actually worked, I thought I was done.
I wasn’t.
Feedback kept coming.
So I kept refining.
Export tools. Email alerts. Tracking dock spaces. Better usability. Fixing edge cases I didn’t even know existed.
And when I hit walls I couldn’t climb alone, I asked for help.
Mentors stepped in.
Real software engineers like Kaelin helped untangle tricky technical problems.
Somewhere in that process, I noticed something important:
This wasn’t just a club database.
It was solving a problem that probably exists far beyond our club.
Then a question struck me:
Do other clubs experience fleet tracking data issues as well?
The Shift: From Project to Product
I started researching fleet and asset management tools.
What I found surprised me.
Most options were built for massive companies with huge budgets.
Others were narrow, focused on scoring or payments.
Almost none were designed for the everyday reality of volunteer-run clubs that just want to know:
Which boats are up-to-date?
That’s when the project earned its name: RigReport.
In addition, I built a public marketing site so I could advertise the app without displaying all of my club’s fleet information. (Link below.)
I added a demo.
I started reaching out to other sailing organizations.
Not because I have it all figured out, but because I want to see where this tool could actually help.
If you want to explore the RigReport demo, you can visit my demonstration site at rig-report.com.
What This Actually Taught Me
Looking back, the app was only half the project.
The real lesson was learning how to:
Build something for other people, not just myself
Keep going even when I didn’t fully understand what I was doing
Ask for help
Turn a small idea into something that matters
I’m not a master coder.
I still get stuck.
I still ask questions.
But I learned that you don’t need full expertise to begin.
You just need a real problem and the willingness to stay with it longer than expected.
The Credits
It took a lot of work to build a functional fleet readiness app (and I’m still building!), so I’d like to give a huge shout-out to the people who helped and continue to help me along the way:
My Dad: For helping with everything code-related and spending hours troubleshooting with me
Kaelin: For help with adding new features and advice on the coding process.
The members at my sailing club, especially Mr. Daniel: For all the feedback and help with improving the app.
Zain: For giving me the confidence to take-on this project without upfront coding knowledge.
My writing mentor Brianne: For help on the writing side of things (as always), and for help preparing for my board presentations.