DEV Community: Kulsum

HomeKeeper OS: I Built a Home Maintenance App (and Tested It Before Shipping)

Kulsum — Wed, 05 Aug 2026 18:04:02 +0000

by Kulsum Shannan

Full disclosure: I currently intern at Perfai Security, the authorization and access control security testing platform mentioned later in this article. This isn't a sponsored post — I genuinely built this app as a personal project, and because I work at Perfai, I naturally used it as part of my release process. If you think either the app or Perfai could be improved, I'd genuinely appreciate your honest feedback.

Three Problems It Solves

Forgotten Home Maintenance
Most homeowners don't intentionally neglect maintenance — they simply forget. HomeKeeper automatically reminds you about recurring maintenance like replacing HVAC filters, cleaning dryer vents, testing smoke detectors, servicing appliances, and seasonal home care, before those tasks become expensive problems.

Household Knowledge Lives in One Person's Head
Every household has one person who somehow remembers everything: when the dishwasher was serviced, where the appliance manuals are, which contractor fixed the plumbing, what paint color was used. When that information isn't documented, everyone else starts from scratch. HomeKeeper turns that knowledge into something the entire household can safely access.

Home Information Is Scattered Everywhere
Receipts live in email. Warranty PDFs are buried in Downloads. Maintenance photos are somewhere in the camera roll. Calendar reminders disappear. HomeKeeper keeps everything connected — recurring schedules, maintenance history, appliance information, documents, photos, notes, and reminders, all in one place.

The App
HomeKeeper OS is a smart home maintenance and cleaning management platform that helps homeowners and families keep track of recurring chores, appliance care, repairs, and important home documents. The app provides automated reminders for tasks like replacing filters, cleaning appliances, seasonal maintenance, and inspections while creating a long-term history of everything done in a home.

Key Features:

Recurring cleaning and maintenance schedules
Smart notifications and reminders
Appliance tracking with warranties, manuals, and service history
Room-based organization
Maintenance history timeline
Task assignment and collaboration
Document and photo storage
Dashboard analytics for home upkeep

Roles:

Household Owner: Full control over the household, members, settings, and all data
Household Admin: Manages tasks, schedules, rooms, and maintenance records
Member: Completes assigned tasks, adds updates, and uploads photos
Guest: View-only access to shared information

The app is designed to become a digital memory for your home, helping users remember important maintenance tasks and preserve household knowledge over time.

Why I Built HomeKeeper OS
I started thinking about all the maintenance tasks people constantly forget around the house — not daily chores like taking out the trash, but the things that happen every few months, or even once a year. When did I last replace my HVAC filter? Have I cleaned the dryer vent recently? When should I flush the water heater? Did I ever replace the smoke detector batteries? Which paint color did we use in the guest bedroom? Where's the warranty for the dishwasher?

None of these are difficult. The problem is remembering them. Every reminder ends up in a different place — Notes, Google Calendar, sticky notes, emails, or simply forgotten.

I wanted one application that would become the memory of a home. Not another to-do list, but a system that remembers maintenance history, schedules recurring tasks automatically, stores manuals and warranty documents, keeps track of appliances, and lets family members collaborate without giving everyone full control. That's what became HomeKeeper OS.

How I Built It
Like a lot of people lately, I wanted to see how far modern AI development tools could go. Instead of building the application page by page, I started with a single detailed prompt inside Lovable. The prompt described the overall product vision, user workflows, a multi-tenant architecture, role-based permissions, recurring maintenance schedules, notification logic, dashboards, authentication, PostgreSQL database structure, Row Level Security, API endpoints, file uploads, and responsive UI.

From that single prompt, Lovable generated a surprisingly complete full-stack application. I then iterated on the generated code to refine workflows, improve the user experience, connect integrations, polish the interface, and make the authorization model behave consistently throughout the application.

By the end, HomeKeeper supported authentication, multiple households, Household Owners, Admins, Members, and Guests, recurring maintenance schedules, smart notifications, appliance management, document uploads, maintenance history, role-specific dashboards, and a multi-tenant PostgreSQL architecture. It looked and behaved like a real SaaS product.

The Part AI Builders Don't Solve
This post isn't really about HomeKeeper. It's about something I think many developers overlook.
Today it's incredibly easy to build software that looks production-ready. Modern AI builders like Lovable, Bolt, and v0 can generate polished dashboards, authentication flows, CRUD operations, and beautiful interfaces in hours instead of weeks. But none of that proves the application is actually secure.

A polished UI tells you nothing about whether someone can access another household's maintenance history, download documents they shouldn't see, modify someone else's recurring tasks, bypass role restrictions by calling the API directly, or access another tenant's data. Those problems don't usually appear during normal testing. Everything looks fine — until someone intentionally tries to break it.

