A Coffee Shop Is a System Before It Is a Room

Planning the Roastery I Want to Open Someday — 22
Concept visualization of a small coffee roastery workbench with roast records, packaged coffee, inventory and Farmers’ Market preparation.
A small operation can stay simple, but the information created by the work still needs somewhere to go.

When I was running larger coffee businesses, one of the simplest tools we used was an operations note.

It sounds almost too basic to mention.

But imagine someone closing the store notices that an ingredient is running low, a machine is behaving strangely, or a customer issue needs to be followed up. The person opening the next morning may not have been there. In a two-shift store, the two people may barely overlap at all.

If nobody writes it down, the problem is still there. The information is not.

So we used communication notes or a board where the important things could carry over to the next shift.

I have been thinking about that again while planning a much smaller Filgap.

A coffee business has materials coming in, coffee being roasted, quality being checked, products being packed and sold, equipment being cleaned, inventory changing and customers telling you things. Some of those steps may be done by the same person. Later, different people may do them.

Either way, they have to stay connected.

That is what I mean when I say a coffee shop is a system before it is a room.

What I still want to record, even when it is only me

My 2024 business plan described a much larger café than the Filgap I am working toward now.

There were opening and closing shifts, food production, receiving, roasting, packaging, cleaning, deliveries, inventory checks, staff feedback and manager review. It made sense for a more complicated operation.

Most of that structure would be unnecessary at the Farmers’ Market stage.

I do not want to bring a large-company system into a one-person business just because it looks organized.

There are still things I want to record from the beginning, though.

Inventory coming in and being used is one. Quality information is another.

I tend to think about coffee in two ways at the same time. Of course I taste it. Taste matters. But there is a lot I also want to understand through data. If I roast something, check it and then fail to record what happened, that information starts disappearing almost immediately. Later, when I want to compare one batch with another, I am relying on memory.

That is not how I want to build consistency.

At the same time, I do not think every repeated action needs to generate more paperwork.

If something happens the same way every time, a routine or a simple manual may be enough: clean this part, check this point, put this back here.

What I see differently is the information created while doing the work.

  • What came in?
  • What did I use?
  • What did I roast?
  • What did I notice in the quality check?
  • What is left?
  • Did something fail?
  • Is there something I need to remember next time?

Those are the things I want to keep.

For the Farmers’ Market, the cycle is a week

I first thought about the market as a Saturday operation, but that is not really accurate.

For me, it makes more sense as a weekly cycle.

I’m currently planning around a Saturday Farmers’ Market schedule, with the main roasting on Thursday and packaging the coffee the same day. Friday is for finishing the preparation—checking what I need, getting the market materials together and dealing with anything I do not want to discover on Saturday morning.

Then Saturday is setup, sampling, selling and talking with customers.

After the market, I need to know what actually happened.

What sold? What is left? Did one coffee move much faster than another? Did I run short of something? What did people keep asking? Was there something awkward about the setup that I should change next week?

So Saturday does not really close the system. It gives me information for the next Thursday.

The days in between still matter too. I may be working on the website, managing suppliers, cleaning or maintaining equipment, and preparing whatever the next production cycle requires.

Finished coffee creates another small planning question because roast date and resting time matter.

I can imagine having some coffee from the previous week’s roast, if my own testing says it is still where I want it, for someone who wants to start brewing immediately. The coffee roasted on Thursday may suit someone who can let it rest a little longer.

I do not want to turn that into a universal number of days. Different coffees and roast levels can behave differently, and I want Filgap’s guidance to come from the coffee we actually test.

But even at this small scale, the roast date is more than something printed on the bag. It affects how I think about inventory and what I tell a customer.

Memory works until somebody else needs the information

When I am working alone, I can keep a surprising amount in my head.

I know why I moved something. I remember the customer conversation. I know that a particular bag of green coffee is getting low. I know what I meant to check tomorrow.

That can make the operation feel more organized than it really is.

The weakness appears as soon as another person needs to know what I know.

I saw that in larger stores, especially when new employees were still learning. A procedure could exist, but that did not mean every new employee understood what information mattered or what needed to be passed to the next person.

That was where the communication note or board helped.

The person closing did not have to know who would open the next day. The information still had somewhere to go.

If Filgap eventually has a permanent roastery and tasting room with more people or shifts, I expect that kind of handoff to become important again.

I think of people as the bridges between the steps in the system.

But the bridge only works if the information can cross with them.

Fix the customer problem first, then look at why it happened

Customer feedback is not exactly the same as roast or inventory data.

If someone has a problem in front of me and I can solve it, I should solve it then. I do not want to turn a simple customer problem into an investigation while the customer is still waiting.

Afterward, I can ask the other question: why did it happen?

Was it one mistake? Was the process unclear? Was something wrong with the product? Did the equipment contribute to it? Is there something in the records that helps explain it?

Sometimes the immediate solution and the real operating correction are two different things.

Taste feedback needs even more care because coffee is a preference product.

One person may say a coffee is too light. Another person may prefer exactly that character. I want to listen, and I can cross-check what someone says against the coffee and against other products, but I do not want to change the basic direction every time one person prefers something else.

Patterns matter more to me.

If I keep hearing the same thing at the Farmers’ Market, and then similar comments show up through reviews, the website, email or messages, I pay more attention. That starts to look less like one person’s taste and more like something I should investigate.

Listening to customers is important. So is knowing when not to react too quickly.

Some problems only appear when customers arrive

I can think through a system before opening, but I do not believe I can finish designing it on paper.

Peak time is the easiest example.

A store can look fine when you imagine one or two customers. Then several people arrive at once and something starts to break down. Drinks back up. Pickup becomes confusing. One person blocks another. A small step that seemed harmless in planning suddenly creates a queue.

I have seen that happen.

In the businesses I operated before, that was one reason for a soft opening. We could run the store with real customers, see where the operation was not working as expected and make adjustments before expecting the team to handle full demand.

The employees needed practice, but the operating process also needed to be tested.

That is the part I cannot learn only from a floor plan.

I can think carefully about physical workflow. I can think about suppliers and inventory. I can think about how many people may eventually be needed. Those decisions give me a better starting point.

Then I still have to watch what happens when real people enter the system.

For now, I want to keep the system small

I do not want a thick operating manual just because established companies have one.

I do not want reports nobody reads or dashboards that exist mainly because a business is supposed to have dashboards.

The first Filgap system should be much simpler than the one in my old business plan.

What I do want is enough structure that important information does not disappear.

I want to be able to look back at what I roasted and what I learned from it. I want inventory to connect to what I need to buy and what I need to produce. If a problem happens, I want some way for it to be remembered long enough to fix the cause. If customers keep telling me the same thing, I want to notice the pattern instead of treating every market day as a completely separate event.

That is probably enough for the beginning.

As the business grows, the system can grow too.

But I would rather understand those connections before I worry too much about what the room looks like. If the work and information do not connect, a beautiful room will not fix that.