There is a strange problem with everyday organisation.

The information is rarely missing.

It is just scattered everywhere.

One reminder is in a calendar.
The grocery list is in a messaging app.
A household task was mentioned verbally and forgotten.
An upcoming trip is saved somewhere else.
Someone paid for dinner, but nobody remembers who owes what.
A recipe looks good, but its ingredients never make it onto the shopping list.

I wanted to see what would happen if all of those small pieces of daily coordination lived in one private place.

That became this project: a shared household Progressive Web App built with React, Vite, Supabase and Netlify.

It is designed for a small private group to organise daily life together, with changes synchronised between devices in real time.

One Shared Space

The starting point is a private shared space.

Each person has their own account, but members can join the same space using an invite code.

A space currently supports up to six people.

Once inside, everyone works from the same shared information.

If one person adds a grocery item, completes a task or sends a message, the update appears on the other connected devices almost immediately.

That real-time behaviour was important.

A shared organiser becomes frustrating very quickly if one person is looking at stale information.

The application therefore uses Supabase's real-time capabilities throughout rather than treating synchronisation as an occasional refresh.

The Calendar Became the Centre

The calendar is where much of the application comes together.

It supports:

  • Day view
  • Week view
  • Month view

Tasks can contain considerably more than a title.

A task may include a time, notes, priority, tags, a checklist, a colour and an icon.

There are 12 colours and 24 icons available, which makes it possible to visually distinguish different kinds of activities without creating an overly complicated category system.

Tasks can also be assigned to a specific person.

That sounds like a small feature, but assignment changes the calendar from:

"Something needs to be done."

to:

"We know who is handling it."

For shared planning, that distinction matters.

Repeating Life Requires Repeating Tasks

A large percentage of daily life repeats.

Cleaning.

Exercise.

Appointments.

Bills.

Weekly shopping.

Regular household jobs.

So recurrence needed to be a first-class feature rather than something added later.

Tasks can repeat:

daily · weekly · monthly

and recurrence intervals can also be adjusted.

That allows patterns such as every week, every two weeks or every few months.

Editing recurring events also introduces a familiar but important decision:

Change only this occurrence, or this occurrence and everything after it?

The same logic applies when deleting recurring items.

Supporting that properly was one of those areas where a seemingly simple calendar feature becomes much more complex once real usage is considered.

Faster Than Opening a Form

Not every task deserves a multi-field form.

Sometimes I just want to write:

gym every monday at 7am

and move on.

So the app includes a natural-language quick-add system that interprets simple phrases and converts them into structured tasks.

It is not trying to understand unrestricted language.

It solves a narrower problem:

turn common scheduling phrases into dates, times and recurrence rules quickly.

This is one of my favourite kinds of automation because the benefit is immediately measurable.

It removes taps.

Tasks Have a Memory

Shared systems have another problem.

Something changes and the obvious question becomes:

Who changed it?

Tasks therefore include a change history.

The application can record who performed certain actions, providing useful context when several people are working inside the same space.

Items can also be reordered through drag-and-drop.

And deleting something is not immediately final.

An undo option gives the user a short opportunity to restore an accidentally deleted item.

None of these features is individually dramatic.

Together, however, they make the application feel much safer and more practical during everyday use.

A Grocery List That Understands the Shop

The shopping section started as a basic shared grocery list.

It did not stay basic for long.

Items can contain:

  • Quantity
  • Notes
  • Completion state

But the more interesting part is how they are organised.

Items are automatically grouped by aisle.

Instead of walking through a shop with an arbitrary list like:

milk
apples
detergent
bread
chicken

the interface groups related products together.

Aisles themselves can also be reordered to match the way a particular shop is laid out.

That means the list can gradually match the actual path someone takes through the supermarket.

Checked items are not lost either.

They can be re-added later, which is useful for products purchased regularly.

The grocery list became less about remembering items and more about reducing friction while shopping.

Chat Without Leaving the App

There is also a built-in real-time chat.

The goal was not to compete with dedicated messaging platforms.

It exists because some conversations belong directly alongside the shared information.

Messages appear with avatars and day dividers, and new messages arrive in real time.

Keeping chat inside the same shared space also means there is less context switching between planning something and discussing it.

