For mess managers

You are a mess_manager: you run one mess. Everything here is scoped to that mess and nothing you do reaches another one.

You also hold everything in the member's manual — you are a member of your own mess, with a meal plan and a profile like anybody else. This manual covers what is yours in addition.

---

1. Creating the mess

From Get started → Create a mess.

Only the name is really up to you. Timezone and currency arrive pre-filled from the platform default, and both are editable afterwards.

Field	What it decides
Name	What members see everywhere, and on the invite page.
Slogan	Optional. Appears under the name on the invite page.
Timezone	Every date in this mess is read in this zone, whatever a member's phone says.
Currency	One per mess. See §6 for when it stops being changeable.

The cutoff time is not asked for here. A new mess gets the platform default (22:00), and you change it in Settings whenever you need to — see §7. It is a rule for a mess that is already running, and having it on both screens meant one setting with two places to answer it.

Creating is confirmed, because it is a one-way door: the account is now in a mess, and getting out means leaving — which for a sole manager means handing over first.

A new mess is not empty. It is created with Breakfast, Lunch and Dinner at weights 0.5, 1.0 and 1.0, and with you as its first member. All three are editable and deletable immediately. They exist because the weight feature is invisible until somebody sees a 0.5 next to Breakfast and asks what it does.

A platform administrator cannot create a mess for themselves, and will not appear in your roster. If one set this mess up for you, they did it through the API.

---

2. Getting people in

There is no "add member" button, and that is deliberate. A member arrives exactly two ways — you approve a join request, or a platform administrator creates the membership — and the roster follows from either. A third way to create a member would be a second version of the truth about who is in the mess.

The join code

Settings → Join code. Three forms of the same thing, for three situations:

• The code itself — eight characters, for reading down a phone.
• A QR — for printing and sticking on a cupboard. It is generated in the app, so it works offline and the code is never sent to anybody else.
• An invite link — for pasting into the household's group chat. This is the one people actually use.

Both Copy buttons confirm with a tick.

Issue a new code replaces it. Confirmed, with a warning, because it is irreversible in the way that matters: anything printed with the old code stops working immediately, and there is no going back to it. Requests already waiting for you stay valid — you have already seen them.

To close the mess without breaking anything printed, turn off Open to new members in Settings instead. The code keeps working for people who already have it; new requests are refused.

The approval queue

Join requests shows what is waiting. Filter by outcome with Show.

Each row is an account number and whatever note the requester wrote. The name is not shown, and cannot be — this mess's records do not include a person until they are a member, and the app does not reach into the identity service to look one up. The note is what identifies them, which is why the request form asks for one.

• Approve (tick) — confirmed. Creates their membership, then their roster row and an empty weekly meal plan.
• Reject (cross) — confirmed, and a reason is required. The requester sees exactly what you write, and "no reason given" is the answer that starts an argument.

An approval can fail for a reason that is about the requester rather than about your mess — most often because they were approved somewhere else first. The message says so; it is not a fault in your mess.

The roster does not update itself. The member row is created a second or two after the approval by a background message, so refresh Members if it looks unchanged.

Requests nobody decides expire after 14 days.

---

3. Meal types

Meal types is the mess's own list of what it serves.

Field	Notes
Code	Uppercase, permanent. Later features reference it, so it cannot be edited after creation.
Name	The editable one. Change this, not the code.
Weight	The money multiplier. 1 is a full meal, 0.5 is typical for breakfast, 0 means served and tracked but never charged — a mess that gives away tea.

The dialog shows what the weight you have typed will actually mean, in the terms it will be felt in, because this is the least self-explanatory field in the product and its consequence is money.

Changing a weight applies from now on. It does not reprice anything already closed.

Order, offering, and removing

• Up/down arrows reorder the list. One press sends the whole order, so it cannot half-apply.
• Offered is a switch. Turning it off keeps every existing plan and record; the type simply stops being offered, and turning it back on fills in slots for anyone who joined while it was off.
• Delete (bin) does one of two things, and the confirmation tells you which. While nothing references the type it is deleted outright. Once meals have been recorded against it you are offered the permanent delete — the type, its plan slots and its meal records go together, and the months they were in are recalculated — or you can turn it off instead, which keeps every record and stops it being offered.
• A permanent delete stops at a closed month. If any of the type's records fall inside a month you have already closed, the delete is refused and says how many — that month's meal rate and everybody's share of the bazaar were calculated from those records, and removing them afterwards would leave the bill resting on figures that no longer exist. Turning the type off is the answer there, and the refusal says so.

Adding a meal type creates the plan slots for every member, switched off, so the weekly editor never shows a gap.

---

4. The roster

Members lists who is here, searchable by the name they go by in this mess.

Opening a row gives you:

• Name in this mess — "Rafi (3B)". This is yours to set and it changes nothing about their account; their platform name is theirs.
• Not currently eating — the paused state, for a member travelling for a month. They stay a member, nothing about their account changes, and from the next release no meals are generated for them.
• Weekly meal plan — you can edit anybody's, which a member cannot. A member who has just joined has every meal switched off, so nothing is generated for them and nothing reaches the meal rate until they set their week. That is opt-in on purpose — the alternative charged a new member for a template they had never seen — but it does mean a new member who eats on day one shows as zero until somebody records it. If you know they are eating from the first day, open their plan and set it for them, or enter the day itself on the meal grid.
• Make a manager — confirmed. See §5.

Remove (the person-minus icon) ends their membership. Confirmed, and it needs no reason from you because the mess keeps the record; their past meals and costs stay.

You cannot remove yourself. The button is not offered on your own row, and the server refuses it anyway: you leave a mess, you do not remove yourself from it. Allowing it would be a way around the rule in §5.

---

5. Handing over, and leaving

A mess with members and no manager is a dead mess — nobody could approve a request, edit a meal type or, later, approve a cost. So the rule is:

The last manager of a mess cannot leave or be removed while any other member remains.

This is not about your rights; you are entitled to leave. It is about the state the mess would be left in. Nobody can override it, not even a platform administrator.

What happens in practice. Press Leave this mess in Settings. If you are the only manager and others remain, the app does not show you an error — it opens a hand-over picker. Choose who takes over, and it promotes them and leaves in one go.

• Promoting somebody does not demote you. For a moment the mess has two managers, which is a perfectly good state — co-managers are supported, and it is what makes the hand-over work.
• If you would rather stay, Stay for now backs out and nothing has changed.
• If you are the only member as well as the only manager, you can just leave. There is nobody to strand.

Leaving signs you out, because ending a membership invalidates every session that account holds and your old sign-in still claimed to be in this mess. Sign in again to land back at Get started.

To hand over without leaving, use Make a manager on the roster and stop there.

---

6. Settings

Settings is yours alone; members do not see it.

• Name, slogan and logo. The logo appears on the invite page and beside the mess's name. JPEG, PNG or WebP, and you frame it before it is saved. It is private — served through the app to signed-in users, not a public URL.
• Timezone — every date and cutoff in the mess is read in it.
• Currency — one per mess. Editable only until the mess has financial history. From the release that closes a month, it locks: a month priced in one currency cannot be reinterpreted in another, and existing figures are never converted.
• Cutoff time — see §1. Members can change today's and tomorrow's meals until it passes; you can change any day. Leave it empty and members are only barred from the past.
• Automated daily meal generation — an on/off switch, and nothing more. There is no generation hour to set: at midnight in your timezone, that day's meals are written from everyone's weekly plans. Turning it off leaves the board empty until somebody fills it in.
• Billing period start day — 1 means calendar months; 15 means the 15th to the 14th. Everything monthly — the meal grid, the meal rate, closing — follows it.
• Cost entries need a manager's approval — on by default. Off means a member's grocery expense counts the moment they submit it, with no queue.
• Open to new members — see §2.

Saving is confirmed, and the confirmation spells out what a timezone or currency change will mean before you agree to it.

---

The platform's branding is not yours, and there is no mess theme

Your mess has a title, a logo and a slogan (§6), and they appear where your mess is named. What they do not do is repaint the app: the colours, the corner radius, the density and the font are one setting for the whole platform, set by an administrator, and there is deliberately no per-mess override.

If your mess needs a different look, that is a platform-level request rather than something in your settings — and worth knowing before somebody spends an afternoon looking for the switch.

---

If your mess is suspended, or somebody from support looks inside it

