Anchor

Inspiration

This idea came from something I saw in my own life.

Nine years ago, my friend's 40-year-old working mother was caring for an aging parent while also raising two children. Doctors, hospitals, and care services were already involved. The hard part was everything around the care.

Aid renewals. Missing documents. Diapers. Medication supplies. Hospital visits. Paperwork deadlines. Information scattered across WhatsApp, paper folders, calendars, and memory.

The person she cared for passed away six years ago but if I could go back, I wish I could have built something like Anchor for her mother without burn out.

Anchor came from that feeling: caregiving often becomes an operations job, but families are expected to manage it without an operating system.

What it does

Anchor helps family caregivers manage the operational side of caring for aging or dependent parents.

The app lets a caregiver switch between care recipients, such as Rose and Charlie, and track what each person needs. Anchor currently supports aid programs, required documents, recurring supplies, and hospital visit checklists.

Instead of showing one long list, Anchor surfaces the three most important actions for the selected care recipient this week. That might be an aid renewal due soon, missing documents for an application, a supply item running low, or an incomplete hospital checklist.

Caregivers can add, edit, and delete aid programs, supplies, documents, and checklist items. They can also mark supplies as restocked and toggle documents or checklist items as complete.

Anchor does not provide medical advice, diagnosis, or treatment recommendations. It does not use AI to make healthcare decisions. Its goal is simpler: reduce decision fatigue and help caregivers stay ahead of critical responsibilities.

How I built it

Anchor was built with Next.js, React, TypeScript, Tailwind CSS, Vercel, v0, and Amazon Aurora PostgreSQL.

I used v0 to quickly prototype and improve the mobile-first interface, then built the app around real caregiving workflows: dashboard, recipient switching, aid programs, supplies, and hospital visit preparation.

The backend uses a relational PostgreSQL data model. Users, care recipients, aid programs, required documents, supplies, checklists, and checklist items are stored as connected tables. This structure matters because Anchor’s main feature depends on relationships between those records.

The core technical feature is a PostgreSQL view called priority_feed. It combines data from multiple tables and ranks caregiving priorities using deterministic SQL rules, including:

aid renewal deadlines
missing required document counts
supply countdowns
checklist completion

I chose Aurora PostgreSQL because Anchor needs relational structure, joins, indexes, and flexible schema changes. During development, the product changed a lot. I added editable workflows, multiple care recipients, and new priority logic, and PostgreSQL made it easier to adjust tables and relationships as the app became clearer.

Aurora is not just storing data for Anchor. The database helps produce the product experience by deciding what the caregiver should see first.

Challenges I ran into

The biggest challenge was deciding what not to build.

Caregiving is a large problem space. I considered appointments, medication reminders, document uploads, family sharing, notifications, care center messaging, and aid discovery. Building all of that would have made the app wider but weaker.

For this version, I focused on the operational tasks that felt most important for a caregiver demo: aid renewals, document readiness, recurring supplies, multiple care recipients, and hospital visit preparation.

Another challenge was technical. This was my first time working with this kind of full-stack setup, including Vercel, v0, AWS, and Aurora PostgreSQL. The integration between v0, Vercel, and AWS helped me move faster than I expected as a beginner. It also made AWS feel less intimidating and made me want to understand the infrastructure more deeply.

I also had to keep the experience simple. A caregiver using Anchor may already be tired, busy, and not very technical. That affected product decisions like using “Caring for Rose” instead of technical language like project, workspace, or entity.

Accomplishments that I'm proud of

I am proud that Anchor starts from a real caregiving problem instead of starting from technology and searching for a use case.

I am also proud of reframing caregiving as operational coordination. Anchor does not try to replace doctors or care providers. It focuses on the invisible admin work that family caregivers often carry alone.

The strongest part of Anchor is the database-driven priority feed. It turns normal caregiving records into a short list of urgent actions, so the caregiver does not have to mentally sort through everything at once.

I am also proud that, with v0, Vercel, and AWS, I could build something much more complete than I expected for my first hackathon. Anchor now feels like a working product that I would want to keep improving and eventually share with people who need this kind of support.

What I learned

This project taught me how much hidden coordination work family caregivers perform every day.

I learned that the problem is not only remembering information. The harder problem is knowing which responsibility matters first when everything feels urgent.

Technically, I learned why relational database design matters. Anchor’s core feature depends on joins between care recipients, aid programs, required documents, supplies, and checklists. PostgreSQL views and indexes helped me think beyond storing form data and toward building product behavior from the database model.

I also learned how important scope is. A focused caregiving tool with fewer features can be more useful than a large app that tries to solve every caregiving problem at once.