The Part Called "More"

Eventually there were features that did not naturally belong in the calendar, chat or shopping views.

Rather than crowding the main navigation, they became part of a More hub.

This is where several smaller tools live.

Stats

The statistics area looks at shared activity over time.

It includes things such as:

  • Streaks
  • Weekly activity balance
  • Reusable chore templates

The goal is not to turn household tasks into a competition.

It is simply another way to understand how recurring work is distributed and whether routines are being maintained.

Expenses

There is also a lightweight shared expense tracker.

Its main job is answering one question:

Who owes whom?

For a small household app, I did not need full accounting software.

The useful part is simply having shared expenses recorded in the same place as the rest of the household information.

Countdowns

Some events do not need to occupy the calendar every day, but they are still worth keeping visible.

Countdowns can be created for things such as:

  • Trips
  • Anniversaries
  • Important events
  • Personal milestones

It gives future events a different type of presence from ordinary calendar entries.

Meal Planning

The meal planner connects another part of household organisation directly to shopping.

Meals and recipes can be planned, and recipe ingredients can then be added automatically to the Shop list.

This is an example of a feature I enjoy building because two separate tools become significantly more useful once they communicate with each other.

A meal planner knows what ingredients are needed.

A shopping list knows what needs to be bought.

Connecting them removes an unnecessary manual step.

Building Connections Between Features

That became one of the main themes of the project.

The interesting part was not simply adding:

calendar + shopping + chat + meals + expenses.

It was finding useful relationships between them.

For example:

Recipe → Ingredients → Shopping list

or:

Recurring task → Assignment → Calendar → Activity history

The individual modules are useful.

The connections between them make the application feel like one system rather than several small apps placed beside each other.

Privacy Had to Be Part of the Architecture

A shared household application naturally contains information that should remain private.

So access control is enforced using Supabase Row Level Security across the database.

Users authenticate individually and only gain access to data belonging to spaces they are authorised to join.

That distinction matters.

Security should not depend on the frontend simply choosing not to display someone else's records.

The database itself should reject unauthorised access.

I also added an optional PIN app lock for another layer of protection on the device.

For an application centred around everyday personal information, privacy cannot be an afterthought.

Notifications

Push notification support is also built into the application.

This is important for tasks because an organiser becomes significantly more useful when it can actively remind someone rather than requiring them to open the application repeatedly.

The notification infrastructure is implemented, while the remaining deployment configuration can be activated separately.

I deliberately treated notification support as part of the architecture rather than tying the whole application to it.

The core system remains usable even without push enabled.

Designed as an Installable Web App

The application is a Progressive Web App.

That means it can be installed to the home screen and opened in an app-like environment without maintaining separate Android and iOS codebases.

This architecture has become particularly useful for my private applications.

The stack remains relatively compact:

React + Vite for the frontend
Supabase for authentication, database and real-time functionality
Netlify for deployment

One codebase can serve phones, tablets and desktops while still behaving like an installed application on supported devices.

Real-Time Changes the Experience

One technical feature has a much larger impact on usability than it might initially seem:

real-time synchronisation.

Suppose one person is shopping while another person is at home.

An item is added to the list.

A second or two later, it appears on the other phone.

Or someone completes a household task.

The other device reflects the change without needing a refresh.

This makes the application feel genuinely shared.

Without it, the system would really be two people looking at separate cached versions of the same database.

Real-time updates turn it into a common workspace.

Where the Project Reached

The application has now reached the point where the major systems are built:

authentication, shared spaces, calendars, recurrence, assignments, shopping, chat, expenses, meal planning, countdowns, statistics, security and real-time synchronisation.

The most recent development work focused less on adding visible features and more on making sure the underlying database and recurring-task system behave correctly from end to end.

That is an important stage in a project.

There comes a point where another feature is less valuable than proving that all the existing pieces work reliably together.

The next step is therefore straightforward:

use it.

Create recurring tasks.

Add groceries during the week.

Plan meals.

Record expenses.

Move between two devices.

See where the workflow feels natural and where it creates friction.

Because the biggest question is no longer:

Can I build all of these features?

It is:

Can they make everyday coordination easier?

That is the question real use will answer.