Two things a platform administrator can do to your mess. Both tell you.

Suspension. A suspended mess accepts no new members and is flagged wherever it appears. Nothing is hidden from the people already in it — the meals, the ledger, the duties and every figure stay exactly where they were, deliberately, because the usual reason to suspend is a dispute about money and you need the numbers to settle it. You are notified with the administrator's reason quoted in full.

A support session. Somebody from platform support can open a read-only session inside your mess for thirty minutes. You are told the moment it happens, by email and in your inbox, and the message names them. They can see what your members see; they cannot change anything at all — not a meal, not a payment, not a duty.

If either happens and you were not expecting it, the notification is the record: it names who and when.

---

7. Your home screen, and reading the overview

The home screen

Home (/dashboard) is a grid of cards, and which ones you get depends on what your account may read.

They are ordered by how often you need them. The approval queue is first, then today's meals, your next duty and your balance; the live meal rate and the month close sit in the middle; the fine fund and the rota figures are lower down. Month close is monthly work but sits mid-list rather than at the bottom, because for the week it matters it is the only card that matters. On a phone the grid is one column, so this ordering is simply the order you scroll past things. It is fixed — cards never rearrange themselves because a figure became urgent.

Several cards are charts now, and each one answers something the bare number could not. The headline figure has not moved and no card changed position; the chart took the place of the grey strip of secondary numbers beneath it.

Cards are grouped by height, so a short card is never padded out to match a graph. The short ones — today's meals, your next duty, your fines — sit together in one row; the ones carrying a chart sit together below. Within each group the order is still how often you need it. Earlier versions stretched every card on the screen to the tallest one, which left a card saying "no fines this month" rendered mostly empty, and the version after that let each card find its own height, which left gaps under the short ones. Neither was worth keeping.

Month close readiness now shows its four steps — meal period, costs, utility bill, close — with how many are done. It is the same sequence the closing screen enforces, so you can see at a glance how far the month has got without opening it.

• Outstanding dues plots charged against collected, month by month. 12,000 owed is ordinary in a mess that bills 40,000 and collects it, and a problem in one that does not — the total alone cannot tell you which you are.
• Duty compliance breaks the rate down per duty type. Bazaar at 100% and bathroom cleaning at 40% averages to a comfortable-looking 70%, which is the one thing the single percentage hid. Open days are drawn as their own segment and are never counted as anybody's miss — a slot nobody held is a gap in the rota, not a failure.
• Fine fund shows the subtraction rather than the answer: what has reached the tin, what has been spent out of it, and what is still owed. Only the first is spendable, and that figure has been wrong on this screen before, which is why it is now shown with its working.
• Live meal rate draws what the rate actually settled at in recent closed months. The live figure moves all month as bazaar is approved, so on its own it cannot tell you whether this month is expensive — and while the month is still open is the only time you can do anything about it. The spend and units beneath it stay: they are what the rate is made of.

Every chart has a plain table behind it for a screen reader, and wide charts scroll inside their own card rather than making the page scroll sideways.

Reading the overview

Overview carries five numbers and one chart.

The numbers: members eating, members paused, meal types offered, how much of the roster has set a plan at all, and how many requests are waiting. Each is a link to the list behind it.

The chart is the useful part. "How many are we cooking for?" plots expected diners per weekday, per meal type, from everyone's standing plan. It is the mess's demand curve, and it exists the moment plans are set — before a single meal has been recorded. Friday looking different from Monday is the answer to a question you would otherwise have to ask at the shop.

The same numbers are available to a screen reader as a table.

---

8. Running the meals

At midnight in your mess's timezone — not at an hour anybody configures — that day's meals are written for every active member from their weekly plan. It catches up after downtime, and it never touches a day somebody has already set by hand, so a member's Friday-off survives it. It also never rewrites a day that has already happened.

Nothing is ever written for a day the mess has not reached. On the 6th you see the 6th; the 7th appears when the 7th arrives. Meals used to be written a day early, in the evening, which put tomorrow on the board before anybody had decided about it — any such rows left over are cleared automatically, except one a member set by hand, which stays theirs.

Today is re-checked every five minutes against the current weekly plans, so a member who turns their plan on this morning has today corrected rather than waiting for tomorrow. Saving a plan applies it immediately as well; the five-minute sweep is the net that also catches a meal type you have just added and a member whose record has just arrived. Once the cutoff passes, today stops following the plan — it has been cooked.

Today's board (/meals)

Headcounts per meal type — "Breakfast 12, Lunch 18, Dinner 24" — over a searchable list of who is eating. This is the number the cook wants.

The month grid (/meals/grid)

Every member against every day of the billing period. Tap a cell to change it: you can change any member's meal on any day, before or after the cutoff, as long as the period is open. That is the fix for a member who forgot, a guest who turned up, or a plate nobody ate.

Overrides are recorded as manual, so the nightly generation leaves them alone afterwards. Grid and summary export to CSV, and print cleanly.

Is the month open or closed

The ledger shows a badge — Open or Closed & Locked — and that is all it shows. Once a month is closed nobody can toggle, override or add a meal inside it, which is why the badge is there: it explains why the cells stop accepting edits.

There is no close or reopen button on this screen. Closing a month happens in exactly one place, Finance → Monthly closing (section 11), where freezing the meals is step 1 of four. Freezing the meals first is deliberate — the figure the whole month's billing divides by has to stop moving before anything is divided by it — but you do it from there, alongside the three steps that follow it.

The record of which months were frozen and when, and any that were reopened, is on that screen too, under Meal period history.

---

9. Grocery, expenses and the meal rate

Finance → Grocery & expenses (/finance/expenses).

The meal rate

Approved meal / grocery spend for the period ÷ everyone's weighted meals for the period. It is what one weighted meal costs and it moves all month as costs are approved and meals are recorded. The other three categories — cleaning, maintenance, shared household — are split equally per active member instead, because they have nothing to do with who ate.

The approval queue

A member's submission arrives pending and counts towards nothing until you approve it. The queue shows the amount, the submitter, the date and a receipt thumbnail.

• Approve puts it into the totals.
• Reject asks for a reason. The submitter keeps seeing the entry with your reason on it; it stays out of every total.

What you enter yourself is approved immediately — you are the trusted party, so there is no self-approval step. You can also record a cost on behalf of another member, who must actually be a member of this mess.

If you would rather not review anything, turn off cost entries need a manager's approval in Settings and members' submissions count straight away.

Receipts

JPEG, PNG, WebP or PDF, up to 3MB. Every upload is verified by its actual bytes rather than its file name, images are shown inline and anything else downloads, and the bucket is private — links are issued short-lived and per-request.

What you cannot do

Change anything inside a closed period, including approving an expense dated in it. Reopen it first (section 11).

---

10. Utilities

Finance → Utility Bill (/finance/utilities) and Finance → Utility Templates (/finance/utilities/templates) — two menu entries, two screens.

They were briefly merged into one screen with a Heads tab and a Templates tab, on the reasoning that you edit both in the same sitting. The cost was that Templates could only be reached by clicking a tab on another screen, so people stopped finding it; they are separate entries again. A link of the old form /finance/utilities?tab=templates still lands on the Templates screen.

Neither entry appears for a member. Both are gated on utility:manage, which only you and the platform roles hold. A member still sees their own share of every bill on their statement and on Bills & Payments — what they no longer see is the chart of accounts the bill is built from, where every control would have refused them.

Heads, and the one rule about them

A head is a cost category — House Rent, Electricity, Gas, Wifi. You can group them:

Utilities          ← a group
  ├── Electricity
  ├── Gas
  └── Wifi
House Rent         ← on its own

A group never holds an amount. It shows the total of what sits under it, and that total is always the sum of its children rather than a number somebody typed beside them. The screen gives a group no amount box, and the server refuses one even if the request is made directly.

If you add a child to a head that already has amounts on it, you are offered convert to group instead of an error: it creates the child you named and moves the existing amounts onto it. Amounts in months that are already closed stay exactly where they were — that is what those members were billed.

A head that is used by a template or by any generated month is deactivated, not deleted, so past months keep reading correctly.

Icons, and the order they sit in

Each head carries an icon you pick from a list — a flame for gas, a socket for electricity, a house for rent. Pick it when you create the head or from Edit; "No icon" is in the same list, so clearing one is the same gesture as choosing one. Heads with no icon still line up, they just show a plain marker.

