Should You Abandon a Profitable Product for the Software Behind It? Shopify's Snowboard Pivot
Short answer: Do not abandon a profitable product because its internal software attracts compliments. Run paid tests with at least five external businesses, prove they can succeed without your operating knowledge and compare software contribution with the product business you would give up. Make a full switch only when independent demand, repeatable delivery and runway survive a downside case.
An internal system can solve a real problem and still be impossible to sell. Its apparent simplicity may depend on the team that built it, the data you control or exceptions handled manually.
Conversely, preserving the original business can consume the attention needed to pursue a much larger problem. The decision is not whether software has higher margins in theory. It is where your strongest paid evidence sits.
What Shopify's Snowdevil pivot established
Tobias Lutke built ecommerce software because the available options did not suit Snowdevil, the snowboard shop he started with Scott Lake and Daniel Weinand. In a first-person interview, Lutke said the initial store software took about two months to build and the snowboard business produced a profit in the 2004 season.
Requests from other merchants suggested that the system behind the shop could be the more valuable product. Turning it into software others could use took roughly another year and a half before Shopify launched in 2006. The founders went without salaries until launch, relying on savings and family support. In a direct interview, later president Harley Finkelstein identifies his business as Shopify store number 136.
The public record does not disclose Snowdevil's margin, number of licensing requests or the first cohort's churn. Those are precisely the numbers a founder should demand from their own decision.
My view is that most founders should run both models briefly, then choose. Permanently operating a shop and a software company creates two customer groups, two rhythms and divided product priorities. A time-limited overlap creates evidence. An indefinite hybrid creates drag.
Use the Merchant-to-Software Demand Switch
The Merchant-to-Software Demand Switch tests whether an internal capability can stand independently. It has five switch conditions.
| Condition | Product-business evidence | Software evidence required | |---|---|---| | External pull | Customers want the end product | Five unrelated operators ask, trial or pay | | Independent outcome | Your team runs the system | Users reach value without insider intervention | | Repeatable economics | Known product margin | Positive contribution after support and hosting | | Market route | Existing retail channel | One channel produces three qualified customers | | Downside runway | Product cash supports the team | Cash survives delayed software revenue |
Score the models with the same time period and conservative assumptions. Do not compare last year's mature store with next year's optimistic software forecast.
Separate requests from demand
“Can I use that?” is not a purchase. Ask the interested operator to describe their current system, cost, switching work and approval process. Then make a paid offer with a defined start date.
The strongest early signal is not a waiting list. It is an external business transferring data, changing a workflow and paying to continue. Five customers is a practical minimum for a small business product because one enthusiastic buyer can distort the result. Enterprise tools may require fewer customers but stronger commitments.
The broader method in [finding problems people pay to solve](/business-ideas/problems-people-pay-to-solve/) helps distinguish admiration for technology from budgeted pain.
Remove your operating knowledge from the test
Internal tools often contain assumptions nobody wrote down. The shop team knows which orders require intervention, why an inventory figure looks wrong and what to do when payment fails.
For every pilot, log setup minutes, questions, corrections and actions performed by the founder. Classify each as product defect, missing guidance, customer-specific work or unavoidable service. External users should complete the core outcome without the original operating team touching their account.
Do not automate every exception before selling. First learn which exceptions recur. But price manual help honestly, because hidden support can make software appear profitable.
Compare contribution and founder constraint
Calculate monthly contribution for each model:
Revenue minus direct goods, fulfilment, payment, hosting, support and acquisition costs.
Then identify founder hours required to produce that contribution. A store generating £6,000 contribution with 140 founder hours may be less attractive than software generating £3,500 with 25 hours, but only if software retention and acquisition can continue.
Consider seasonality. Snowboards and many physical products have concentrated selling periods. Software subscriptions can smooth revenue, but they add continuous uptime, security and support obligations. Recurring billing is not the same as recurring profit.
Choose between licensing, spin-out and full pivot
A licence can be sensible when the system is mature, buyers need limited support and the original product business remains strategically valuable. A separate spin-out can work when different leaders can own each model and cash is sufficient for duplicated functions.
A full pivot is usually cleaner when the same founders are the bottleneck, the software opportunity is time-sensitive and running the original business teaches little more. Full commitment should follow evidence, not precede it.
Company, tax, intellectual-property and consumer obligations differ by country. If software was developed by employees, contractors or within another company, confirm ownership and transfer terms with qualified local legal and tax advisers before licensing or moving it.
Worked example: Snowline Commerce
Snowline Commerce sells specialist winter equipment and has built inventory software for its own shop. These figures are illustrative.
The store produces £42,000 monthly revenue at 38% gross margin. After £7,400 fulfilment, payment and acquisition costs, contribution is £42,000 x 38% minus £7,400 = £8,560. It needs 150 founder hours monthly.
Six independent retailers pilot the software at £320 a month. Software revenue is 6 x £320 = £1,920.
| Software cost | Monthly amount | |---|---:| | Hosting and services | £260 | | Support, 22 hours x £28 | £616 | | Sales cost allocation | £350 | | Payment and monitoring | £94 | | Total direct cost | £1,320 |
Software contribution is £1,920 minus £1,320 = £600, far below the store. Abandoning retail now would be reckless.
However, four pilots complete setup unaided, five renew after 90 days and three referrals enter the pipeline. Snowline removes two setup problems, raises the price for the next five enquiries to £420 and caps support at two hours per account. At 25 customers, forecast revenue is £10,500. With £3,900 direct cost, forecast contribution is £6,600 using 55 founder hours.
The team sets a switch point: 25 paying customers, 85% 90-day retention, support below two hours per account and nine months of household runway. Until all four conditions hold, the store remains open but stops adding new ranges. The switch is earned by evidence.
Make the choice in two 45-day stages
During the first 45 days, interview ten external operators and enrol no more than five paid pilots. Measure setup, outcome, support and renewal intent. Do not change the original business beyond what the experiment requires.
During the second stage, sell through one repeatable channel, test a price on five new prospects and model contribution at 10, 25 and 50 customers. On day 90, choose one of four paths: stop software, license narrowly, spin it out with named leadership or plan a dated full pivot. If the answer is “keep exploring both”, set another decision date and a strict capacity cap.
Related guides
Frequently asked questions
Does one profitable season prove the original business should stay?
No. One season proves that a specific offer, timing and cost structure produced profit once. Check whether the result included founder labour, unsold stock, returns and tax, and whether demand is repeatable. A seasonal product may still be an excellent cash generator while software is tested. It may also tie up working capital for months. Use the store's realistic forward contribution, not revenue or a single peak period, as the opportunity cost. Preserve it until software evidence is strong enough to compensate for what you are relinquishing.
How many software requests count as real demand?
Treat five paid external trials as a useful minimum for a small, self-serve product. The number matters less than independence and behaviour. Five requests from friends who never install the software are weak. Three signed enterprise pilots with data migration, named owners and agreed success criteria can be stronger. Record how each prospect found you, what they currently pay and who approves the switch. If all requests arise from publicity about your shop, test whether they continue when you sell the software directly through a repeatable route.
Should I sell the internal tool before making it polished?
Yes, if it reliably performs one valuable job and you disclose limitations. A paid pilot exposes missing assumptions faster than a long private rebuild. Protect customer data, make backups and define support before accepting live operational use. Do not place a rough system into safety-critical, financial or regulated workflows without appropriate testing and advice. Data protection, accessibility, contracting and sector rules vary by jurisdiction. A qualified local professional should review material obligations. Rough presentation is tolerable; uncontrolled operational risk is not.
Can I keep the original business as my first software customer?
Yes, but do not count it as external validation. It is useful for regression testing, process knowledge and demonstrating the result. It is weak evidence about onboarding, willingness to pay and support because the team already understands every assumption. Create the same account boundaries, invoices and support logs you would use for another customer, then compare them carefully with independent pilots. If external users cannot reproduce the outcome, you have built a bespoke operating system, not yet a marketable product.
What if software margins look higher than product margins?
Use realised contribution, not gross-margin stereotypes. Software avoids physical inventory but incurs development, hosting, monitoring, support, payment and acquisition costs. Early support can be especially expensive. Products can have lower percentage margins yet produce more cash because demand and channels are already established. Model both at conservative volumes, include founder time and run a downside case with slower acquisition and higher churn. The decision should follow cash generation and strategic learning, not the claim that software is automatically more scalable.
When should I tell existing product customers about the pivot?
Tell them after the decision has a service plan and date, but before it disrupts orders, warranties or support. Explain what will continue, what will stop and how deposits, returns and data will be handled. Avoid announcing an exploratory pivot that may be reversed, because it can weaken confidence in a still-needed cash engine. Consumer and contract obligations differ by country and sector. Review notice, refund, warranty and data-retention duties with qualified local advisers before closing or transferring the original operation.
Comments (0)