Lessons From Building A Programmed Bookstore

What if you could program a retail environment like you program a desktop application? Miniature computers, pervasive networking, and affordable tablet interfaces make programmed retail environments seem inevitable. Instead of using the familiar mice and monitor for system interaction, a programmed retail operation like my brick-and-mortar bookstore, Lorem Ipsum in Cambridge, Massachusetts, connects cameras, RFID readers, monitors, speakers, and motion detectors to software designed to maximize customer happiness and store profit. But it’s not as easy as just adding sensors and a few monitors to the store. Here’s what you learn when hacking retail in real life.

Lessons From Building A Programmed Bookstore

When Lorem Ipsum Books started up in 2003, I built a web-based inventory and point-of-sale system because that’s what I knew. And then I made an architectural choice that would haunt me for years: I chose to move the Linux server from under the sales counter to a data center down the road.


This simple system was run on an in-store Linux machine running an Apache web server with a MySQL database of inventory on it. Most web developers today would be familiar with this simple LAMP stack. Employees accessed the inventory system through a web browser running on the computer sitting on the checkout counter. For a cash drawer and receipt printer I went on eBay and purchased the cheapest I could find. With this hardware and a found Cuecat barcode scanner I was in business. I built the computers with spare parts, so the total cost was less than $300.

Cords: Complexity Visualized

In typical point-of-sale fashion, the cash drawer connected to the receipt printer with a cord that looks like a telephone cable, which in turn connected directly to the controlling serial port on the Linux machine. The chain of command from cash register to cash drawer via receipt printer was simple, and thankfully worked with little coaxing. But this simplicity wasn’t to last, as I started hacking the store, adding sensors. To receive this sensor input required the addition of a microcontroller. The iRX programmable integrated circuit sat in a box under the counter that converted sensor data into signals readable by the Linux server.

As I expanded the store’s infrastructure, complexity was visibly tied to the size of tangled wires protruding from the ground. Today much of this physical jumbling can be eliminated by embracing Bluetooth, Wi-Fi, or ZigBee, but at the time the physical connection was standard and neat cabling a requirement for both system debugging and a pleasant shopping experience.


Fun With Sensors

Once a sensor backplane had been established with the microcontroller, I wired in a half dozen inputs from various places around the store. For example, a “button box” outside lured puzzled passersby into the store as an in-window speaker spoke the “word of the day,” the title of the last book sold, or the store’s catchphrase depending on what button they pressed. Inside the store, when customers lifted a red lid on the checkout counter the store speakers would blurt out the word of the day. (The word of the day is a randomly chosen word from the title of a randomly chosen book in stock which we tweet daily. If you buy a book with this word in the title, the Point-of-Sale system gives you 10% off.)

After the Cloud, It Began to Storm


The in-store POS system worked for several months with few hiccups. Word eventually got out that I had an inventory system for bookstores, and others wanted to use it. That’s why I chose to move the Linux server from under the counter to a data center: so that other stores could use the system. I rationalized that I could run secure connections between the servers and desktop web browsers, so why have the server in-store? My previous experience with enterprise software further strengthened my belief that software as a service would be easier to maintain than shipped code.

But one obstacle remained before I could move the server to the cloud: How do you connect peripheral devices that live behind a firewall to a server on the Internet? For this, I tapped into the power of XMPP, the protocol that powers Gtalk and Facebook Chat. Chat clients work by connecting to a server on the Internet which then relays messages to other servers and clients. When clients lose their connection, they are programmed to dial the server back. The protocol can be run over a secure connection, and as it’s an outbound connection that will work behind a firewall or NAT device, so it seemed perfect for connecting receipt printers to a server on the Internet.

Lack of a Feedback Loop

The only problem was there was no easily visible feedback between the printer and the server. The plumbing between server and the receipt printer was now a combination of physical and virtual. A USB converter added another step in the chain, and before you knew it it wasn’t always obvious why the cash register drawer didn’t open when you completed the sale. Had the cable come undone? Was the USB converter somehow attached to a different virtual interface after the reboot? Was the Internet connection down? Server problem? Ouch, it got ugly. But as I was skilled at debugging, I didn’t think too much of it, and pressed forward.


As I took the printer setup to other bookstores around the nation, it became quickly clear that setting up the system would require too much technical support for the amount customers were willing to pay. This became the reason that the Ka-Zam service would stop accepting customers in 2008.

Lessons Learned

  1. When your Internet connection goes down, your business must still work.

    If you’re depending on something on the Internet, your business will go down if your Internet connection is accidentally severed. You should either have a backup Internet connection, or better yet put systems in place to enable your sales clerks to perform all functions manually. It happens more often than you’d think.

  2. Make it easy to find the price.

    When you have the Internet’s data at your disposal, it’s tempting to use it in clever ways. But at the end of the day, your customers just want a product for a fair price. We tried a dynamic pricing model that tied the price to the lowest price on Amazon (including shipping), updated in real-time. We also did price sensitivity testing. Customers hated not having a price on the product, so both of these programs were killed in favor of traditional sticker-based pricing.

  3. Build with commodity hardware. The most common input/output devices will save you time and money.

    It’s tempting to buy the latest and greatest point-of-sale hardware. But when things break, you’ll be glad you chose the Epson TM series printer and a keyboard-wedge style barcode scanner. I’ve swapped printers with other stores when mine went out temporarily.

  4. Even the slightest interface fumbling is problematic.

    When browsing the web you don’t notice a half-second delay. When you’re in line at the checkout counter and you have 10 items, a half second here or there adds up, and frustrates both customers and employees alike.

  5. Security isn’t just a lock on the door. WIth a digital point-of-sale, there are new ways into your cash register.

    If you move any of your operations into the Internet, you are opening up new ways to infiltrate your organization. HTTPS and secure connections are required. Similarly if you offer Wi-Fi connectivity to your customers, you should have a unique network for your POS and separate one for the public.

  6. Retail systems need to work out-of-the-box without much fussing or configuration from the store owner.

    Most store owners spend their time on their customers and their product. They don’t have the time to fuss with a finicky piece of technology. If you’re making retail technology, it needs to have a clean interface, work out of the box, and break in a way that’s obvious.

  7. Give customers what they expect, but surprise them with more.

    If you’re adding digital capabilities to your store, you need to first cover the basics. While all of our books are inventoried so we know where every book is, we still need section signage so that customers have a familiar interface for retail browsing.

  8. Expect things to break and disappear.

    The best retail interface is the invisible one. Every keyboard, display, or gadget that can be touched will be broken–or stolen. It takes a lot of engineering and industrial design work to make retail interfaces that do what customers expect as well as make a profit.

It’s Only Just Begun

While I struggled with this in a past life, I look forward to seeing where today’s entrepreneurs take the retail experience. We’re at the dawn of a new era of retail, namely that of the programmed store. This new store will marry together data and localized experience to drive product sales and profit. It will use the Internet to enhance customer experience, efficiently source products, or provide an infrastructure that would not be possible in a single, stand-alone store. Yet it will have all the charm of the mom-and-pop stores of yesteryear.

[Image by FastLizard4]


About the author

Matt Mankins is the former CTO at Fast Company and founder at