Heads are dragged into the order you want by the handle on the left, and every row also has up and down buttons that do the same thing — use whichever suits. The order you set is the order the monthly bill reads in.

A head only ever moves within its own group: Electricity, Gas and Wifi reorder among themselves, and the groups reorder among themselves. Moving a head into a different group is a different decision — it changes what rolls up where — so that is on Edit, not on the drag.

Turning a head off

The button beside Edit turns a head off and on. The icon tells you which it will do, and an inactive head shows greyed with an Inactive badge; Show inactive heads brings them back into the list.

Turning a group off turns off everything under it, in one action. The confirmation says so and names what is going with it — "Utilities is a group, so everything under it is turned off too — Electricity, Gas and Wifi" — because that is not something to discover afterwards. Months that are already generated keep every head they were generated with, whatever you turn off now.

How each head is split

Per head, one of four:

Split	Divided by	Use it for
Equal share	one share each	rent, wifi
By meal units	each member's weighted meals	gas, cooking costs
By days present	days each member was actually here	electricity, water
Individual rates	a figure you set per member	room rent, seat rent, an AC surcharge

Changing a head's split affects months generated from now on. A month that already exists keeps the split it was created with, so correcting a category in December never quietly redistributes September.

Individual rates work the same way, and the same protection applies to them. Set each member's figure on the head (Member rates), and the line's total is their sum — you do not type a total, and one that disagrees with the rates is refused rather than scaled to fit, because a "fixed" rate that got scaled is not the figure anybody agreed to. The rates are copied onto the bill when the month is generated, so revising somebody's room rent in December changes December's bill and leaves September's exactly as it was closed. To pick up revised rates on a bill you have already drafted, remove that line and add it again.

A head on individual rates with no rates set cannot be added to a bill and cannot be finalized — it is refused with a message naming the head, rather than being quietly divided equally between everybody.

When each bill is due, and who to quote

Two optional fields on a head, both on the same dialog as the name and the icon:

• Due day of the month (1-28). What day the vendor wants paying by. Leave it blank when there is no agreed date — a bill with no due day is never marked late, which is the honest answer rather than a deadline the app invented. 29, 30 and 31 are refused rather than quietly moved to the 28th: those days do not exist in February, and a silent move would report a bill late before anybody agreed it was.
• Meter or account number. What you read out at the counter. It is free text, it is shown on the bill's payment panel, and nothing validates or dials it.

Like the split, the due day is copied onto each month's bill when that month is generated and frozen there. Correcting the electricity due day in December changes December onwards and leaves September's line dated exactly as it was posted.

Templates

Finance → Utility Templates. A template is the set of bills that repeat, with what they usually come to — wifi 1,200, electricity 0 because it varies. Mark one as the default and generating a month is one click. Only heads that hold amounts can be picked; groups appear in the list, greyed, so you can still see where each one sits.

---

10a. Bills & Payments — has the vendor actually been paid?

Finance → Bills & Payments (/finance/bills).

Generating a bill says what the month costs. It says nothing about whether the landlord, the electricity office and the internet company have been handed anything — and until this screen existed, the bill you paid out of collected mess cash and the bill nobody had paid looked identical. That is what this fixes.

Two facts, not one

Who funded a bill and whether the vendor has been settled are two different things. They coincide when a member pays the vendor directly, and they are separate events when you pay out of collected cash.

So every payment you record names whose money it was:

Source	What it means	What it changes
Mess cash	Money you were already holding	Nothing on anybody's balance. The vendor is settled, and nobody is owed a refund.
A member's own money	They paid the vendor directly	The next monthly close credits them for it, exactly once.

The screen

A month selector at the top, then the bill with a chip on every line:

Chip	What it means
Not paid	Nothing has been recorded against this line
1,465 left	Part paid — that is what is still owed
Paid	Settled in full
Overpaid	More has been recorded than the line is for. Reported, not refused — see below
Overdue 4d	Still owed, four days past its due date
Paid by Rafi	A member's own money is in this line, and how much

Above them: the month's total, what has been paid, what is pending, and a three-segment bar splitting the paid part into mess cash and members' own money. "Paid" as one figure would collapse exactly the distinction this screen exists to make.

The filter chips — All, Pending, Overdue, Paid — carry live counts, and overdue lines sort first.

Paying several bills in one sitting

The fast path, and what the screen is built around:

1. Type an amount into as many rows as you like. Nothing is written while you type. An empty box is not a payment of nothing — it means that row is not part of what you are recording now.
2. The bar at the bottom counts what you have entered.
3. Press it. One confirmation lists every line, and you set the source, the date and the method once for the whole sitting.
4. It is written as one transaction: if any line is refused, none of them is written, so you never have to work out which half went through.

Six bills paid in a sitting cost six numbers and two taps. If you are interrupted before the confirmation you lose a draft, not half a bill.

The row menu, and what each item actually writes

You will think mark this paid. There is no status to edit — the status is worked out from the payments — so each item is an action that appends a record:

Row menu	What it writes
Mark fully paid	One payment for the whole remainder, mess cash, today
Record a part payment…	Opens the payment form with the amount blank
Paid by a member…	Opens the same form with the source set to a member
Mark unpaid	Reverses every payment on the line, under one reason you type
Payment history	Opens the panel below

Nothing is ever edited or deleted. A wrong payment is cancelled by a reversal that names it and carries your reason, and both stay readable side by side — so the answer to "where did the money go" never has a hole in it. Mark unpaid is the only item that demands a reason, because it is the only one that is a correction.

The detail panel

Tap a line's name. It holds what a row has no space for: the split it was frozen with, its due date and meter number, who owes what for it, and the full payment history — amount, date, source, method, reference, who recorded it and when. A reversal is struck through with its reason underneath. You can record a payment from in here too.

Overpaying is allowed

If you hand the electricity office 5,200 against a 5,000 line, record 5,200. The line reads Overpaid and the screen warns you before you confirm. Refusing it would leave you with no way to record what actually happened — but the surplus is not automatically anybody's credit, so if it should be, post it as an adjustment on the ledger.

What it will not do

• A draft bill cannot take a payment. Finalise it first: a payment against a line whose amount then changes is a reconciliation nobody asked for.
• An unpaid vendor never blocks the monthly close, and that is deliberate. The close is what tells the members what to hand over, and you pay the vendor with what they hand over — a blocker there would lock the whole thing solid. The closing screen shows the settlement state beside step 3 as information, with a link here.
• A closed month does not stop you recording a payment. You close October in order to collect what November's bills need. What stays frozen is the charge side — the amounts and the shares.
• Members cannot record a payment. They see this screen, the chips and the figures, and no controls. If a member paid a bill themselves, they file a payment claim (section 13), which is reviewed.

---

11. The monthly close

Finance → Monthly closing (/finance/closing). This is the one place a month gets closed, and everything it needs can be done from it.

The four steps

The screen opens on a checklist. They happen in this order because each one depends on the last, and the server enforces it either way:

	Step	What it does	Where the button is
1	Meal period	Freezes the month's meals, so the totals the bill divides by stop moving	on the checklist
2	Costs	Every bazaar entry approved or rejected — a pending one has no place in the total	on the checklist, in place
3	Utility bill	Generate, correct the figures, finalize — for the next month	on the checklist
4	Close the month	Writes the snapshot	on the checklist, once 1–3 are green

Step 1 used to send you to the meal ledger and step 2 to the expenses screen. Both still work from those screens — nothing was taken away — but you no longer have to go there. Step 2 shows the waiting entries inline with their Approve and Reject buttons.

Step 4 stays disabled until the three above it are done. If you are entitled to close the month but not to close the meal period, step 1 shows a link to the ledger instead of a button, because it is someone else's action to take.

A closing names two months

Utilities are collected a month ahead, and everything else in the close belongs to the month that just ended. Closing August settles August's food — the meal rate, each member's meals, the bazaar — and collects September's rent, internet and gas at the same sitting, which is how a mess actually works: you eat the month first and pay for it after, and you pay for the roof before you live under it.

So step 3 says Utility bill — September while steps 1, 2 and 4 say August. The bill card repeats it, and the toast after generating says which close collects it. Nothing about this is a choice on the screen; it is what the close does.

Two consequences worth knowing:

