What community kitchens taught us about operational software.

The community kitchen we built a system for, FMB AEM, prepares and serves meals every day to families in the community it serves. There is no closed day. There is no slow week. The kitchen produces at a steady tempo that does not forgive operational confusion. We learned more from that engagement, about what operational software actually has to do, than from many higher-revenue clients.

This essay is about what the engagement taught us, and why the lessons apply far beyond the community kitchen context.

The constraint of daily output

A business with a quarterly cycle has time to recover from a bad week. A business with a daily cycle does not. The kitchen has to produce today's meal today, regardless of whether the ingredient supplier delivered late, the volunteer schedule had a gap, or the contribution flow was lower than expected.

This shapes what operational software needs to do. It cannot be a monthly reporting tool. It cannot be a periodic reconciliation system. It has to be a daily working surface that the coordinators rely on to get through the day. If the system is wrong about today's ingredient position, the meal does not happen.

The discipline this imposes on the software is useful. Every screen has to answer the question "what does someone need to do, right now, because of what this screen is showing?" If the answer is "nothing specific, this is just information," the screen is not pulling its weight.

Volunteer time is the most expensive input

The kitchen runs on volunteers. Volunteer time is the most expensive input the operation has, even though no money changes hands. The opportunity cost of a volunteer hour is high because the volunteer chose to be there, and burning their time on coordination work means they are not available for the actual production work.

This means the software cannot ask volunteers to maintain the system for the sake of completeness. Every field a volunteer has to fill in has to earn its place by saving more time downstream than it costs to enter. Most operational software fails this test. It asks for fields because the developer thought the data would be useful, not because the team has a downstream use for it.

We learned to be ruthless about this. Every form field went through a test: which downstream report or decision does this enable? If we could not answer cleanly, the field came out.

Contributions are a relationship, not a transaction

In the community kitchen context, contributions come from families who are part of the community the kitchen serves. The financial transaction is the smallest part of what is happening. The acknowledgement of the contribution, the receipt, the reminder for next month, the trust that the kitchen is managing the money well, all matter more than the payment itself.

Generic billing software treats these as transactions. It is wrong to do that. The right system treats them as relationships and supports the relationship with appropriate communication, transparency, and acknowledgement.

We built the contribution module with the relationship as the organising principle. Invoices go on the agreed cadence. Receipts go out automatically. Reminders are gentle. Donors can see, if they want, where the money went. The financial transaction is correct because the transaction has to be correct, but the relationship is the actual product.

This generalises beyond community kitchens. Any business with a recurring revenue relationship benefits from treating the relationship as the primary object and the transaction as a byproduct. Most subscription businesses do the opposite, and pay for it in churn.

Governance is operational, not periodic

A community institution that runs on community trust depends on visible governance. The trustees have to be able to answer questions from the community about how the kitchen is running, where the money is going, what the operational shape looks like. This is not a quarterly report problem. It is a continuous visibility problem.

The system we built gives the trustees a financial dashboard they can review at any time. Contribution flow, expense pattern, operational tempo. The trustees do not have to wait for a monthly summary. They can look any morning and see how the kitchen is running.

This shifted the governance conversation. Instead of being reactive ("what happened last month?"), it became proactive ("what is happening now?"). The trustees stopped depending on the coordinators to surface problems. They could see for themselves.

The same pattern applies to any business with stakeholders who need visibility. Founders, investors, board members, partners. Building continuous visibility instead of periodic reporting changes how governance feels. It becomes operational, not bureaucratic.

What this means for premium operational software

The kitchen engagement reinforced something we already believed but had not formalised. Premium operational software has nothing to do with how impressive it looks. It has to do with how seriously the system takes the daily reality of the people who use it.

Volunteer time is expensive. Contributions are relationships. Governance is continuous. Daily output does not forgive. Each of these constraints, accepted honestly, produces a system that works. Each of them, ignored in favour of feature lists or design awards, produces a system that gets quietly abandoned.

The category most likely to need this seriousness is also the category least likely to receive it: small institutions, community organisations, founder-led businesses where the team is the founder's own. We try to do that work well, partly because it is the work the firm exists to do, and partly because the lessons travel.