homsy.ai

How claims are labeled

Working shipped & verified in the repo
Pilot / partial built but rough, gated, or incomplete
Design principle a rule the product follows, not a feature
Future intentionally not built yet
Homsy mascot waving
Early working pilot · deployed and tested end-to-end

A trust-first home operations companion.

Homsy helps homeowners understand what needs maintenance, when it should happen, and what to do next — while keeping every important action under their control.

Built end-to-end with AI assistance. The current pilot deliberately uses transparent, rule-based maintenance recommendations rather than black-box AI decisions.

01 · Story

Why I built Homsy

The idea started while reading an article that mentioned a home-maintenance task in passing. It made me realize I had no idea how often that task should actually happen — or what else around my house I might be quietly missing. The information existed, just fragmented — scattered across articles, manuals, regulations, supplier recommendations, old emails, and other people's memories. Coordinating individual suppliers (finding someone, explaining the job, requesting an appointment, following up) for every part of the house was its own separate frustration.

"What if I could describe my house once and receive a practical maintenance plan showing what needs attention and when?"
The first prototype was intentionally small:
  1. Describe the house and its equipment
  2. Generate a maintenance plan
  3. Add it to a calendar
  4. Receive reminders

A second motivation ran alongside it: understanding AI-assisted product development by completing the whole loop — idea → research → product definition → UX & visualization → architecture → implementation → testing → deployment → users — instead of isolated prompts. AI meaningfully shortened the distance from idea to working prototype; I still owned the product judgment, architecture, constraints, prioritization, review, and every final call.

Preview of the Homsy story: from a solar-maintenance article to a working, AI-built pilot.
A snapshot of the interactive version of this story — open it.

Homsy started as a tool for my own house. Talking to other homeowners about it made clear the friction wasn't just mine — not knowing what's required, losing service history, repeating coordination work for every recurring service. That suggests future opportunities, all still hypotheses, none shipped:

  • Prepared, ready-to-send supplier communication
  • Automatic follow-ups on outstanding requests
  • Recurring service workflows
  • Grouped service requests across similar homes
  • Coordination between nearby homeowners
  • Possibly better supplier availability or pricing through aggregated demand
All future — none implemented
Not just engineering

Name, brand, and visual identity

Alongside the code, I explored the Homsy name, a squirrel mascot and its personality, and the visual language — it made an otherwise invisible operational product approachable, and let me explore UX before writing a line of production code.

About the name

My kids sometimes call me 'veverka' — squirrel — because I love snacking on all kinds of nuts. Squirrels are famous for storing, sorting, and keeping track of what they've got — a fitting metaphor for a product about keeping track of a house. And "Homsy" itself leans on "Home."

Brand palette (from design/logo.svg / DESIGN.md)

The wordmark encodes the brand logic directly: forest-green "homsy" for trust and structure, lime ".ai" for accents. Status colors deliberately avoid red anywhere in the product — even a failed or declined state reads as calm gray, not alarm.

Autoplay teaser clip used on the real landing page (app/page.tsx).

02 · Product

How Homsy works

Walked through with a common Czech example: periodic inspection of an active flue path. The exact cleaning and inspection interval depends on the connected appliance, fuel, output, operating pattern, documentation, and applicable regulation — Homsy's shipped rule applies a 12-month default for any home with a chimney (§ 43 zákona č. 133/1985 Sb.; vyhláška č. 34/2016 Sb.), which is a reasonable baseline, not a substitute for checking your specific situation. Click a step.

Across every step: the homeowner can change recommendations, override intervals, nothing is sent without review, and communication is always draft-first.

03 · Build

Building it with AI

AI was central to how Homsy was researched, designed, implemented, tested, and iterated. It is not currently making live maintenance decisions inside the shipped product — that distinction matters enough to repeat throughout this page.

04 · Architecture

Architecture and integrations

The shape in one view: the homeowner uses Homsy, Homsy coordinates the workflow, a deterministic knowledge layer produces recommendations, house data stays in the homeowner's own Google Sheet, Neon holds only operational metadata, Gmail receives drafts only, the calendar connection is a one-way signed feed, and Slack is an internal ops notification — never homeowner-facing.

What changed from the original concept

Operational store: SQLite → Neon Postgres. The original architecture spec called the operational store "SQLite." The tech-stack spec explicitly supersedes that wording: Vercel's serverless functions have no persistent disk, so the operational store (OAuth tokens, sessions, scheduler state — never user content) moved to Neon Postgres via Drizzle. The trust-first contract didn't change: house data still lives only in the user's own Google Sheet.

Google Calendar OAuth → signed ICS feed. Early onboarding copy in DESIGN.md still lists "Google Calendar" as an initial connected service. The shipped architecture deliberately walked that back: Homsy requests no Calendar OAuth scope at all — a one-way, token-secured iCalendar feed instead. Fewer permissions requested, same reminder outcome.

Google Sign-in as the front door → waitlist as the front door. The original plan was "sign in with Google" on the landing page. Google's app-verification review for the restricted gmail.compose scope is a multi-week external process that hasn't started, so the public site leads with an email waitlist, keeping Google sign-in as a secondary link for already-added test users.

Integration flows

Three primary flows below; secondary ones under "More integration flows."

05 · Trust

AI should earn autonomy through trust

Homsy is designed to evolve gradually — from assistant, to supervised operator, to a more autonomous coordination layer — never skipping ahead of what's been demonstrated to be safe and predictable.

Designed to assist, not silently take control

Where your data actually goes

Tap a step to see exactly what crosses it, why, and what happens if it fails.

🤖 Future: AI provider (not connected today)
No homeowner data currently crosses into Claude, ChatGPT, or any other LLM API during product use. This node represents the planned AIKnowledgeProvider — a future, swappable implementation of the same interface the rule engine uses today. It is not live.

Trade-offs

06 · Current state

Current state and lessons

Homsy today — an intentional early pilot built for learning, not a finished product.

Becoming a real product

Validating Speed 1 with real homeowners is one track. The other is turning Homsy into something other people can find, sign up for, and use — in three rough phases.

Working hypothesis

Being able to lean on AI at every layer — research, spec-writing, code, ops troubleshooting — is what makes it realistic for one person to keep exploring multiple directions in parallel instead of picking one path and betting everything on it.

What I learned by building, not just reading

07 · Builder

About the builder

linkedin.com/in/vladimir-pindura

Homsy mascot head

I'm an engineering leader and hands-on product builder with more than 15 years in software engineering and over 10 years leading engineering and technical teams.

At Mews, I led distributed teams working across Connectivity, public APIs, integrations, Marketplace capabilities, and external technology partnerships.

Homsy brought me back into the complete product-building loop — from identifying the problem and designing the experience to architecture, implementation, deployment, and preparation for real users.

Homsy is ready enough to stop being only my experiment — and start learning from homeowners.

The next round of learning has to come from people who aren't me.