• The shares are worked out over the month being closed, not the month on the bill. September's rent is divided between the people who were here in August, using August's days present and meal units — the only figures that exist yet, and the same list of members the closing snapshot iterates.
• A bill is frozen by the close that collects it. September's bill locks when August closes, not when September ends. To correct it afterwards: reopen August, fix the bill, close August again.

Generating the month

Generate creates the next month's utility bill from your template: one line per head that holds amounts, pre-filled with the default. Edit the ones that came in different in the table below the checklist — the group subtotals above them update themselves.

Finalize works out each member's share of every line. Shares always add up to the line exactly, to the last paisa; nobody absorbs the rounding twice.

Closing

Closing writes a snapshot: the meal rate, each member's meals, meal cost, utility share, shared costs and what they already paid out of pocket. Those numbers are frozen — re-reading the month later cannot produce a different answer from the one members settled against.

Reading the closing table

Once a month is closed, the table under the checklist is what everybody was billed. It is worth knowing what each column is, because two of them are new and one of them behaves differently from all the others.

A head billed at an individual rate gets its own column. If Home Rent charges each member a different amount, it is a column of its own on the table, because that is the figure a member cannot work out for themselves and the one you are asked about. Everything else — the heads split equally, by meal units or by days present — stays inside a single Other utilities column beside it, since each of those is the bill line divided by a number already printed on the same row. The two always add up to that member's whole utility share.

The column headings are frozen at the close: rename a head in December, or switch it to individual rates, and September's table still says what it said in September, because that is what those people were billed under. A dash in a cell means that member was not billed under that head at all, which is not the same as being billed nothing.

A mess with no individually-billed head sees one Utilities column, exactly as before — there is nothing to break out. The same is true of months closed before the breakdown was recorded at all: that detail was never stored, the app will not reconstruct it from a bill that may have been edited since, and reopening and re-closing such a month writes it.

What each member paid for themselves that month is shown in two columns: Paid grocery beside Meal cost (the bazaar they entered) and Other paid beside Shared (shared costs and bills they paid). This month is their costs less both. The PDF prints the same two columns. The credit goes to whoever entered the expense, so a purchase you typed in for somebody else is credited to you; correct it with a pair of adjustments (a credit for them, a charge for you).

Previous due is what each member still owed from earlier months after the payments they made during this month, signed: a positive figure is dues left over, a negative one is money they had paid ahead. Payable now is that plus this month's net, as at the month's last day, so the row adds across and you can read one number per person when you are collecting.

Why "after the payments": closing a month charges it on the month's last day, and members pay that bill during the next month. So September's Previous due is August's bill less whatever was paid in September — not August's whole bill. A payment made after the month ends counts in the following month's Previous due.

The one thing on the table that is not frozen is Previous due, and deliberately so. It is read from the ledger every time you open the page, so a correction — a voided payment, a voided advance, a reversed adjustment — shows up here rather than leaving the table quoting a figure the ledger no longer agrees with. A cancelled line and its reversal are both left out of it, whatever day the reversal was made. Everything to its left is the frozen snapshot. The PDF shows the same figures.

There are no column totals for Previous due or Payable now, on purpose: adding them down the roster would let one member's advance cancel another's arrears and report a mess that is square when it is not.

On a phone the table becomes one card per member — the same figures, with labels, rather than a sideways scroll with the name off the edge of the screen.

The PDF carries the same columns. It is A4 landscape, and with a long chart of accounts it gets crowded; that is the trade for a printed sheet that matches the screen a member was just shown.

Underneath the checklist the screen also prints the server's own reasons for refusing, in its words. When the two ever disagree, the server is the one that is right.

The confirm dialog also offers Ask everybody to pay by — a date. It is optional, and leaving it empty is a real choice: a mess that collects as people happen to have the cash sets no deadline, and then nobody is ever reminded and nothing is ever reported late.

The payment deadline, and the reminders

Under the checklist sits a Payment deadline card. It holds two settings with deliberately different lifetimes.

The deadline belongs to the month. It is the date by which everybody should have paid what this close charged them. Set it at the close, or afterwards with Set deadline / Change. Moving it is not a reopen — no figure changes, nothing is recalculated, the month stays closed — so it needs no reason and no audit trail, though the box for one is there because moving a deadline is usually a concession and quoting it is kinder than a bare new date. Everybody is told when it moves — in the app, on their phone and by email, because a deadline is a date people arrange their money around.

Only the mess's latest closed month carries a deadline, and this is the part worth reading twice. A mess can have several closed months standing at once — August and September both closed, neither superseded — and the reminders, the balances list and every member's statement all read the newest one's date. So setting a date on August while September stands would chase nobody, and the app refuses it rather than storing something that does nothing. Navigate to the latest closed month and set it there.

That costs nothing, because a reminder asks for a member's whole balance, not one month's. Whatever August left unpaid is already inside the figure September's deadline chases.

Three things it will not let you do, and all three are refusals rather than quiet corrections:

• A deadline before the month being settled ends is refused. The charges do not exist yet, so nobody could be late paying them.
• A deadline more than 90 days away is refused — counted from the month's end, or from today if the month ended longer ago than that. That is generous for "pay me for last month", it catches the mistyped year that would otherwise silence every reminder until 2027, and counting from today is what lets a month you closed six months ago still take a date next week.
• Setting one on anything but the latest closed month, as above.

The reminder schedule belongs to the mess. Warn a week, three days and a day before, then chase three days after, at 8pm is a standing arrangement, so it is set once and applies to every month. Change on the Reminders row opens it. You pick the time of day — in the mess's own time zone — and tick which warnings and which chases you want. The whole thing can be switched off; the deadline still shows on this screen and on every member's statement.

New messes start on a week, three days and a day before, then three days after, at 8:00 PM. It works without you touching it.

Who actually gets reminded, and this is the part worth knowing:

• Everybody who still owes something, and nobody else. Somebody who has paid is never told to pay. The amount comes from their ledger balance, so a payment recorded five minutes ago is already reflected — and so is a fine, an adjustment, or arrears from a month you closed long ago.
• You included. A manager is a member with a balance like anybody else; there is no exemption.
• Paused members included. A paused member has stopped eating, not stopped owing. They are left out of a closing's figures — no meals, no share — but the money already on their account is still theirs to pay, and they are reminded about it like anyone else.
• Former members are left out. What they owe is a settlement's job, and a settlement is a conversation rather than a nag.
• Once per step, ever. A member warned a week out is not warned again the next day at the same step. If the app is down for the whole warning window it catches up to the latest step that has arrived — one reminder, not the three that were missed.
• Every one goes to the app, the phone and their email. Not just the late ones — the whole point of a warning is to reach somebody who has not opened the app this week, and an in-app-only nudge misses exactly that person. So tick only the reminders you would genuinely send. Each one is a real message to somebody who may simply not have the money yet, and the schedule is the only place that is decided. A member who has switched email off for money notifications still gets it off; this is a ceiling, not an override.
• Moving the deadline re-arms everything. Somebody already chased at "three days late" is warned again against the new date, so an extension is never silent.

What the message says. It opens with the amount and the date — "Your outstanding balance with the mess is ৳1,240.00, and the mess has asked for it by 20 September 2026" — and then says where the figure comes from: meals, shared costs and utilities from the closed months, less everything already paid, with a link to their statement. The overdue version says how many days late it is and offers tell a manager when you can pay as an equally acceptable answer. It is deliberately not written as a demand; somebody behind on their dues usually knows, and an app that scolds people is one they mute.

The closing report

Once a month is closed, Download PDF on the closing screen produces the whole month as a document: the totals, the per-member table, the utility lines and who paid what out of pocket. It is generated on the press, from the stored closing — so a superseded revision is not what you get; the current one is.

As on a member statement, the mess logo and each member's picture appear where they exist and a lettered badge stands in where they do not. A missing image never fails the download.

After it is closed

Nothing inside the month can be changed by anyone: not a member, not you, not a platform admin. Meals, expenses and utility amounts all refuse. There is no override flag.

Reopen is the way in. It asks for a reason, records who did it and when, and unlocks meals, expenses and utilities again. Fix what was wrong, then close again — which writes revision 2 rather than editing revision 1. The earlier snapshot stays readable in the history, marked superseded, so a member who asks "but you told me ৳4,200 last week" can be shown exactly what changed.

---

12. The ledger: who owes what

Finance → Ledger & dues (/finance/ledger) is the mess's money in one screen.

The five figures at the top

