How a Failed Snowboard Shop Led to Shopify

In 2004, a 24-year-old German programmer named Tobias Lütke started selling snowboards online from Ottawa under the name Snowdevil. The most valuable thing the store ever produced turned out to be the software it ran on. By 2006 that software had become Shopify. Years later Lütke reflected that he'd never really been in the snowboard business. He'd been in the business of helping people sell things online¹.

Quick Summary

A snowboard shop's failure led to Shopify because the store software Tobias Lütke wrote for Snowdevil, his Ottawa shop opened in 2004, proved worth more than the snowboards. Other merchants asked to use it, it launched as Shopify in 2006, and the 2008 downturn finished the store while the platform held. For operators, the tools a team keeps working around often point to a problem other businesses share.

The story is usually told as a pivot story, about a founder who fails and bounces back. The details are more useful than that version. A shop owner kept running into the same limits with his tools. He fixed them for his own store, and then other shop owners started asking to use his fix. That sequence matters again right now, because AI has brought down the cost of building your own tools, and more service businesses are running into their own version of the Snowdevil moment.

What Held Snowdevil Back?

Snowdevil was an online snowboard shop that Lütke ran with co-founder Scott Lake, and by most accounts the store itself was well built. It looked good and worked the way it was supposed to¹. The trouble was what it sold.

Snowboards sell mostly across a few winter months. They cost enough that people like to see one in person before buying. And in 2004, plenty of shoppers still hesitated to spend hundreds of dollars on a website they'd never heard of. A small online shop in that category tends to spend heavily on getting noticed, and then it waits for the snow.

Lütke came to the store as a programmer first. He had moved to Canada from Germany, snowboarded as a hobby and had no business training to speak of. That background explains a lot of what happened next. He looked at his store's problems the way someone who writes code does, as things that could be rebuilt.

Why Did Lütke Write His Own Store Software?

He built his own store software because the ready-made options of 2004 couldn't do what he needed, and he was one of the few shop owners who could code a replacement. He tried several of the store builders available at the time, including Yahoo Stores. The breaking point, as he has told it, came after he paid for a custom design and found that Yahoo Stores would barely let him change the background color of the top of the page.

Lütke has said that adding a single product to his Yahoo store took about 15 minutes of clicking through screens and confirmation prompts. For a hypothetical catalog of 200 boards, bindings and jackets, that works out to 50 hours of data entry before the first sale.

Two pieces of timing made building his own tool realistic:

• Ruby on Rails had just appeared. David Heinemeier Hansson released the Rails framework in 2004, and it let a small team build a database-backed website much faster than before. Lütke became one of its early contributors.
• Online selling was young. The existing store builders were clunky and slow to change. A cleaner, faster one didn't have much to beat.

Most shop owners with the same complaints would have switched store software vendors or put up with it. Lütke spent the time writing a store builder that fit the way a small merchant works, and Snowdevil became its first customer.

Other Merchants Asked for the Software Before It Was for Sale

The move from snowboards to software started with outside demand: other online sellers saw Snowdevil and asked what it was running on. Lütke and Lake realized the tool they'd built for themselves solved a problem those sellers shared, and in 2006 they launched it as Shopify.

Lütke later described the goal as taking "this really, really complex idea of internet entrepreneurship" and making it simple and straightforward¹. That's a merchant's description of the problem. He knew which parts of running an online shop were confusing because he'd sat through every one of them himself.

The two businesses were built very differently, and the differences explain why the second one grew:

A store that sells a board once has to find a new buyer for every sale. A platform that a merchant pays for every month keeps earning for as long as that merchant stays in business, which is why subscription revenue changed the math for Lake and Lütke.

Surviving the 2008 Downturn

When the 2008 financial crisis hit, shoppers stopped buying luxury sporting goods and focused on necessities, and a snowboard store couldn't hold up through that¹. Shopify's customers sold across many categories, so a drop in any one kind of spending couldn't take it down the same way. Accounts differ on exactly when Snowdevil wound down, but by the time of the crisis the software had been the main business for about two years.

The same year, Scott Lake stepped down as CEO and Lütke took the role. He hadn't been looking for it, and he has said he would have preferred to keep writing code. The company was still small, still without outside investment, and now run by an engineer who had come to business sideways.

It's easy to read this part of the story as a dramatic rescue. It looks more like a slow sorting. Snowdevil depended on people feeling flush enough to buy winter gear, and Shopify depended on thousands of different sellers each staying open. When money got tight, the second arrangement held and the first didn't.

Letting Outside Developers Build on Shopify in 2009

In June 2009, Shopify released an API, a set of connections that lets outside programs read and update store data, along with an App Store where developers could sell add-ons to merchants. The platform reportedly had a little over 5,000 merchants at the time.

The reasoning was simple. Merchants wanted shipping tools, accounting connections, email marketing, product reviews and dozens of other features, and a small team in Ottawa couldn't build all of them. Letting other developers build filled those gaps, and it gave those developers a reason to bring their own customers onto the platform. Lütke's years with Yahoo Stores, which let him change almost nothing, probably made the value of that openness obvious to him.

Shopify went public in May 2015 on the New York and Toronto stock exchanges, and it has since grown into one of the most valuable companies in Canada.

Where the Snowdevil Story Stops Being a Useful Model

The honest limit here is survivorship. For every store owner who turned an internal tool into a software company, many others spent a year building something nobody else wanted to buy. Lütke had advantages most frustrated operators don't: he was a skilled programmer, he arrived just as a new framework made building fast, and the competition was weak.

For a service business with a dozen people, turning an internal tool into a product usually pulls attention away from paying clients, and the product rarely makes up for it. Selling software is its own job, with support, updates, a sales process and a different kind of customer. In most cases, fixing the problem for your own team with tools that already exist, and keeping the business you have, is the better trade.

What does carry over is the noticing. Lütke paid close attention to a daily annoyance, understood why it kept happening, and recognized the moment when other people turned out to have the same one.

Service Firms Building the Tools They Wish They Had

The cost of building custom software is falling again, this time because of AI, and it's reopening the path Lütke took. Agencies and consultancies appear to be turning more of their own processes into internal tools, client portals and small AI assistants for service work that handle parts of the job. The line between a service firm and a software company is harder to draw than it was a few years ago.

Shopify is a reminder of which side of that line tends to hold the advantage. It worked because a merchant built it, someone who knew what adding products one at a time felt like. Software built without that first-hand knowledge often comes out tidy and misses where the work hurts, while a firm that has lived with a problem for years knows exactly where it pinches.

Cheaper building has a catch, though. Once the building gets easier, deciding what's worth building becomes the harder part. Teams that start from a tool ("we should use AI for something") tend to end up with demos. Teams that start from a problem, such as a client proposal that takes three days to assemble or project updates spread across five inboxes, tend to end up with something they open every week.

A good place to start: list the tasks your team complains about every week, and next to each one write down the workaround people already use, whether that's a shared spreadsheet, a copied template or the one colleague who "just knows." Each workaround marks a spot where your current tools stop fitting the work.

AMW's own software came out of this kind of lived frustration. After running a service business since 1997 with customer details scattered across disconnected tools, AMW built AMW CRM so a client's full history sits in one place instead of five.

If your list of workarounds keeps tracing back to customer information spread across too many tools, that's the problem worth solving first, and a look at how AMW CRM handles it is one place to begin.