The Evolution of RoastLog
We’re starting the big march forward to our actual release date. For those following us on Twitter, you’ve probably heard us whining about how much work we have to do. Starting up a company while holding down day jobs has been a huge learning experience for all of us. I think I can speak for the three of us when I say, it’s been a lot of fun and hugely rewarding so far, and we haven’t even made $1 yet.
The path to where we’re at right now, and where we’ll be in April when RoastLog 1.0 lands, has been a long and interesting one. The whole idea first started over three years ago when I got the notion of building my own auto controlled home roaster. At the time, I was roasting on an iRoast2. I had just written a PID algorithm at work to smartly sample email messages from various sources (I was working at an anti-spam company and we were getting a lot of spam on purpose). I was pretty familiar with PID controllers from my engineering days at NASA and Rockwell, but was surprised at how easy it was to implement in software (BTW, one pet peeve of mine is people referring to “PIDs” as devices, when it’s really an algorithm…the controllers just implement this algorithm in hardware or software).
The first step in building an automated home roaster would be to measure the current temperature. This was all around the same time I attended my first SCAA show where I:
- Took some roasting classes and wrote down time-temperature data on a piece of paper (ack!)
- Talked with Joe Behm who told me he sunk a LOT of time and a LOT of money building the Behmor
Realizing that coffee roasters wanted to track data and knowing that I’m not good enough with hardware to build my own roaster, RoastLog was born.
The initial idea was targeting at home roasters since, well, I was a home roaster. I came home, did some research and hacked together the first version of the Data Bridge. This is what the prototype looked like…it was built on top of the awesome Arduino. The bare thermocouple wires literally plugged into the top breadboard. Hey, I got a B- in my circuits class in college…so leave me alone.
Now, I whipped together some software to talk with the Arduino over USB along with a website and I was tracking all of my own roasting data. Perfect.
Things stayed pretty amateur for a while until I began realizing that professional coffee roasters needed something like this. A buddy and I took the idea to SCAA last year in Atlanta to gauge interest. The software was still in its infancy. In fact, I was up until 3am before the show getting the Data Bridge software polished. Regardless of its rough exterior, the response we got was fantastic. Paul from Mecca Espresso in Sydney (who was our third person at the booth) wanted to buy it right then and there. After the show, it was clear that this needed to happen for real.
I had previously met Ted through a mutual friend, and he was acting as a great advisor and sounding board up to that point. While I knew quite a bit about coffee relative to the layperson, I didn’t have 15 years in coffee industry like Ted. With bigger goals comes more work, so I asked Ryan if he was interested in working on RoastLog…we needed a good front-end engineer (I’m more of a back-end server/db guy). Fortunately, he jumped in with both feet. My previous buddy bowed out due to family obligations, so now it’s the thee of us.
I honestly feel that it couldn’t have worked out better. The three of us have very complimentary skills and RoastLog has evolved over a long course. We really feel like now, the application we’re building is going to be immediately useful and will really make the lives of coffee roasters easier. In fact, our testers have told us as much. The Data Bridge has been designed properly, and we have our first batch ready to go. The Data Bridge software is much better than what we had at the show last year.
What we’re working on now is the first “real” version of the website, since we’ve had our testers using, well, a test site. They get to use RoastLog’s features, but with a user interface which was just intended to work, not be delightful to use. Ryan has done a great job evolving our web application to the point where, it will be delightful to use, and will allow you to find your data quickly and accurately, work with you, not against you. In the next seven days or so, we’ll be finalizing the design, then it’s off to the races. There will be lots of code slinging going on, but I have no doubt that the results will be very impressive.