The Side Hustle I Didn't Know I Was Qualified For

I spent about a decade working in operations for a small fulfillment company. Managing receiving, picking, shipping, inventory, and customer relationships. Walking the warehouse floor. Training staff. Fixing the things that broke.

I left that job a few years ago. I didn't think I was leaving with anything valuable. I thought I was leaving with a resume bullet. Turns out I was leaving with a decade of knowledge that nobody with a computer science degree has.

I'm back now, as a consultant, building software for that same company. And the thing I've realized is this: if you know an industry well, you already have the hardest skill. The technical part is learnable. The domain knowledge is what took ten years.

This post is for anyone who works in operations, logistics, healthcare, retail, restaurants, or any industry where the work is messy, and the existing software doesn't quite fit. You probably have a side hustle sitting right in front of you.

What I'm Actually Building

I'm building a Warehouse Management System (WMS) for a small fulfillment company. They have one warehouse location, dozens of clients, and thousands of orders a month. For years, they've run on spreadsheets, email, and institutional memory. That works until someone gets sick or an email is missed. Picking accuracy drops. Inventory counts get out of sync. Shipping deadlines slip because nobody knows where something is until someone walks the floor.

Off-the-shelf WMS software exists. Most of it costs tens of thousands of dollars up front, requires months of configuration, and then the warehouse staff ends up working around it because it doesn't actually fit their workflow. That's the trap small operations get stuck in: buy the expensive software, lose months to implementation, end up with a tool that's worse than the spreadsheets.

So I'm building a custom one. One that does exactly what this company needs. Nothing it doesn't need.

The Stack (For People Who Care About That)

I'm building with Supabase for the backend database, Vercel for hosting, and Cursor plus Claude for the actual coding work. I'm still a beginner on the backend side, especially when it comes to complex schemas and security. But AI tools have made it possible for me to build something I couldn't have built two years ago.

Full disclosure: I do know enough code to problem-solve and spot-check AI code. I'm not relying on Cursor for 100% of the code base here.

What AI is good for: writing code I can read, explain, and modify. Helping me understand why a query is slow. Flagging security considerations I wouldn't have thought of. Letting me prompt my way through problems instead of spending hours Googling Stack Overflow.

What AI is not good for: knowing what to build. That part is still all me. AI will happily write you a beautifully structured database schema that has nothing to do with how a warehouse actually works. It doesn't know that receiving staff rush and miss duplicates. It doesn't account for pickers losing time when switching zones. It doesn't know that the warehouse is loud and dusty, and people are squinting at screens outside in the sun.

I do. That's the part I'm bringing to the table.

The Timeline

I started this project in December 2025. I'm wrapping up the main build this month, with small tweaks and additions ongoing. That's about six months from zero to functional software, while also working a full-time W-2 job and a second contract.

I don't say that to flex. I say it because six months is fast for custom software, and the only reason I could move that fast is that I wasn't learning the business and the code at the same time. I already knew the business. All I had to learn was the code.

If you don't know the business, building a custom operations tool for a company takes years. You spend the first year doing "discovery," which is a fancy way of saying "asking operations people questions they don't know how to answer." Then you spend another year building the wrong thing. Then you spend a third year rebuilding it.

I skipped all of that. I know what receiving looks like on a bad day. I know why picking errors happen. I know which reports managers actually use and which ones get ignored. I designed the system around that, not around what a software engineer would assume.

Why Domain Knowledge Is the Real Moat

Here's the thing I didn't expect when I started this project: the technology is the easy part. Learning Supabase took a few weeks of deep work. Writing SQL queries that track inventory movements took a few days longer than someone who knows SQL front and back. But knowing what to track in the first place took ten years.

When I was designing the inventory schema, I had to decide whether to track individual items or just quantities by case SKU. In most warehouses, that's an obvious call. Here, it matters because some items require serial-level tracking, while others don't. You'd only know that if you'd worked in receiving.

When I designed the picking interface, I had to decide what information to show. Too much, and pickers slow down. Too little and they make mistakes. I know the answer because I've picked alongside these people and watched where they get confused.

None of that is in any coding tutorial. None of it is in any business book. You learn it by doing the actual work, for years, paying attention.

The Side Hustle

This is the part that matters if you're reading this as someone in your own job, wondering whether you have something like this.

If you know a process well enough to fix it, you probably know it well enough to automate it.

The economics work when you already know the business. I could quote this project at market rate because I'm not billing for learning the operations. I'm billing for building the thing. A software engineer coming in cold would charge three times as much, take twice as long, and produce a final product that fits worse.

You don't need to be a great software engineer. You need to understand the problem, be willing to learn the technology, and find a situation where your knowledge is valuable enough that someone will pay you to build a solution.

The easiest situation to find: your old employer. Or your current one. Someone you've worked for who has a problem you already know how to solve. This is what AI is great for and the kind of thing I love seeing it do.

What It Looks Like to Land This Kind of Work

I didn't pitch this project. They asked.

Originally, I was hired to find and onboard them to an existing system, but after months of trial and error, the conversation came up naturally. That's usually how it goes when the domain knowledge is real. You don't cold-call companies trying to convince them you can help. You maintain the relationships you built when you worked there, you stay in touch, and when they hit the wall the spreadsheets can't handle, they call you.

If that's not happening for you, the question isn't whether you're qualified. It's whether the people who knew you when you worked there know what you can do now. A LinkedIn post about what you're building. A note to a former boss. A mention in a casual text to an old coworker. That's how this work moves.

What I'm Still Figuring Out

I'm not done with this project, and I'm definitely not done learning. The mobile-friendly version is still down the road. There are features I know this company will want over the next few years that aren't in v1. Every client who signs on after this will have their own requirements, which will force me to generalize parts of the system and rebuild others.

Custom software is never really done. But offering that kind of customization to a small family-run business is rare, and it matters to them. The big WMS vendors don't build for companies this size. I can.

The Takeaway

If you're sitting in a job right now and thinking you don't have any marketable side-hustle skills, I want you to reconsider.

You know things that software engineers don't know. You know things that consultants with MBAs don't know. You know the difference between what a process is supposed to do and what actually happens when it breaks. That knowledge is worth money to someone, and it's becoming easier every year to turn it into software.

The barrier used to be that you had to learn to code from scratch before you could build anything. That's no longer true. You still need to understand the basics. You still need to read what the AI writes and know whether it's right. You still need to think about security, permissions, and edge cases. But you don't need to be a traditional software engineer anymore.

The hardest skill has always been domain knowledge. If you have it, start paying attention to how you'd use it.