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.
• Daily generation time — when tomorrow's meals are written from everyone's weekly plans, in your timezone. Turning auto-generation 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. 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

Every night, at your daily generation time, tomorrow'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.

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 → Utilities (/finance/utilities).

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.

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.

---

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	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.

Generating the month

Generate creates the 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.

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 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.

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.

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.
• You cannot approve your own claim, whatever permissions you hold — the screen says so and the server refuses it. Record money you received yourself as a payment instead, which is honest about being your own observation.

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.

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.

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

---

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 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 tomorrow are nudged. Once per day, in your mess's timezone, and a member who has already answered is left alone.
• 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 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.