Family Command Center

What it is

A private, self-hosted web application that runs a household: shared responsibilities, planning, money and a set of optional modules, on one server in the house, with nothing leaving it.

It is genuinely in daily use. It is not a product anyone can download today.

Structural figures on this page were measured on 31 August 2026.

The problem — one household, very different users

Building the features was never the hard part. Chores, a planner, savings goals — none of that is difficult.

The hard part is that a household is not a group of similar users. Some people need full detail, projections and history. Some need three big buttons and plain numbers. Some can barely read. The same system has to serve all of them, and it has to keep working when someone’s needs change — which they do, continuously, and never on a release schedule.

The obvious approach is to build a different screen per person. That works for about a month, and then every new feature has to be written several times and the versions quietly drift apart.

Roles and levels, not one interface

The alternative is to make difference a configuration value rather than a code path.

Two things are set per profile: a role, and a complexity level. The shipped catalogue has seven levels — from a pre-reading tier through progressively fuller ones up to full detail, plus adult and administrative tiers — and sixteen module types covering areas like tasks, planning, money, goals, approvals, appointments and household admin.

Each profile gets its own combination: which modules are switched on, and at what level of complexity each one renders. A profile with no explicit setting falls back to the module’s catalogue default, so the system does not need a row for every person against every module to work.

Generic architecture. No real profiles, counts or household data are represented here.

Configuration, not branching

The rule the module system is built to enforce is blunt: never a conditional on who someone is.

A module’s renderer reads the complexity level and gates which sections appear, working from one shared component tree — rather than maintaining a separate page file per person that has to be updated several times for every change. Enabling a module for someone, or moving them up a level as they grow into it, is a row in a settings table edited through the admin screen. No code change, no deploy.

That is the whole design, and it is what makes the system survive people changing.

Where that rule is not kept yet

It is worth being exact about this, because it is the honest state and it directly shapes what happens next.

The newer module system follows the rule. Parts of the older application do not: some routes and components still encode assumptions about specific individuals rather than resolving everything from configuration. This is recorded as technical debt in the project’s own documentation — there is an explicit checklist for new modules stating the rule, and a written inventory of which parts are configuration-driven and which are still legacy.

It is not a defect that broke something. It is the ordinary residue of building the specific thing first and generalising afterwards. But it is precisely why the current application cannot simply be published: removing those person-specific assumptions is a prerequisite, not a tidy-up.

Identity without passwords on a shared household device

Asking a young child to remember a password is a good way to guarantee they never use the system.

The current model resolves identity from context: on a trusted device inside the house, each person has their own area, and who you are is derived from where you are rather than from something typed in. The profile is always resolved server-side, never taken from submitted form data. Adult and administrative screens sit behind a PIN, stored as a salted scrypt hash and compared in constant time.

This is a reasonable model for a trusted household network, which is the only context it currently runs in. It is deliberately not being presented as a general answer: a public version used by households other than mine would need its authentication revisited properly, and that is on the list below rather than assumed solved.

A deliberately separate, non-monetary pattern

One design decision is worth stating on its own, because it is the kind of thing that is easy to get wrong.

Not every desirable activity in a household should be turned into points, money or competition. Some things are worth doing regardless, and attaching a reward to them changes what they mean. So a category of activities exists that is deliberately non-punitive and non-monetary — outside the rewards economy entirely, running on the same underlying mechanics but with no score attached and nothing to earn.

Building a household system makes the pull toward gamifying everything very obvious. Deciding where to stop is a product decision, not a technical one.

Privacy as the deployment model

It runs on a server in the house. There are no bank integrations, no external APIs, no AI services and no cloud account. Household data does not leave the building, because there is nowhere for it to go.

That is not a feature list — it is the deployment model, and it is the reason the architecture looks the way it does.

Built in stages

91 numbered decision records and 37 development checkpoints as of 31 August 2026. Each stage records what was decided, what was rejected and what was deployed. Several of those records exist specifically because something only failed once it was running against the real system rather than a local build.

What isn’t here

• No automated test suite. Verification today is framework type-checking, a clean build, staged delivery and manual verification against the running system. The other projects on this site lead with test counts; this one has none, and pretending otherwise would be worse than saying it. It is the single largest gap.
• No proper version-control history on the current instance.
• Legacy person-specific assumptions, as described above.

All three are the same category of thing: consequences of building for one household first. All three have to be resolved before any of it could be useful to anyone else.

From private household system to open source

The interesting part of this project is not my household. It is the architecture: role and complexity as configuration, a module catalogue, one shared component tree, self-hosted and local-first. That part is not personal, and the next development direction is to extract it into an open-source, self-hosted household platform other families could configure for themselves.

None of that exists publicly yet. There is no repository, no release, no installation package and no one else using it.

The rule governing how it gets built is already fixed, because getting it wrong cannot be undone:

The private household instance is evidence for the product. It is never the product that gets published.

The public version will not be made by opening the current project, nor by copying it and deleting names. Privacy-sensitive information is not only in the content — it is in the seed data, the routes, the profile mappings and the structure itself. The public core has to be extracted and rebuilt around generic configuration, with a completely synthetic demo household, and without inheriting the private commit history.

The immediate next step is not building it. It is an audit: what is genuinely generic, what carries household-specific assumptions, what authentication model a public version actually needs, and what test baseline has to exist before any release. The scope of a first version comes out of that audit, not out of this page.

What it is not

• Not surveillance, monitoring or parental-control software. It coordinates a household; it does not watch anyone.
• Not a scoring system for people. The wellbeing pattern above exists precisely because not everything should be scored.
• Not a SaaS or a hosted service. There is no account, no server of mine holding anyone’s data, and nothing uploaded.
• Not open source today, and not available to install. That is a direction, not a status.
• Not a replacement for judgement. It is scaffolding for a household’s own decisions.

Where it stands

Real, private, self-hosted, actively developed and in daily use for one household. Limited today by legacy person-specific assumptions and the absence of automated tests — both known, both recorded, both blocking anything public.

The next chapter is the extraction audit. When there is genuinely a repository to look at, this page will say so and link to it.