Figure	What it is
Outstanding	The sum of what people are behind, and how many of them.
Collected	Money that actually arrived — payments and approved advances.
Charged	Meals, shared costs and utilities billed in the period.
Advances held	Members who are ahead.
Deposits held	Caution money. Owed back, not income.

Outstanding is not "charged minus collected". It is the total of positive balances only. Netting the two lets one member's ৳500 credit cancel another's ৳500 arrears and tells you everybody has paid up while somebody is still behind — which is the one thing this screen must never do.

The cash position: how much of it is actually yours to spend

Under the five figures sits a card that does the subtraction those five cannot:

Payments, advances and deposits received      42,000
Bills paid out of mess cash                   − 8,000
Cash in hand                                  34,000
Caution money held (owed back)                − 18,000
Owed to vendors (3 lines)                     − 6,200
Free to spend                                  9,800

Every term is on the card, not just the answer. A single number with no working is how a mess spends money it does not have — and this app has made that mistake once already, with a fine-fund figure called available that let a payout succeed against money nobody had paid.

Two things the card will tell you rather than hide:

• Fine money is not counted here. A payment tagged to a fine belongs to the fine fund, which tracks and spends it separately. Counting the same taka in two places is how a figure like this becomes confidently wrong. The card names the amount and links across.
• Until you start recording vendor payments, every bill counts as owed, so Free to spend will look worse than it is. That is the truthful figure for a mess that has never recorded one, and the card says so with a link to Bills & Payments rather than presenting a frightening number as history.

Free to spend can be negative, and it is never floored at zero. "You are 2,000 short" and "you have nothing left" are different sentences, and only one of them is useful.

Below it is the same bill strip as on the closing screen, so what is still owed to vendors is one glance away from what is owed by members.

Below it, one row per member, arrears first, because the point of the list is who to chase. Each row opens their full statement — the same view the member sees, so a balance you read out is the balance they are looking at.

Former members stay in the list if they have money on either account, flagged Needs settlement. Dropping them is how a mess loses track of ৳3,000 somebody left owing.

The payment deadline is named once, above the rows — "everybody has been asked to pay by 10 October", or how many people are past it. It is not a column, because it is the same date for every member and a column of it would be one fact repeated twelve times. What the rows carry is an Overdue tag on the people it actually applies to: they owe money and the date has gone. Somebody who has paid never carries it, whatever the date says. The deadline is set on the closing screen.

Recording a payment

Record a payment takes the member, the amount, how it arrived (cash, bKash, Nagad, bank, other), the date, and a reference like a transaction id. It takes effect immediately — you received the money, so there is nothing to approve. The confirmation tells you the member's resulting balance, which is the number you will be reading back to them.

A payment into a closed month is accepted, deliberately. You close October in order to find out what everyone owes, then collect it in November. What a closed month freezes is what people were billed — a payment does not change that, it changes what is left.

Void reverses a payment recorded in error. It posts an opposite entry rather than deleting anything, and asks for a reason. Both lines stay on the member's statement.

Approving claims

Finance → Payments & claims holds the queue. A member's claim is either an advance or a bill they paid — and while it is pending it has changed nobody's balance. Approving credits them; rejecting needs a reason they can read.

Two things to know:

• Approve credits the whole claimed amount, not the member's share of the bill. A ৳1,500 electricity bill paid by one member is still split across everyone; approving credits them ৳1,500 and the surplus becomes their advance. Do not "correct" it down to their share.
• A claim you file is credited straight away, because you are the one who would approve it. It never enters the queue: the ledger entry posts as you save, and the row records you as its own reviewer, so the audit trail says who credited whom. Record money you received from somebody else as a payment instead — that is a different fact, and it is the path to use when you want another manager to look at your own claim first.

If the claimed bill's month is already closed, the credit still posts and the bill line is left exactly as it was — the response tells you, because that line feeds a frozen snapshot.

Managing advances and bill claims

The Advances and bill claims card on the same screen lists every claim — approved, pending, voided — with two actions on the ones still in force:

• Change (pencil) corrects the amount, the date or the note, and asks why. A pending advance is simply updated. An approved one is already on the member's balance, so it is replaced: the old credit is reversed and the corrected one posted, and both lines stay on their statement with your reason.
• Void (bin) cancels it, with a reason. An approved advance's credit is reversed — an opposite line, not a deletion — so the member's balance goes back up by that amount.

An approved advance counts as cash in hand. It says the member handed you money. If what was filed as an advance was really something else — bazaar they bought, say — void the advance; do not post a manual adjustment against it. An adjustment moves the member's balance and no cash at all, so the cash in hand on the dashboard stays wrong however many adjustments you post. Bazaar a member paid for belongs under Finance → Expenses, in their name, where the close credits it to them and puts it in the meal rate.

A bill claim is managed the same way, and the bill line moves with it: changing one reverses both the member's credit and the payment it recorded on the line, then posts the corrected amount against the same line; voiding one reverses both, and the line goes back to unpaid if nothing else paid it. Every member whose claim you change or void is told, by email as well.

A bill claim can never be more than what is still unpaid on its line — the app refuses it when it is filed and again when it is approved. The usual way it happens is a bKash or bank fee added on top of the bill: that fee is not part of the bill. If the mess agrees to cover it, give the member a separate credit adjustment that says so. To fix a claim that was approved with the fee in it, change it to the bill's amount — the line stops reading Overpaid and the member's balance loses the extra.

The member's picker offers the last three months' bill lines, each labelled with its month, because a bill is usually paid just after the month it covers ends. Check the month on the claim as well as the head: "Internet, August" and "Internet, September" are two different bills and only one of them is theirs.

Corrections

Adjust on a member's row posts a manual charge or credit. The direction is a named choice, not a minus sign, and the reason is mandatory and shown to the member.

Use it for what the automated paths cannot express: a negotiated discount, something agreed outside the meal system, or an old closed month where reopening would cost more than it fixes. An adjustment works on a closed month, because appending a dated, explained correction leaves the snapshot intact and the arithmetic visible. Changing what the month says still needs reopen → fix → close again.

Reverse takes an adjustment back. On a member's statement (Finance → Ledger, then the member), every manual adjustment line has a reverse button; it asks for a reason, posts the opposite line, strikes the original through, and tells the member. Use it rather than posting a second, opposite adjustment, which leaves two unrelated lines somebody has to pair up by eye. Only adjustments are reversed there — a payment, an advance or a settlement is voided from its own screen.

No posted entry can ever be edited or deleted, by any role. That is the whole design: a correction is always another row.

Fixing an advance that was really bazaar, end to end: reverse each adjustment you posted to work around it, void the advance on Payments & claims, then — if the bazaar is not already entered — add it under Expenses in the member's name. The cash in hand drops by the advance, the member's balance comes out the same as if the advance had never been approved, and the bazaar is credited to them at the close.

---

13. Caution money, and settling somebody up

Finance → Caution money (/finance/deposits).

The policy

Two settings: the expected deposit and the refund percentage. The expected figure only drives the "still to collect" column — it never posts anything by itself. The percentage is applied when you settle somebody, and frozen onto that settlement, so changing it in December cannot reinterpret one you did in September.

Recording a deposit

Nothing is credited to anybody because they joined. You record a deposit when the money is in your hands, and part payments are ordinary — several deposits add up to what the mess holds.

Caution money sits on its own account. It never reduces anyone's meal or utility bill. If it did, every member's first months would look free and the mess would be counting refundable cash as income.

Settling a member who leaves

Settle on their row opens a three-step wizard: review what they owe → refund policy → deductions and confirm.

Every figure comes from the server, including the live preview as you add deductions, so what you confirm is exactly what gets recorded. The final step restates the outcome as a sentence, because "৳300 back to them" and "they still owe ৳1,500" are what actually ends the conversation.

The arithmetic, in order:

1. The refund percentage is applied to what they have on deposit.
2. Deductions come off that — each with a reason the member can read.
3. What remains clears what they owe first; anything left over is cash back to them.
4. Whatever they still owe stays owed. It is not written off, and the wizard says so.

The columns always add up: refundable + withheld equals the deposit exactly, and applied + cash equals the refundable amount.

Afterwards their deposit account is closed — a further deposit is refused with a message pointing at the void path. Their dues account stays open, because a settlement can leave a remaining due you still need to collect, and refusing that payment would be the same mistake as blocking a payment on a closed month.

