Building Lifestyle Software in Unglamorous Industries: Lessons from a Decade in Waste

I'm writing this one month after leaving my role at Routeware, where I spent years building software for the waste industry. I expected to start my next venture right away. Instead, I'm asking a lot of questions about how I want to build a software business. For the first time in over a decade, I'm not working nights and weekends.

I spent my thirties building my technical skills and industry knowledge. Now I'm in my early forties. I ride mountain bikes to clear my head and stay fit, and I hope to have another good decade of riding. The usual advice is to work hard now and retire later, when your body is older and your kids have moved out. I don't want to wait that long to spend time with my family.

For knowledge workers, that advice doesn't fit well. We can write code and solve hard problems well into later life. So why plan our careers as if we can't?

That led me to a question: can I build a bootstrapped software business that pays well and also gives me the life I want now? As a solo technical founder, I think one answer is to work in industries that most software founders overlook.

Industry knowledge

I've sat in many meetings at software companies where people tried to work out what customers want. In my view, a development team would learn more by working inside a waste hauler for six months, doing the business work, not the programming.

I worked at Paso Waste before I moved into software. That experience helped me a lot. I knew what frustrated dispatchers, what customer service reps needed, and which "requirements" were only nice to have.

You get this kind of knowledge by doing the work next to your customers. User interviews and market research don't give you the same picture. If you want to build software for a niche industry, pick one where you have real experience, or go get some. Insiders see the daily problems that everyone else has learned to accept.

Calm software

In my career, many late-night support calls came from single points of failure and systems that were not well documented. When something broke, the people on shift called the few people who knew how to fix it, often at 2 AM.

I don't want to build software that needs that. By "calm software" I mean the user experience, the developer experience, and the business model.

Calm software follows these principles:

• Resilient: Failed health checks start automated recovery.
• Twelve-factor: Clear separation of code and configuration.
• Documented: Tests and docs come first, not last.
• Degrades gracefully: When a part fails, the system fails safely.

These are what let a solo operator sleep at night.

Calm software also means building at your own pace. As a solo founder, I don't answer to investors or a board. I can take the time to build things right, which I think gets you to a working product sooner than moving fast and breaking things.

I've started to use AI coding agents like Claude Code and Cursor AI to build prototypes quickly. In a large company, approval for new tools can take a long time. As a founder, I signed up and started.

Pick a problem of the right size

The best problems for a bootstrapped business are hard enough that they are not easy to copy, but small enough that one person can build and run the solution.

The idea I'm working on now (HaulerPhone) came from conversations with industry contacts after I posted that I had left Routeware. Several haulers and software leaders told me their customer service and sales reps needed better information during calls. When you have tens of thousands of accounts, finding the right one in legacy software is slow.

The solution is simple: use caller ID and a cached lookup to show the account when a rep answers the call. The rep gets the account number right away and can open the legacy system to make any changes.

This is the right size of problem. You need industry knowledge to understand why it matters and how it fits into the workflow. It doesn't need a large team to build and maintain.

Good opportunities are often common annoyances that nobody has fixed. To find them, I ask the people who do the work what annoys them. They may not know the solution, but they know where the friction is because they feel it every day. Then I use AI coding agents to build a clickable prototype in a few days. I think most software teams can now build a prototype in the same week.

Partnership

Some B2B software companies start from "how do we get our share?" and not "how do we help our customers?" That can lead to shortcuts and products that don't help much.

In the waste industry, most haulers are family businesses, often run by several generations. If a vendor helps a hauler run more efficiently or grow into new territory, that hauler will likely buy more software over time. That works for both sides.

A partnership approach means software with clear, measurable value. If a hauler spends $1 on your product, they should make or save $2 somewhere else in the business. The return should be easy to see without a spreadsheet.

A lifestyle business makes this easier. Without aggressive growth targets or a next funding round, you can focus on a smaller number of customers who pay for tools that solve their problems.

Making the change

If you are still employed and thinking about this path, learn as much as you can about the customers and the work that interest you most. Talk with people in the industry about their problems. Those relationships will help keep you going when the work gets hard.

Several industry contacts checked in with me during my first month on my own. Those check-ins helped my motivation more than they know. My energy has been lower than I expected after a decade of steady work, and those conversations helped.

The technical preparation is simple: learn modern tools, including AI-assisted coding, practice building and deploying applications quickly, and learn the twelve-factor method. The more important preparation is industry knowledge and relationships. Those relationships help you understand the industry, its unwritten rules, and who will support your product because they trust that you understand their work.

Also, save enough money to give yourself time to recover. I thought I would start right away after leaving Routeware, but I needed this month more than I expected. I suggest 6 to 12 months of expenses, so that money pressure doesn't drive your decisions.

What I'm building toward

I want a software business that pays for a comfortable life. Not a mansion or a second home. Enough to travel a few times a year in my Sprinter van, riding bikes and camping when the weather and time allow.

The product must cover its infrastructure costs (including any AI/LLM costs) and make enough profit to support my small family. It also needs to mostly run itself, with automated recovery, good documentation, and an architecture that avoids 2 AM calls.

I'm not trying to build a unicorn. I want to use what I know to build something useful for a specific group of customers, and have time for my life now.

My son is twelve. I want to spend the next decade with him, camping and riding while he still enjoys doing that with me.

A different path

The usual startup path is to raise money, grow fast, and sell the company. For technical founders with industry knowledge, there is another option: build profitable, sustainable software that solves real problems for people you understand.

That path means a few choices:

• Build first, then sell.
• Bootstrap for freedom instead of raising money for faster growth.
• Treat customers as partners.
• Choose a calm architecture over move fast and break things.

The waste industry taught me that good opportunities often look boring from the outside. Many founders go after popular, crowded markets. You can build a good business solving unglamorous problems for people who need better tools.

I'm still working this out, and I'm still looking for the right problem for the next decade of my work. But I know I want to build software that fits my life instead of taking it over.

If you are a technical founder and the usual startup path doesn't fit you, look at the industries you know. There may be a real problem there that you can solve.