Building Homier

I spent a decade at Zillow thinking about real estate. I’ve rented my own house on Airbnb when I’m out of town. I’ve always been drawn to the space where real estate meets community, the idea that your home can do more than just sit there when you’re not using it.

There’s a tension I keep seeing. Stunning homes that sit empty most of the year. The people who own them want to bring more life into those places, get more utility out of them, share them with the people they care about. But the logistics get in the way. Group texts, Google Calendar links, spreadsheets, email threads. The friction of coordinating who’s going when is enough to make people just not bother. And the alternative, listing on Airbnb or VRBO, turns your home into a business. That’s a different thing entirely.

I have a strong belief that this is basically a friction problem. The homes are there. The people who’d use them are there. The tools just make it too hard to connect the two. A purpose-built tool for private sharing doesn’t just simplify the organization. It increases the vibrancy of a home that someone cherishes.

That’s Homier. Private, invite-only vacation home sharing for people who already trust each other. No public listings. No strangers. One place for the calendar, booking requests, house details, and co-owner coordination.

Why this couldn’t exist before

The economics of Homier make sense for me as an individual builder. They probably don’t make sense as a venture-funded company. The market is real but niche. The revenue per user is small. The complexity is high enough that you’d need a real engineering team if you were doing it the traditional way.

That combination, real need but not VC-scale, used to mean the software just didn’t get built. Nobody was going to raise $5M to build a private home-sharing coordinator for families. But with Claude Code and the current generation of AI tools, I can build and maintain it myself. The cost structure is totally different when one person can do the work.

I think there’s a whole class of software like this. Products that serve real needs, that people will pay for, but that don’t fit the venture model. The tools are making it possible for individual builders to go after these spaces. Homier is my bet on that idea.

Starting in Cursor

I started building in early 2025 using Cursor. The first few weeks felt fast.

I could describe what I wanted and get working code back quickly. I got a basic prototype up, authentication working, some initial pages rendering.

But as the codebase grew, things started to slow down. Cursor would lose context on the project structure. I’d get suggestions that conflicted with patterns I’d already established. The more complex the app got, the more time I spent correcting the AI instead of building with it. By the time I had a few thousand lines of code across multiple services, the experience had degraded enough that I was spending more time fighting the tool than using it.

Switching to Claude Code

I switched to Claude Code around June 2025, and the difference was pretty immediate. Claude Code operates on the full codebase. It reads your files, understands how things connect, and makes changes that are consistent with what’s already there. The context window problem that was killing me in Cursor basically went away.

More importantly, Claude Code helped me fix the mess I’d made. I’d introduced a lot of bugs and architectural issues during the Cursor phase. Things that worked in isolation but broke when they interacted. Claude Code was able to trace through the codebase, identify where the patterns were inconsistent, and help me refactor into something more maintainable.

Over the rest of 2025, the updates to Claude Code kept making things better. Better context handling, better tool use, better ability to work across files. Each improvement compounded because my codebase was growing at the same time.

Learning everything the hard way

I’m a data scientist. I have a reasonable mental model of backend systems. Databases, APIs, cloud infrastructure, that kind of thing is adjacent enough to my day job that it felt challenging but intuitive.

Frontend was a completely different story. CSS, React components, layout architecture, responsive design, how to organize a component library. I had basically no foundation for any of it. I went through a ridiculous number of iterations on the frontend, trying different approaches to component organization, wasting time on patterns that didn’t scale, rebuilding things I’d just built.

But I learned a ridiculous amount. TypeScript, CI/CD pipelines, Firebase Cloud Functions, Firestore indexes and security rules, testing patterns, deployment workflows. All things I never knew I needed to know in order to ship a real web application. Every one of them felt like a wall until I got past it, and then it felt obvious in hindsight.

Where things are now

The codebase is in a pretty clean state at this point. I can add features quickly. The architecture supports rapid iteration in a way that the early versions absolutely did not. The speed of going from idea to shipped feature is kind of amazing compared to where I started.

The product itself is live at livehomier.com. I wrote more about what it does and why it exists in this post announcing the launch. You can set up a property, invite the people you trust, and they can check dates and request stays. There’s co-owner management for shared properties, a co-stay feature for booking rooms when other people are already at the house, and house guides so guests know the wifi password without texting you.

It’s $4.99/month per property. Guests use it for free. I priced it that way because I wanted the incentive structure to encourage sharing. The more people an owner invites, the more useful the platform becomes for everyone.

The bigger idea

I keep coming back to this: Homier exists because the tools changed. A year ago, building something this complex as a side project would have been either impossible or would have taken years. The AI tooling compressed that timeline enough to make it viable for one person.

And that means there are probably a lot of products like this waiting to be built. Real needs, real willingness to pay, but not enough market size to justify a traditional startup. Individual builders can go after these now. That’s basically why I did it.