The Domain - First Pop Coffee Company
The Domain
First Pop Coffee Company is a business specializing in roast-to-order coffee. Roast-to-order, in this case, means that the company has scheduled roast days where he roasts a set number of lbs of coffee based solely on the supply and the amount that he can roast in that single roast session. He doesn’t have the resources to roast and sell large quantities of roasted coffee beans, but he wants to grow and scale as demand increases.
The company is run by Nick Chamberlain who has been a hobby roaster for 5 years. He started with a sample drum roaster that can roast 1⁄4 lb per batch. He recently upgraded to a 1 lb per batch drum roaster. Each roast takes about 10 minutes from start to finish. With prep time and warm-up time, he can roast 13 lbs per hour with his current setup. That means that on a given roast day, he can roast about 104 lbs of coffee. He buys it bulk from a supplier and they sell 50 or 100 lb bags via UPS (former) or freight (latter).
A local roaster is selling their “select” coffees for $15.00 - $18.00 per lb. If he can buy 100 lbs of coffee for around $500 - $550 and sell the roasted coffee for $15.00/lb, he could generate about $1560 revenue per roast session. Minus bean cost and overhead, he’s thinking he could do about $2000 - $2500 profit on a good week.
While he has the potential to make more if he can buy more equipment and roast more per session, he doesn’t want to sell more than he can produce. Hence his idea that he sells only the amount that he can roast at any given time. So he hired a software company to develop a website for him that will let him be really transparent to his potential customers about the timing of his roast-to-order coffee.
What does this mean? Well, Nick is open to suggestions. He is imagining having a way to schedule his roasts by calendar day. So on his website, visitors can see what days he has scheduled to roast. Based on his current supply of coffee and the age of the many shipments of green coffee he has in stock (ready to be roasted) he will decide what days he has available to roast. His calendar might be a 1 week calendar or a 1 month calendar, not quite sure yet.
Say he has 200 lbs of green coffee in stock. He wants to roast 5⁄7 days this week. He will plan his roast days for Monday thru Friday. When he updates the calendar through a management console, he can allocate as many pounds that he wants to roast for any of his roast days, along with what kind of bean, cupping notes, and ideal roast based on samples that he’s done (he won’t do custom roast levels). He might plan to roast 30 lbs each day (the default schedule), but he can deviate. He can also do half of the roasts as one bean and half as another. He’ll have the ability to allocate certain beans for each batch.
When he sets up his roast schedule, the coffee roasted that day will become available for purchase from the website. He will choose the bean that he has available and it will be displayed on the schedule with cupping notes.
The user will click on a day and then will see the 30 lbs (or scheduled amount) that are available to buy for that roast day. They might be represented graphically, like a grid that they can click squares to add a lb to their cart. They will see other customers reserve lbs for the day and when all the lbs for the day are purchased, no more lbs can be purchased.
The cart system might work like an event ticket reservation system. You may add the lb to the cart, but to make sure the customer commits - it will be removed from the cart after 5 minutes. Only after the customer charges their credit card will the coffee be reserved completely and no one else will be able to buy it.
Once a customer purchases coffee from a roast day, they will get a confirmation email with the schedule and the expected dates that the coffee will be roasted and shipped to them.
On roast day, Nick will confirm that the roast day has started and the user might get a notification that their coffee is being roasted today. After roasting the coffee and bagging it, Nick will confirm that he roasted all the lbs of coffee that were reserved for the day and a notification will go to the user that their coffee was roasted. The roast schedule on the website will reflect the day’s status - scheduled, roasting, roasted, resting (1 day rest period), shipped.
When the coffee gets shipped after the 1 day rest period, the customer will get notification that their order is being shipped. Shipping will be a flat rate box of some sort (hoping there’s a service that can take care of it). The coffee will get bagged in a plastic zipper bag with CO2 vent.
He’ll need to know what he has available when he sets up his schedule. So when he receives bulk coffee from his supplier, he’ll need to be able to add the green beans to inventory and that will be reflected in his admin console that he uses to allocate batches to the schedule.
The site will also sell roasted beans (dated) when available at a lower price. Maybe ~$10.00 for coffee that was roasted the earlier week. This will be a separate page on the website for discount coffee that’s not roast-to-order.
There will be a mailing list that will notify people about the next schedule release.
He’s not quite ready to approach it yet, but he plans to also offer custom K-Cups at 14g of coffee each cup so the math could be done to figure out whether that’d be profitable.
He’s also thinking about giving the customer a copy of their roast profile as a marketing thing.
His competitive advantage comes from offering the freshest artisan-roasted coffee available and giving himself the freedom to control demand through his scheduling system. If he wants to roast less, he’s able to schedule less. If he wants to make some more money, he can roast extra for the week (given that he has enough customers and demand)…
I will be releasing most of this content only to subscribers. Make sure you sign up by clicking the big red button!
Related Posts:
- More Efficient Domain Modeling with EventStorming
- Where do you find resources for learning DDD, CQRS, Event Sourcing, and EventStorming?
- Has the code devolved into a big ball of mud?… What can you do about it?
- A Better Way to Project Domain Entities into DTOs
- Exposing IQueryable in a CQRS Query Stack
- A Pattern to Decouple your Aggregates from their Clients
- Erlang-style Supervisors in C# with Akka.NET and the Actor Model