Why I Tested It With Perfai
Since I intern at Perfai Security, using it as part of my release process was the obvious choice. I'm mentioning it because it's genuinely what I used, not because I'm trying to pretend I'm an unbiased third party.

After deploying HomeKeeper, I ran it through Perfai to test the live application. The goal wasn't to review my code — it was to test whether the authorization model actually held up against direct requests to the deployed app. That meant checking things like tenant isolation, role-based access control, ownership validation, API authorization, file permissions, broken access control, privilege escalation, and IDOR vulnerabilities. Those are exactly the kinds of problems that are difficult to notice by clicking around the UI.

The first scan came back with 5 critical access control issues — nothing that showed up in normal use, but real gaps that a determined user could have exploited: a couple of endpoints that didn't fully check household membership before returning data, and a role check that wasn't enforced consistently on the backend. I fixed each one directly in Lovable and reran the same scan. The second report came back clean, with zero issues remaining.

Whether you use Perfai or another tool, I think this kind of testing should become a normal part of shipping AI-generated applications. Building software quickly is becoming easy. Building software that's safe to hand to real users is still a separate job.

I'd Really Like Your Feedback
Developers are usually the toughest audience, and that's exactly why I'm sharing this here. I'd genuinely appreciate feedback in the comment section on two things:

HomeKeeper OS [https://homebase-recall.lovable.app] — Is this an application you'd actually use? What features feel unnecessary? What would make it genuinely useful over the long term?

Perfai [https://perfai.ai/] — Since I work there, I'm especially interested in hearing honest opinions. If the testing workflow, reports, or developer experience could be better, I'd love to hear it. Skeptical feedback is far more valuable than polite agreement.

I don't expect everyone to agree with my conclusions, but I'm hoping this project starts a conversation about what the "last mile" of AI-generated software should look like. Building an app is no longer the hard part. Knowing it's ready for real users still is.

HomeKeeper OS: I Built a Home Maintenance App (and Tested It Before Shipping)

Kulsum — Mon, 03 Aug 2026 17:57:31 +0000

by Kulsum Shannan

Three Problems It Solves

Forgotten Home Maintenance
Most homeowners don't intentionally neglect maintenance — they simply forget. HomeKeeper automatically reminds you about recurring maintenance like replacing HVAC filters, cleaning dryer vents, testing smoke detectors, servicing appliances, and seasonal home care, before those tasks become expensive problems.
Household Knowledge Lives in One Person's Head
Every household has one person who somehow remembers everything: when the dishwasher was serviced, where the appliance manuals are, which contractor fixed the plumbing, what paint color was used. When that information isn't documented, everyone else starts from scratch. HomeKeeper turns that knowledge into something the entire household can safely access.
Home Information Is Scattered Everywhere
Receipts live in email. Warranty PDFs are buried in Downloads. Maintenance photos are somewhere in the camera roll. Calendar reminders disappear. HomeKeeper keeps everything connected — recurring schedules, maintenance history, appliance information, documents, photos, notes, and reminders, all in one place.

Key Features:

Recurring cleaning and maintenance schedules
Smart notifications and reminders
Appliance tracking with warranties, manuals, and service history
Room-based organization
Maintenance history timeline
Task assignment and collaboration
Document and photo storage
Dashboard analytics for home upkeep

Roles:

Household Owner: Full control over the household, members, settings, and all data
Household Admin: Manages tasks, schedules, rooms, and maintenance records
Member: Completes assigned tasks, adds updates, and uploads photos
Guest: View-only access to shared information

The app is designed to become a digital memory for your home, helping users remember important maintenance tasks and preserve household knowledge over time.

None of these are difficult. The problem is remembering them. Every reminder ends up in a different place — Notes, Google Calendar, sticky notes, emails, or simply forgotten.

I'd Really Like Your Feedback
Developers are usually the toughest audience, and that's exactly why I'm sharing this here. I'd genuinely appreciate feedback in the comment section on two things:

HomeKeeper OS [https://homebase-recall.lovable.app] — Is this an application you'd actually use? What features feel unnecessary? What would make it genuinely useful over the long term?
Perfai [https://perfai.ai/] — Since I work there, I'm especially interested in hearing honest opinions. If the testing workflow, reports, or developer experience could be better, I'd love to hear it. Skeptical feedback is far more valuable than polite agreement.

GardenOS: A Garden That Remembers (Prelaunch best practices)

Kulsum — Thu, 30 Jul 2026 17:34:49 +0000

_by Kulsum Shannan

_Disclosure: I intern at Perfai Security, the tool used for the security testing described below. But I want to be upfront about something else too: GardenOS wasn't built to test Perfai. I built it because I actually wanted this app to exist. The security testing came after, because I cared about the product enough to want it to be safe.

Why I Built This
I garden on and off, and every year I lose track of what I planted, when I watered it, and what actually worked from one season to the next. Notes end up scattered across notebooks, phone photos, or nowhere at all, and by the next spring most of it is forgotten.

I wanted one place where a garden's history sticks around instead of resetting every spring: every plant's care history, journal entries, and harvests kept in a continuous record. I also wanted a way for family or a helper to check in on the garden without risking someone logging a task wrong or deleting a plant record I'd spent a season building. That's what became GardenOS: a role-based garden platform where an Owner holds real authority, an Admin can manage day-to-day without full access control, a Gardener can log care and add journal entries, and a Viewer gets visibility without any risk to the data.

I built it with Lovable, starting from one long, detailed prompt covering the product, the roles, the pages, the workflows, and the technical architecture. It came together fast, and by the end of the process it looked like a real, finished product. Accounts worked, dashboards were role-specific, data persisted, and it was live at a public URL.
That's usually where the story of a vibe-coded app ends. This post is about why it shouldn't be.

The Point of This Post
I'm not writing this just to talk about GardenOS. I'm writing it because I think a lot of people building with AI app builders right now, tools like Lovable, Bolt, and v0, are stopping at the same point I almost did: the app runs, it looks polished, it demos well, so it must be done.
It isn't. And the gap between "this app works" and "this app is safe to put real users' data into" is not something these tools check for you. That gap is the actual subject of this post.

What "Published" Actually Proves
Publishing GardenOS took a few clicks. Lovable generated a live URL, and from that point on, anyone could visit the app, sign up, and use it.

But here's what that step does not prove:

That the authorization model holds up under direct requests to the backend, not just clicks in the UI
That a Viewer on one garden has no path, intentional or accidental, to reach data belonging to a garden they aren't part of
That someone can't reach another user's private plant records or journal entries by manipulating a request
That authentication endpoints are resistant to abuse

None of this shows up when you're using the app normally. The dashboards look properly separated. The role restrictions look like they're working: buttons are hidden, pages redirect where they should. That's exactly what makes this gap dangerous: everything looks fine from the front end, which is the only view most builders ever check.

Role logic in particular is deceptive. Getting Owner, Admin, Gardener, and Viewer permissions to behave consistently across gardens, plants, tasks, and journal entries took more iteration than any single feature in the entire build. Hiding a button in the UI is trivial. Making sure that restriction actually holds everywhere the underlying data is touched, every API call, every database query, is a completely different problem, and it's not one that "the app works when I click around it" can answer.

Why I Tested It Anyway (and Why You Should Too)
Before treating GardenOS as release-ready, I ran the live deployment through Perfai Security. I want to be clear about what that step was and wasn't:

It wasn't a rebuild. It wasn't a second development phase. It was a release check, the same category of thing as confirming the app works on mobile, that environment variables are configured correctly, or that error states behave the way they should. Perfai tested the deployed application directly: it mapped the app's accessible functionality, roles, routes, and requests, and then tested each of those for weaknesses, rather than just reviewing the source code or the interface Lovable generated.

The first scan found 0 critical issues and 11 medium issues.
I’m glad that there were no critical issues. There were a few medium issues, but when I looked through them they didn’t seem too important. It was a good practice to run my app so I can be confident that my app is ready. There have been times when the Perfai results show many critical issues.The design was polished. The dashboards were separated by role. Authentication existed and worked. Every normal flow I tried behaved exactly as expected. If I had stopped at "it works when I use it," I would have shipped an app with 8 critical authorization problems and had no way of knowing it.
I fixed the issues and ran the scan again. That second pass came back clean.

The Actual Takeaway
Lovable did exactly what I asked it to do, and it did it fast. Turning a long, detailed product spec into a working, full-stack application is genuinely impressive, and I don't think that capability should be undersold. But building the product and confirming it's safe to release are two separate jobs, and only one of them is something a vibe-coding tool does for you.

If you're building anything that touches accounts, roles, permissions, or other people's data, which is most real products, "it's published and it works" is not the same claim as "it's safe to hand this to real users." Making sure it doesn't leak data, doesn't let one user reach another user's records, and doesn't have an authorization model that only exists in the UI is a distinct step. It has to happen after the build, against the live deployment, not just by reading the code or clicking through the demo.

Security testing isn't a replacement for building the product, and it shouldn't overshadow it either; the product still has to be worth using. But it is one of the checks required before anything handling accounts, permissions, and personal records can reasonably be called ready. I used Perfai because I intern there and it's the tool I know best, but the underlying point holds regardless of which tool you use: run something against the live, deployed version of your app that actually tries to break the authorization model, before you call it done.

Try GardenOS:
I'd genuinely appreciate your feedback, both on the app itself, and on whether this changed how you'll think about the "last step" before shipping something you built with an AI app builder.

I Vibe-Coded a Full-Stack Group Travel Planner in a Weekend — Then Found 8 Critical Security Issues

Kulsum — Wed, 29 Jul 2026 05:29:09 +0000

I built TripNest, a role-based group travel planner (Owner/Editor/Viewer permissions, itinerary planning, packing lists, group messaging) in a single weekend using Lovable. It looked release-ready by Sunday night. A free security scan found 8 critical issues before I ever pushed it live to real users.

🔗 Try it:

The Problem

I take a lot of short trips with family and friends — mostly road trips on holidays — and organizing them is always a mess:

Fragmented info — itineraries live in someone's Notes app, flights get shared as screenshots buried in a 200-message group chat, no single source of truth.
No safe way to share control — the person who did the planning has no way to let others view the plan without risking someone accidentally deleting a hotel booking or changing dates.
Trip chat lost in the noise — trip-related decisions get buried in unrelated group chat messages.

TripNest solves this with one space and a proper permission model.

How It Works: 3 Roles
Admins — the source of truth. Add/remove participants and planners.
Planners — can shape the itinerary without admin-level control (good for the friend handling activities, not the whole trip).
Participants — visibility without risk. Follow along, no ability to change dates or delete flights.

Core features: trip creation, role-based invites (with accept-before-join), collaborative day-by-day itinerary, flight info storage, packing lists, and a dedicated group message thread per trip.

Tech Stack
Lovable (initial build + iteration)
React + TypeScript
Tailwind CSS
Supabase (Auth + PostgreSQL)
Google Maps + OpenWeather (location/weather data)
Perfai Security (free access-control testing)
Building It

I started with one long, detailed prompt covering the product, users, pages, visual direction, workflows, and technical expectations — front-loading detail so Lovable could build a connected first version instead of screen-by-screen guesswork. That first pass nailed the design system (consistent typography, spacing, cards, buttons, forms), but it wasn't a finished product. I spent the rest of the weekend iterating: wiring components together, fixing edge cases, and adding features as I thought of them.

Challenges
Limited Lovable credits — every prompt draws from a chat budget, so vague prompts were expensive. I had to batch related changes and think through exactly what I wanted before sending a message.
Role logic across features — getting Owner/Editor/Viewer permissions to hold consistently across trips, itineraries, packing lists, and messaging took way more iteration than any single feature.
Sharing with non-users — inviting someone without a TripNest account initially just failed. Email invites needed a custom domain (which costs money), so I shipped a copy-link share feature instead.
"Published" ≠ "Ready to Release"

By Sunday, TripNest was a fully functional prototype — accounts, role-specific dashboards, persisted data, and a live published URL from Lovable. It looked done.

But publishing only proves the app runs. It doesn't prove the authorization model holds up under direct requests, that sensitive data can't be reached outside the intended UI, or that auth endpoints resist abuse.

So before calling it release-ready, I ran the live deployment through Perfai Security — not a code review, an actual test of the deployed app: mapping accessible routes, roles, and requests, then probing for weaknesses.

Result: 8 critical issues. None of them were visible from using the app normally — the UI looked polished, dashboards were properly separated, auth worked, normal flows worked fine. After fixing them, a second scan came back clean.

Takeaway
Lovable turned a detailed spec into a working app in a weekend — genuinely impressive. But "vibe-coded and published" isn't the same as "safe to hand real user data to." A security pass isn't a replacement for building the product, and it's not optional once you're handling accounts, permissions, and personal records — it's just part of the release checklist, same as checking mobile responsiveness or environment configs.

This is the prompt I used to build TripNest:

TripNest – Collaborative Travel Planner

Prompt I Used to make TripNest
Overview
Build a modern travel planning web app where users can create trips, collaborate with friends, build itineraries, upload travel documents, and receive travel recommendations.

Tech Stack
React
TypeScript
Tailwind CSS
Supabase (Auth + PostgreSQL)
APIs
Google Maps API – Maps and destination search
OpenWeather API – Weather forecasts
Amadeus API – Flight and hotel search
Authentication
Sign Up
Login
Forgot Password
Logout
Roles
Traveler: Manage their own trips and invite collaborators
Moderator: Moderate public content
Admin: Manage users and access the admin dashboard
Features
Dashboard
Trip CRUD
Shared itineraries
Search & filtering
File uploads
Notifications
Public & private trips
Database
Users
Trips
Trip Members
Itineraries
Comments
Notifications
Uploaded Files
Security
Role-based access control
Secure API authorization
Supabase Row Level Security (RLS)
Prevent unauthorized access, edits, file downloads, IDOR, and privilege escalation
Goal
Build a production-ready collaborative travel planner with multiple users, shared resources, CRUD operations, external API integrations, and secure authentication and authorization.