flightpack/clients and flightpack/people: who the work is for, who did it

Two small packages that other packages lean on: client companies with users who can only look, and team members with a public profile and a byline.

Two of the thirteen packages are small enough to read in an afternoon, and both are load-bearing. flightpack/clients arrived on 14 October 2026 and flightpack/people on 16 October. Between them they answer the two questions every project tool eventually meets: who is this work for, and who did it.

clients: companies, and users who can only look

A client is a company with a name, a logo, a registration number that must be unique among live clients, contact details and an active flag. Deleting is a soft delete, and a client that still has users cannot be deleted. It is shaped like a contractor or vendor record.

The interesting part is how a person becomes a client user. An administrator assigns a guest to a client, and the guest role is swapped for the client role. Remove the last assignment and the person goes back to guest. One person can belong to several clients. Accounts that hold any other role are refused, because staff are added to projects directly.

guest --assign to client--> client role (read only)
client role --last assignment removed--> guest
staff role --assign to client--> refused

• Invite: from a client page an administrator can invite someone with no account yet. The account is created through the core registration service and the person receives a welcome message and a password reset link.
• My company: a client user gets one read-only page about their own company.
• Events: the package fires an event when a user is assigned or removed, so other packages can react without clients knowing they exist.
• Cards: a dashboard card with a share ring for active clients, a bar of clients with and without users, and a ranked list of the clients with most users.

It needs nothing but the core. The projects package detects it: a project can be linked to a client, and the client's users see that project read only. Billing uses the same link to decide who an invoice is addressed to.

people: a team page that other packages sign with

A team member has a photo, a short and a long biography, social links and a slug. Only active members appear on the public team list. Order is set with arrows in the panel, and the list renumbers every member so the order has no gaps. A GIF avatar is accepted, animated ones included, which is why our own team page can have a goblin that moves.

The slug is the part that grew the most. On 24 October a member gained a slug as the address of their public profile. A member created without one gets one made from the name, whoever creates them, and an edit that renames a person keeps the slug, so a link someone shared does not break. A hotfix the same day recorded that the profile route pattern must stay flat.

On 25 October the profile page gained "Posts by" followed by the member's name, listing that member's published blog posts. That is the point where the two packages became useful together: the blog package signs each post with a team profile from this one, and the byline links back to the profile.

Why both are separate packages

Neither lists the packages that use it. They publish events and endpoints, and the others look for them at runtime. That is the rule in the modular design post, and these two are the cleanest examples of it.

What I would tell another small team

Keep the small, boring packages separate. A client list and a team list cost almost nothing to maintain, and every larger feature gets simpler when it can ask "who is the client" and "who wrote this" without owning the answer.