AARON SPINDLER

Be your own first customer

I keep starting businesses the same way: I run into something frustrating in my own life, live with it long enough to understand the sharp edges, and then build the product I wish already existed.

The first customer is usually me. That has become one of the clearest filters I have for deciding what is worth building. I do not have to invent a fake user story or guess where the friction is. I already know, because I am the one hitting it every day.

RoomScout

RoomScout started because I had rooms to fill.

When I was in university, I rented a whole house and had to figure out how to find roommates. Finding people was only the first part. After that came all the smaller pieces that do not sound exciting but matter a lot when you live with other people: splitting bills, keeping things transparent, coordinating chores, and making sure everyone understood what was going on.

I did not need another classified ad. I needed a system for the whole roommate lifecycle: finding people, managing the household, and reducing the awkward manual coordination that happens when money and shared space are involved.

So I built RoomScout. It became a roommate marketplace and management platform because that was what I wished existed. I was not starting with a market map or a pitch deck. I was starting with a real house, real rooms, real bills, and a real need to make the situation less painful.

Team Bio

Team Bio came from a different kind of gap.

Remote work is great in a lot of ways, but it can make coworkers feel strangely flat. You might work with someone every week, trust their judgment, and still know almost nothing about them outside of tickets, meetings, and Slack messages.

When I joined a fully remote company, I felt that gap quickly. I wanted an easier way to understand who people were, what they cared about, where they were coming from, and what might make it easier to connect with them as actual people.

Team Bio was my attempt to build that missing layer. Profiles, trivia, coffee chats, and shared context were not features for the sake of features. They were answers to something I personally felt: remote teams need lightweight ways to build familiarity before every relationship has to be forced through another meeting.

ActionsUptime

ActionsUptime came from a recurring operational annoyance: I had a lot of projects, a lot of GitHub Actions, and not enough confidence that I would notice when something quietly failed.

Normal uptime monitoring tells you whether a site is reachable. That is useful, but it is not the whole picture. A project can look fine from the outside while deployments, scheduled jobs, tests, backups, or other automation are failing behind the scenes.

I wanted one place to see both service uptime and the health of the automation keeping those services moving. That became ActionsUptime.

The first version was not built because I thought monitoring was an untouched market. It was built because I had my own mess of repos and services, and I wanted fewer surprises. When a tool starts that way, the requirements are sharper. I did not need to guess whether the dashboard was useful. I knew whether it helped me catch failures faster.

Photonfolio

Photonfolio is the current version of this pattern.

My photo library keeps growing. Outdoor trips, hikes, family events, random experiments, and all the almost-good shots that pile up around the good ones. Managing that gets messy fast. Editing is one part. Sorting is another. Finding the right photo later is another. Sharing albums from a trip without turning it into a chore is another.

I wanted a system that could help me manage and edit that library, while also making it easy to share photos from outdoor trips in a way that felt clean and intentional. Not just dump a folder somewhere. Not just send a handful of compressed images in a chat. I wanted a place where the archive, the editing workflow, and the sharing experience could all fit together.

That is why Photonfolio exists. It is not abstract for me. I have the photos. I have the backlog. I have the trips I want to share. I know the pain of looking through too many similar shots and trying to turn them into something people can actually enjoy.

The pattern

The thread across all of these is pretty simple: I trust problems I have personally lived with.

That does not mean every personal annoyance should become a company. A lot of them should stay as scripts, notes, or tiny tools that make life easier. But when the same friction keeps coming back, and when the solution starts to feel useful beyond me, that is usually when I start taking it seriously.

Being your own first customer gives you a few advantages. You get immediate feedback. You can tell when the product is pretending to solve the problem versus actually solving it. You are less likely to get distracted by features that sound good but do not change the daily experience. You also have to face the uncomfortable question of whether you would use the product if nobody was watching.

That last part is important. It is easy to build something that looks like a product. It is harder to build something that earns its way into your own routine.

I keep coming back to this because it makes the work more honest. RoomScout had to help me manage a real house. Team Bio had to make remote work feel a little more human. ActionsUptime had to tell me when my own systems were failing. Photonfolio has to make my photo library easier to live with.

If I can make something useful enough for myself first, then I have a real starting point. Not a guarantee, but a starting point. And for me, that has always been the best place to build from.