Void reverses a settlement's entries and returns both accounts to where they were, keeping the original record readable with your reason on it. You can then settle again on corrected terms.

---

14. Duties, the calendar and fines

Under Duties in the menu: the calendar, the queue of people asking to change days, the setup screen and the fine fund.

The words the screens use — and the ones they do not

Nothing inside these screens says turn, rota, rotation, assignment, slot, accrued, disbursed, waived or compliance. The five menu names stay as they always were — a menu label is a place name people navigate by, and renaming a signpost costs everybody who had already learned it. It is the words inside a screen that had to change — every one of those was on a screen, and every one of them is a word somebody has to be taught. The people this is for live in a mess; they should not have to share our vocabulary to find out whether it is their day to do the bazaar. So the screens say what happens, in the words anybody would use:

What the screen says	What it means
A job	A kind of work — Bazaar, Common bathroom, Attached bathroom
Who does it, and in what order	A list of people. When the list ends it starts again from the top
Together	One line with two or more people on it: they share the same days, and if the work is not done, each of them is fined
When it happens	Every day, or only on the days you pick
Fill in the calendar	Turn all of that into real days with real names on them
Somebody's days	The days that came out of it — Rahim, 6–10 November
A free day	A day nobody has. Anybody can ask for it, and it is never counted as missed and never fined
Fine Fund	One pot the fines go into, which the mess spends on shared things

Read as one sentence: a job has a list of people; you say how often it happens; then you fill in the calendar and everybody gets their days.

Everything is still called the same thing in every place. If the calendar calls it your days, so does the fines page and so does this manual — a screen that invents its own word for something is its own kind of unreadable.

The jobs

A new mess is created with two: Bazaar and Cleaning. They are rows, not fixed options, so you can add your own — and that is how the awkward cases get handled, rather than by a special feature.

Each one carries a name, an icon and, importantly, how it is marked done:

• One day at a time. Every day is its own job: one tick per day, and a day missed is one fine for that day. Right for the bazaar, which happens again tomorrow.
• All the days together. All your days are one job: the bathroom is yours this week, not Tuesday. One tick covers all of it, and missing it is one fine however many days you had.

This is not decoration. Without it, a six-day block of cleaning missed once would produce six fines.

Deleting a duty type only really deletes it while nothing has ever been scheduled for it. After that it is turned off instead, and the confirmation tells you which it will be — every past duty, miss and fine keeps rendering.

Who does it, and in what order

Each duty type has its own rotation, which is what makes the awkward case ordinary:

Rahim has an attached bathroom and cleans only his own. The rest of us share the common one.

Two duty types. Common washroom has a rotation of everyone but Rahim; Attached washroom has a rotation containing only Rahim. Nobody is excluded from anything — a member is in a duty's rotation or they are not, and you see that as a list you edit.

One row is one turn, and that is the whole model. Three people added one at a time are three turns that come round one after another; three people in a single turn are one turn they all serve together. Both look like the same three faces on this card, so the count above the list says which it is, and a shared turn is badged Together.

Tapping a name in the not in this rotation strip always makes a turn of one person — that is the ordinary case. Add somebody is the other one: two people who share a single turn.

A turn can hold more than one person. Two names in one turn is we clean in pairs: they are jointly responsible, either of them can tick it off, and if it is missed each of them is fined. The screen says so when you build the turn and again when you set the amount, because 100 on a paired duty is 200 a miss.

Joining the mess does not put anybody on a rota. The screen shows "2 members are not in this rotation" with a one-click add. Silent auto-add would hand the bazaar to somebody three days old.

Reorder with the up and down arrows. The order matters — see the spare days, below.

How often it happens

Four of the five put work on every single day and differ only in how long one person keeps it. Only Only on the days you pick — like every Friday leaves days empty. That is the distinction to get right before anything else: wanting bazaar once a week and picking each person for a number of days you choose with 7 gives you one person on duty for seven days running, which is the opposite of what you asked for.

What you pick	What it does
There is work every day — a different person each day	Work every day, changing hands daily — the per-day bazaar
There is work every day — the days split equally between everybody	Work every day, the dates you asked for cut into one unbroken run per person
There is work every day — each person for a number of days you choose	Work every day, kept for as many days as you say — a week each, a fortnight each, whatever
Only on the days you pick — like every Friday	The one with empty days. Nothing on the others. Friday for once a week; Monday and Thursday for the bins
I will fill in the names myself	Nothing is filled in; you put people on days

The last one is a real choice, not the absence of one. A mess that fills the calendar in by hand still gets ticking off, days not done, fines and the fine fund — it just never presses Fill it in.

What is not there yet: once every 15 days, once a month, or any "one person every N days" cycle. Only on the days you pick — like every Friday covers weekly and weekend duties because those land on fixed weekdays; a 15-day or monthly cycle does not, and there is no scheme for it today. Use I will fill in the names myself for those until there is.

How the equal split works, exactly

This is the one people argue about, so here it is spelled out. 28 days between 5 turns:

turn 1   days  1- 5    (5)
turn 2   days  6-10    (5)
turn 3   days 11-16    (6)   <- the three spare days land on
turn 4   days 17-22    (6)      the last three turns, one each
turn 5   days 23-28    (6)

The spare days go to the last turns, one each — never two on one turn while another has none.

And because that would otherwise hand the same people the longer turns every month, the rotation shifts by one each time you generate:

November   Karim 5 · Rahim 5 · Sabbir+Nadim 6 · Jony 6 · Imran 6
December   Rahim 5 · Sabbir+Nadim 5 · Jony 6 · Imran 6 · Karim 6
January    Sabbir+Nadim 5 · Jony 5 · Imran 6 · Karim 6 · Rahim 6

The preview tells you who starts and who gets the extra days, in words. If there are more turns than days, the turns at the end get nothing this period and come first next time.

Saving the rules does not put anybody on a day

Every control on this screen saves the moment you touch it — there is no Save button, and the toast in the corner is the confirmation. What it saves is the rule, not the rota.

Until you press Generate, no day belongs to anyone. The calendar is empty, the compliance table has nothing to count, no duty can be ticked off, no duty can be missed, no fine can be raised — and members cannot claim or swap anything, because a claim and a swap are both requests about a specific assignment and there is no assignment yet. Setting up the rules and never generating leaves the whole feature dormant and gives no warning that it has.

So the order is: duty type → rotation → schedule → Preview → Generate.

Generating does not make claims and swaps pointless — it is what makes them possible. They are how the rota changes after it exists, without you rewriting it:

• A swap exists because the rota already gave somebody Tuesday and they cannot do Tuesday. They ask a named member to take it.
• A claim exists for a day nobody holds. Those come about two ways: you publish a day with the member list left empty on purpose — whoever is free takes it — or a member leaves the mess and their future days become open slots.

Look first, then fill it in

Show me first always comes first, and Fill it in stays switched off until it has. It saves nothing and shows the real dates with the real names: who gets which days, and who gets the extra day when the days do not divide evenly. Argue with that list before you commit to it.

Two rules, and neither has an exception.

1. You get exactly the dates you pick — days that have already gone included. This is the case the app was originally wrong about. Nobody sets a mess up on the 1st: Karim has been doing the bazaar since the 1st because that is what was agreed at the table, you get to the app on the 5th, and the first four days are facts that already happened. So pick 1 August and you get 1 August.

Nobody is fined for a day that had already gone when you filled it in. The app will not decide by itself whether that work was done — nobody was tracking it, so neither done nor not done is something the app can honestly claim. Those days are written down and left for you: tick off the ones that were done, from the calendar or from the day itself. Ones you leave alone stay as they are and never turn into a fine.

The preview says how many days in the range have already gone, before you press anything, and the toast afterwards says it again — because a manager who back-filled three weeks without noticing has three weeks of days nobody has answered for.

2. A day that already has somebody on it is never changed. It is skipped, and you are told which days were skipped. So running this again is safe: the second run over the same dates does nothing, and a run over a wider range fills in only the days that are still empty.

So nothing is locked, but nothing is rewritten either. To change a day that is already filled in, change that day — open it from the calendar and put somebody else on it, split one day out of a run, or call it off. That is a deliberate difference: filling the calendar in is a bulk action, and a bulk action that silently overwrote what people had already been told would be the worst kind of convenience.

