Building a Master Operations App Exclusively for Specialty Coffee Roasters - ROASTERYFLOW
The Product
RoasteryFlow is an operations management application built specifically for specialty coffee roasters. The product rests on a simple premise — "Roasting is for the roaster, management is for RoasteryFlow" — and consolidates order aggregation, production planning and forecasting, raw material management, product management, regulatory document automation, and customer management into a single integrated workflow. The target user is the one- or two-person roastery that cannot justify an enterprise ERP but has outgrown a stack of Excel files.
Role & Fit
I ran the project end-to-end as a solo founder — planning, product management, product ownership, UX design direction, and development oversight. The product exists because I spent a decade inside the exact operating reality it is built to solve. At Normcore Coffee Australia and, most recently, at MTSPACE COFFEE, I watched the same administrative work absorb a disproportionate share of the roaster’s time. RoasteryFlow was designed based on that operator experience, not on a market-research hypothesis about what roasters might want.
Context
Small roasters in Korea and around the world are caught between two bad options. Excel is flexible but fragmented: orders from Smartstore, Cafe24, and Shopify arrive in different formats and get reconciled by hand; raw material inventory drifts from its book value because intake and wastage are logged days late; blend ratios and batch sizes live in the roaster's head; and statutory documents are recreated from memory whenever a regulator asks. Enterprise ERPs solve some of this, but are priced and designed for businesses ten times the size, with onboarding complexity that small roasters cannot absorb.
Challenges
Four challenges defined the product scope. First, keep the feature surface small enough that a one-person roastery can adopt it without process redesign. Second, handle multi-channel order aggregation as a genuine integration problem, not a manual import workflow. Third, build production forecasting that is useful even with thin historical data — most small roasters have months, not years, of structured sales data. Fourth, automate regulatory documents in a format that meets Korean food-manufacturing compliance requirements without requiring the user to understand the regulations.
Approach & Execution
The product was scoped around six integrated modules rather than six separate tools. Order aggregation pulls data from the main Korean and international e-commerce platforms into a single view. Production planning combines blend ratios, historical roast yields, and sales trends to produce weekly production targets and green bean demand forecasts. Raw material management tracks intake, usage, and wastage at the batch level, so book inventory stays close to physical inventory. Product management holds blend recipes and batch sizes centrally. Document automation produces the statutory documents as a by-product of the same data. Customer management surfaces which wholesale accounts are due to re-order this week. Each module was designed to reuse the same underlying dataset; the integration between modules is the product, not an afterthought.
Outcomes
RoasteryFlow is now positioned for beta and launch, with a defined go-to-market plan centred on the core value proposition — approximately 800 hours and 10 million won per year of reclaimed operator time for a one-person roastery. The product is being marketed to the Korean small-roaster segment as the missing middle ground between Excel and enterprise ERP. It serves as both a standalone SaaS business and a proof point for how domain-native operators can design category-specific software that horizontal tools cannot match.
Consultant's Perspective
Category-specific software built by domain operators consistently out-specifies horizontal tools built by generalist product teams. The reason is not technical; it is that operators know which five decisions the user makes every week and design the product around them, while generalist teams design around a broad feature surface that has to flex to many industries. For roasters, the five decisions are: what to roast this week, how much green coffee to order, what inventory actually exists, which regulatory documents need to be ready, and which customers are due to buy. A product that makes those five decisions quickly is worth more than one that technically supports a hundred features. That discipline — identifying the weekly decisions and building around them — is how operator-led software wins, and it applies equally to consulting engagements where the deliverable is not software but a better decision rhythm.