Roastery software for green lots, roast batches and true cost per bag.

Coffee roastery management software runs roasting production in one system: green lots with landed cost, roast batches with weight loss, roasted and bagged stock, wholesale and subscription orders, and cost per roasted bag. It makes sense when production keeps repeating and the patched tools cost more in staff time, errors and wrong prices than owning the fix. This page covers roasting production only, not cafe retail: seating, cafe menus and counter service belong to cafe operations, and appear here only where a roastery sells its own roasted coffee.

Buy an existing product when it handles your green lots, roast batches, bagging and orders with reasonable setup and its pricing makes sense. Have software made when the way your roastery works is itself the advantage: your blend rules, your wholesale terms, your bag sizes, your subscription logic, or a connection to your other systems that cannot be done cleanly any other way. If your production rules are still changing every week, wait and settle them first.

The first release should complete one useful production path from start to finish, not collect disconnected features. For most roasteries that path is green lot receiving plus roast logging plus bagged stock: a lot lands, roasts draw it down, weight loss is recorded, and bagged stock goes up by the amount actually produced. Wholesale orders and costing join once that path works. The scope names the workflow, what done looks like, the price, and the exclusions, all before paid work starts.

Each green lot is recorded when it lands: origin, supplier, quantity, and landed cost, meaning bean price plus freight and duty. That landed cost is the number every later cost is built from. Every roast draws down the lots it used, so the shelf count, the remaining lot quantity, and the cost base all move together. Low lots surface before they become a production problem, and a new lot at a different landed price changes later bag costs without rewriting history.

Roasting loses weight, mostly moisture, so roasted coffee always weighs less than the green coffee that went in. The system records what went in and what came out for every batch, and the weight lost is accounted for rather than quietly ignored. That matters because cost per roasted bag must be built from roasted weight, not green weight: ignoring the loss understates cost on every bag and makes margins look better than they are.

Cost per bag starts from what was actually paid for the lot, adjusted for the weight lost in the roast, plus packaging, labels, and any other production costs the roastery chooses to include. Because each batch knows which lots it drew on, a bag costed from a new lot at a new landed price reflects that lot, not an old average. The same cost record feeds wholesale pricing, so a price change in green coffee shows up in bag cost before it shows up as a surprise in the accounts.

Set wholesale prices from your own costs, not from what another roaster charges. A neighbour price has no connection to your lots, your weight loss, your packaging, or your overhead, so copying it cannot tell you whether a bag makes money. The sounder method starts with the full cost of the bag, including the operating costs of running the roastery, and then applies the margin the business needs. The system supplies the cost side of that calculation; the roastery sets the price policy.

No. The profiling tool stays in charge of the roast itself: the curve, the heat, the first crack, and the development time. Roastery management software handles the production information around the roast: which lots were used, how much went in and came out, what the batch cost, where the roasted coffee went, and what needs roasting next. The two work side by side, and a connection between them is scoped only where the profiler offers suitable access.

A blend is a recipe with proportions, not a single lot. The roast draws each component lot down by its share, so green stock, roasted stock and cost all stay correct across every lot in the blend. If a component lot runs low, the system shows which blends it feeds before production stalls. Blend costs follow the lots actually used, so swapping a component changes the blend cost visibly instead of hiding inside an average.

Scheduling starts from orders and stock, not from guesswork. The system shows what is on hand, what can be bagged from roasted stock, which green lots run out first, and what wholesale and subscription orders are still unfilled. The roast plan follows from that: roast what the orders need, bag what the roast produced, and reorder the lots that will run out before the next delivery can land. One shared plan replaces the separate lists the roaster, the packer, and the person answering wholesale emails each keep.

They draw on the same roasted and bagged stock, so a bag promised to a wholesale account cannot also be promised to a subscriber. Wholesale orders carry their own terms and pack sizes, subscriptions repeat on their own schedule, and retail bags sold from the roastery counter come out of the same pool. Staff see one view of what is available, what is committed, and what still needs roasting or bagging, instead of reconciling three order lists.

Yes, when lot numbers are recorded at receiving and carried through each roast to the orders that shipped those bags. That chain answers the question a wholesale customer or a quality problem asks: which lot, which roast batch, and which orders. It also matters for quality: when a roast tastes off, the roaster can see every other batch from the same lot instead of searching inboxes and notebooks.

Moving your data over is scoped as its own job, not assumed. We agree which lists move: green lots, suppliers, roast history, products, bag sizes, and customers. Messy lists are cleaned with the roastery, duplicates are resolved by staff, and the moved data is checked against the old lists before the old tools are retired. A spreadsheet that nobody trusts is not moved as it is; it is fixed first. Roast curves stay with the profiling tool; the production record around them moves into the new system.

For a small, well-defined task with someone technical managing it, freelancers are often cheaper. The pattern that goes wrong is a non-technical buyer coordinating several freelancers becoming the project manager, the tester, and the person who discovers the pieces do not fit. A software company earns its fee when the work needs coordination across screens, rules, data, and connections: one accountable party, one phase price, and checkpoints against the whole production workflow. If your need is one screen or one fix, hire the freelancer.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the production workflow agreed at the start: receive a lot, log a roast, bag the batch, fulfil a wholesale order, and read the cost per bag. Progress is reported in plain language: what changed, what is next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your roastery.

You own the code made for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.