One limitation to know about. There is no mark this as not done button for a back-filled day. If Karim genuinely skipped the 3rd and you want that on the record, the honest options today are to leave it unticked — it stays as an unanswered day, which it is — or to raise a fine by hand from the Fines page, which does put a real charge on a real bill and says what it is for.

The calendar

One row per duty type, turns drawn as bars across the days they cover. A bar is a run of consecutive days, so a turn that had one day swapped out shows as two bars — which is correct, because somebody else holds the day in the middle.

Open slots are highlighted. An assignment with nobody on it is published and claimable — and it is never recorded as missed and never fined. That is a scheduling gap, not somebody's failure.

Assign days by hand from any day's page. Leaving the member list empty publishes an open slot, which is a normal thing to do.

Asking for a free day, and asking to change days

Asking somebody to change days is a hand-over, not an exchange. You are asking a named person to take your day; you do not take one of theirs. So there is nothing of theirs to check — they keep everything they already have. A true two-way exchange would be a different feature.

A day that is already settled cannot be handed over. If it is marked done, the work happened and giving the day away would credit somebody who did not do it. If it is already recorded as not done, the fine has already landed on whoever held it, and moving the day afterwards would leave the charge on one person and the day on another. If it was called off, there is nothing to take. All three are refused, when the request is made and again when it is approved — because the day can be ticked off while the request is waiting.

• A claim on an open slot always comes to you. There is no other member whose agreement could stand in for yours.
• A swap goes to the other member first. Whether it then comes to you is a setting on this screen — A manager approves every swap, on by default.
• A member can swap one day out of a longer turn: I hold 11-16 but I'm away on the 13th. Approving it hands over that day only; they keep the rest.

Approving re-reads the duty. If you assigned that slot to somebody else in the meantime, the approval fails with a message saying so rather than quietly overwriting your decision.

You cannot approve your own request. Assign the duty to yourself directly instead — that is honest about being a manager action rather than a rubber-stamped request.

Every refusal carries a reason, and the member reads it.

Work not done, and fines

A miss and a fine are two separate facts. A missed duty is recorded whenever an assigned duty passes unmarked — always, whatever the fine settings say. That is what makes "who keeps skipping their turn" answerable in a mess that charges nobody.

Out of the box:

Duty	Fines	Amount	What happens
Cleaning	on	0	Misses recorded, nothing charged
Bazaar	off	0	Misses recorded, nothing charged

Cleaning ships on at zero rather than at a guessed amount, because there is no defensible default for what a mess in another city charges and an invented number would start moving real money on day one. Zero means the rule is on, the price is unset, and the screen says exactly that.

Set an amount and the screen restates the consequence in a sentence before you save it — per day or per turn, and multiplied when the turn holds more than one person.

When a fine is dated

The check runs through the day and fines a duty that has passed unmarked. The fine is dated the day it was found, not the day of the duty. Those differ in one case that matters: you close October on 1 November, and the check for 31 October runs afterwards. The fine still lands — into November, where it can be collected — and its description says "Missed cleaning duty, 31 Oct", so nothing is hidden.

A fine is never quietly backdated into a month you have already closed.

If the app has been down, the check catches up at most 14 days. Anything older stays unassessed, on purpose: coming back after three months and fining everybody for ninety days nobody was tracking would be worse than the gap.

The fines page

Duties → Fines is every fine in the mess: who was charged, for which duty, on which day, and what has been done about it since. Filter by member, or by Charged and Waived. A member opening the same screen sees their own fines and nothing else — the server narrows the list rather than refusing it.

Underneath the list is who has been doing their turns: done, missed, still to come, a completion rate and what each person has been fined. It is complete even for a duty that charges nothing, because a miss is recorded either way — that is the whole reason the two are separate facts. Days nobody held are counted against the duty, never against a person: an open slot is a scheduling gap, not somebody's failure.

Letting somebody off, and changing an amount

• Waive credits the member back and reverses the fund entry. Nothing is deleted — both lines stay visible on their statement, which is what a disagreement about money actually needs. The reason you type is what the member reads on both reversals, so write the explanation, not a note to yourself.
• Adjusting an amount is a waive plus a fresh fine, in one action. There is no edit: an amount that could be changed after it had already been charged is how two records end up disagreeing about what somebody owes, with no way to tell which came first. The button says Waive and re-raise because that is what happens, and all three lines end up on the statement.
• Raising one by hand is for something the rota never saw — a kitchen left filthy, a turn that was never on the calendar. It needs a member, a duty, an amount and a reason, and it is confirmed before it charges anything. It cannot be edited afterwards either; the way back is a waive.
• Marking a turn done after it was missed is yours to do, and it does not cancel the fine. Waive that separately, with a reason.

Every fine in the list says who added it — added by Rahim — except the ones the nightly check raised, which say nothing because the duty and its date are already on the row. There used to be a By hand badge there instead; it sat on every fine in a mess that raises them all by hand, and it meant "no calendar duty behind this", which is our words rather than anybody else's.

"Have they paid it?" — the question on a hand-raised fine

Very often you are writing down something already settled: he gave me the hundred taka on Tuesday. So the dialog asks, and the two answers do different things:

• No — add it to what they owe. The fine goes on their bill and clears whenever they next settle up. This is the default and it is what every automatic fine does.
• Yes — I already have the money. The fine still appears on their bill, with the payment recorded beside it, so their balance does not move. You can say how it arrived — cash, bKash, Nagad, bank, something else — and add a transaction id or slip number if there is one.

Both answers put the same amount into the fine money, because the fund counts what is owed rather than what has been collected (see below).

Why the fine is recorded at all when it is already paid. Leaving it off the bill entirely would mean a charge nobody can find afterwards — and therefore nobody can question. Both lines on the statement is what lets a member check what happened months later.

Two things worth knowing before you use it:

• Waiving a fine you were already paid for leaves the member in credit. The waive cancels the charge; the payment stays, because they really did hand over that money. The mess then owes them that amount against their next bill. If they want it back in cash, record that separately.
• This is not a paid/unpaid tracker. It records how the fine was settled at the moment you raised it, and it never changes afterwards. A fine marked add it to what they owe that the member pays next month is settled through their balance like everything else — the fine itself keeps saying what it said on day one. That is why the list badge reads Settled on the spot rather than "Paid": the fines without it are not necessarily unpaid.
• Adjusting the amount of a fine you were already paid for produces a replacement marked owed, on purpose. Your original receipt survives the adjustment, so the difference lands on the balance: paid ৳100 against a fine adjusted to ৳150 leaves ৳50 owing, and adjusted to ৳60 leaves them ৳40 in credit.

The fine fund

Fines go into a mess-level pot, shown under Duties → Fine money, and every member can see it — they pay into it, so they can watch it.

Four figures:

• Money in — what has actually reached the pot.
• Not paid yet — fines charged that nobody has paid. This is not money the fund holds.
• Spent — money recorded as paid out of the pot.
• Money left — Money in minus Spent. This is what you can actually spend.

Charging a fine does not put money in the pot. This changed on 2026-08-27, and the old behaviour was wrong in a way worth naming: the screen used to show a fine as fund money the moment it was charged, and let you spend it. So a member fined ৳200 who had paid nothing produced a fund claiming ৳200 available. You could buy a mop with money nobody had handed over.

Now a charged fine sits in Not paid yet until the money actually reaches you.

Marking a fine collected

On Duties → Fines, every fine that has not been paid has a piggy-bank button: the money reached me. Press it when the member actually pays, and the amount moves from Not paid yet to Money in.

• A fine you raised as already paid needs no button — it collected itself, because you had the cash.
• Pressing it twice is safe. It records once.
• It does not change the member's bill. Their statement is where what they owe is settled; this is only about the pot. The two are separate ledgers on purpose.
• A waived fine cannot be collected — waiving cancels the charge, so there is nothing to collect.

Why you have to press a button at all. The app cannot tell which part of a payment cleared which fine. A member pays ৳500 against a balance that includes rent, meals and two fines; nothing in this app matches incoming money to particular charges, and guessing would be worse than asking. You know when somebody hands you money for a fine, so you say so.

Recording spending is refused if it would take Money left below zero, and the refusal tells you how much is charged but not yet collected — so you know whether to go and collect it. Your own money spent on the mess is a mess expense (Grocery & Expenses), not a fund disbursement. Nothing in the fund is editable; a correction is a reversal that stays visible beside the original.

On an existing mess, Money left will read ৳0 the first time you look at this after the change. That is the truthful figure — none of those fines had been marked collected, because there was nothing to mark them with. Work down the fine list and press the button on the ones that were actually paid.

---

15. Notifications

The bell is live, and most of what lands in it is somebody asking you for something.

What reaches you

Everything now notifies. The rule is worth learning once: money, deadlines, access changes and rule changes reach your mailbox; everything else is the bell and a push.

The things aimed specifically at you as a manager:

What happened	How you hear
Somebody asks to join the mess	Bell, email, push — marked as needing you
A member submits an expense	Bell, email, push — marked as needing you
A member edits a pending expense, or withdraws one	Bell, push — grouped for the edit
A member claims a payment	Bell, email, push — approving it credits their ledger, so it needs checking
A member claims or swaps a duty	Bell, email, push — and so does the person they are asking
A duty is missed	Bell, push — and the holder is told separately
A member leaves holding future duties	Bell, email, push — those turns are open slots, and an open slot is never missed and never fined, so the work quietly does not get done until you reassign it
A utility bill is drafted	Bell, push — marked as needing you, and never grouped
A bill payment is recorded by a co-manager	Bell only — grouped. It is not your money moving, so it is never emailed
A bill is past its due date	Bell, push and email — once when it first goes late, again at three days, again at a week. Never more than once per step, and never at all once the line is settled
A meal period is closed or reopened	Bell, push
A member changes a meal, or their weekly plan	Bell, push — grouped
A duty is marked done	Bell, push — grouped, and this is the noisiest thing in the product
A utility head is added or changed	Bell, push — grouped
A member joins or leaves	Bell, email, push

Plus everything a member gets, because you are one: your own fines, payments, the month closing, your own duty reminders, the caution-money policy changing.

You are never notified about your own action. If you approve an expense, the submitter hears about it and you do not. If you are the only manager and you submit an expense yourself, nobody is told — there is nobody to tell.

Two reminders now go out on their own

• Before the meal cutoff, members with nothing recorded for today are nudged. Once per day, in your mess's timezone, and a member who has already answered is left alone. It asks about today because today is the day the cutoff closes and the day that has been generated — nothing is written for tomorrow until tomorrow arrives.
• The evening before a duty, and again on the morning. Only to whoever holds the turn. An open slot is never reminded, for the same reason it is never missed and never fined — and a day you filled in after it had already passed is never reminded either, because that would be the app turning its own late start into a nag.

Both are scheduled by the deployment rather than per mess: the lead time and the two hours are set once in the platform's configuration. If they are not going out, that is where to look.

Rule changes are the ones members will remember

Two settings changes are emailed to everybody, and it is deliberate:

• The fine for a duty, because a fine amount can never be edited afterwards. The only moment somebody can object is before the charge.
• The caution-money policy, because it multiplies real money at a settlement that may be months away and is frozen onto the settlement row when it happens.

A settings change that did not move anything sends nothing. Re-saving the same form is not news.

The approval queue still exists

Notifications are not a replacement for Finance → Expenses or Duties → Asking to change. A notification can be read and forgotten; the queue is the list that is still there tomorrow. Anything marked Needs you in your bell is also sitting in a queue, and the queue is the one to work from.

Grouping, and why meal changes are quiet

A member flipping tomorrow's meal on and off three times before the cutoff is not three things you need to know. Those are collected into one message per window (30 minutes by default, yours to change on the preferences screen — the gear in the top-right corner of the bell panel) — and every single change still appears separately in your bell. The grouping reduces the mail, not the record.

What you cannot do

• You cannot change another member's notification settings, and there is no screen for it. A manager who could switch off somebody's fine notifications could charge them silently.
• You cannot send an announcement. There is no compose box: notifications are produced by things happening, not written by hand. A broadcast tool is a product decision with moderation questions attached and is deliberately not smuggled in here.
• You cannot see whether somebody read a notification. The system records that it was delivered, not that it was noticed, and only an administrator sees delivery health at all.

16. Things that surprise people

• Suspending a membership tells the member nothing. They can still sign in and still see the mess, and every write is refused with no explanation of why. There is no notification for it yet — so say something when you do it. (Their account being suspended by a platform administrator does notify; a membership being frozen does not.)
• The roster lags an approval by a second or two. The membership is created immediately; the roster row follows by background message. Refresh.
• You hold MEMBER twice — once as every account does, once through your membership. It is harmless and deliberate; it is what makes "manager, then member again" a single membership row appearing and disappearing rather than roles being shuffled.
• Reordering never notifies. Meal types, duty types and utility heads all drag-and-drop, and display order changes nothing about what anybody eats, does or pays.
• Members can see the join-request queue but cannot decide anything in it.
• A miss and a fine are two separate notifications. Somebody who missed a turn that carries no charge is still told they missed it, and so are you — because who keeps skipping their turn is the question the whole feature answers. When a fine does follow, the fine carries the email and the miss does not: two letters about one evening is one too many.
• There is no "once every 15 days" or "once a month" schedule. The five schemes cover a duty that happens every day and a duty that happens on fixed weekdays. A cycle measured in days — one person every 15 days — has no scheme; fill those in by hand for now.
• Saving the rules rosters nobody. Nothing exists until you press Generate, including the claims and swaps members might want to make, and the screen does not nag you about it.
• The calendar does not fill itself in on a timer. It is a deliberate action with a look-first step in front of it — a job quietly rostering next month is how a mess discovers in February that it has been fining somebody who left in December.
• A back-filled day cannot be marked not done. Days you fill in after they have gone are recorded and never fined, and there is no button that says the work was skipped. Leave it unticked, or raise a fine by hand and say what it is for.
• An open slot is never missed and never fined. A duty nobody holds is a gap in your rota rather than a failure by anyone, and the app will not turn it into a charge.

---

17. The public site, and what you can point people at

Neer has a front page, at /. It is readable by anybody, signed in or not — which matters to you mostly because it is what you send somebody before they have an account.

Your own home screen moved to /dashboard. Nothing about it changed. If the copy on your phone's home screen briefly shows the marketing page before landing on your dashboard, that is the installed app opening the address it was installed with and being redirected; it is harmless.

What to send a prospective member

• /demo — the real application running on a made-up mess with three months of history. Not screenshots: the same screens you use, so what they see is what they will get. Nothing in it is saved and everybody in it is invented. It starts on its own when the page opens, and Exit live demo is the way out — as is going anywhere else on the site, or closing the tab. It is offered to signed-out visitors only, so you will be shown a link to your own dashboard instead. To look at it yourself, open it in a private window.
• /docs/member — the member's manual in full, no account needed. Faster than explaining meal cutoffs twice.
• /docs/mess-manager — this manual, also public, if somebody is thinking about running their own mess.
• /terms and /privacy — readable before signing up, which is the point.

Each guide has a search box that looks inside that guide, and an "on this page" list. On a phone the contents list is a tap-to-open panel rather than a column.

What you cannot change

The public site is the platform's, not the mess's. The front page, the terms, the notices and the guides are edited by whoever runs your platform — you have no screens for them and no permission over them, and a mess cannot have its own landing page. That is the tenancy model: one platform, one public domain.

What you do control is unchanged and is where a new member actually arrives: your join code, your mess's settings, and whether joining is open (§2 and §3).

One thing worth knowing

Nothing on the public site can read your mess. The landing page, the guides and the demo are served without any tenant in them at all — the demo in particular reaches no service, no database and no file store, and every figure in it comes from data shipped with the product. Nobody browsing the public site is looking at your meals, your bazaar or anybody's balance.

---

Reporting a problem to the people who run Neer

Something wrong with the product itself — rather than with your mess — goes to the platform team through /contact, the same form anybody who is not signed in uses. It takes your name, an email address, an optional phone number and the problem, and answers with a reference like NR-7K3QF2AB.

Keep the reference. With the email address you used, it is the only way to look the message up again on the same page: nothing is stored in your browser and there is no account behind it. The tracker shows four steps — sent, viewed, contacted, solved — including the ones that have not happened yet, so you can see what is still to come.

It is not a conversation. The reply arrives in your email or on your phone, not on that page, and a message cannot be added to after you send it — send another and quote the first reference. One email address may send five messages a day.

This is not the place for anything inside your mess. A member's dispute about a meal count, a bill or a duty turn is yours to settle; the platform team can read none of it without a support session, which is audited and read-only.