We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Autopsy of a slow train wreck: The life and death of a Django startup

00:00

Formal Metadata

Title
Autopsy of a slow train wreck: The life and death of a Django startup
Title of Series
Part Number
41
Number of Parts
48
Author
Contributors
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Everyone knows the story: armed with nothing more than a laptop and a dream, a couple of plucky geeks decide to take on the world: disrupting, innovating, and subverting their way to success. In just a few short months, they take a ramshackle collection of software and turn it into a money-printing factory that enables them to drive off into the sunset in gold-plated Lamborghinis. But it isn’t always like that. In fact, it usually isn’t. Venture Capitalists (VC’s) make their investments betting that 15 out of 20 businesses they invest in will outright fail, 4 will maybe get a payoff, and 1 will be a massive success. We always hear about the 1 - the Facebooks, the Instagrams, the WhatsApps. But we very rarely hear about the 15 that don’t succeed. And that’s only counting the VC-funded companies - there are many other companies that never make it past hobby stage, or live a short, privately funded life on the back of consulting income before being quietly shut down. This is a case study of one such a failure - TradesCloud. What went right? What went wrong? And what you can learn from TradesCloud’s mistakes if you’re contemplating starting a business of your own?
6
Thumbnail
42:19
Core dumpComputer animationXML
Numbering schemeRational numberSoftwareOrder (biology)Projective planeVirtual machineDifferent (Kate Ryan album)Right angleComputer configurationNumbering schemeSoftwareEntire functionOnline chatBitNormal (geometry)NumberExtension (kinesiology)Expected valueFlagDirection (geometry)QuicksortService (economics)Computer clusterLocal ringSign (mathematics)PrototypeData conversionPlastikkarteUniform resource locatorFerry CorstenResultantInsertion lossProcess (computing)Key (cryptography)Web 2.0Vector potentialSoftware frameworkFunctional (mathematics)Price indexChemical equationMathematical optimizationRandomizationMultiplication signCodeBoss CorporationElectronic data processingDesign by contractDivisorDecision theoryAreaProof theoryGame controllerAutomatic differentiationReverse engineeringFamilyRational numberAngleLine (geometry)Point cloudWeb page3 (number)MereologyPlanningSoftware developerVideo gameArithmetic meanScaling (geometry)Term (mathematics)Wave packetGoodness of fitComputer fileDigital rights managementTelecommunicationPhysical lawGreatest elementPerspective (visual)GenderExecution unitControl flowAverageBit rateStudent's t-testNear-ringValue-added networkTraverse (surveying)Pascal's triangleWebsiteTheoryBuildingPhysicalismGoogolProduct (business)Social classPay televisionComputerHypermediaComputer animation
SoftwareMathematicsBit rateTime zonePurchasingProcess (computing)SoftwareBit rateQuicksortTheory of everythingDesign by contractMathematicsCore dumpKey (cryptography)Video gameWater vaporBitOrder (biology)WordMereologyDigital rights managementPhysical systemTable (information)Product (business)Reduction of orderNumberPay televisionPoint cloudRegular graphMultiplication signDecision theory1 (number)Boss CorporationSimilarity (geometry)Service (economics)PlastikkarteResultantComputer configurationConfidence intervalVirtual machineBuildingFamilyNP-hardPattern languageSign (mathematics)Numbering schemeComplete metric spaceSoftware maintenanceWebsiteLoginMobile appTask (computing)Office suiteFreewareData conversionRandom matrixSystem callRange (statistics)Projective planeDifferent (Kate Ryan album)Social classOverhead (computing)Software testingStatement (computer science)SubsetComputer fileCellular automatonRight angleOperator (mathematics)Menu (computing)Propositional formulaEndliche ModelltheorieComputer animation
Computer configurationMathematicsIntrusion detection systemQuicksortDifferential (mechanical device)Decision theoryDisk read-and-write headConstructor (object-oriented programming)Social classInjektivitätNumberPoint (geometry)Power (physics)SoftwareData miningOffice suiteProcess (computing)Multiplication signWritingComputer fileReal-time operating systemDynamical systemFrame problemMoment (mathematics)Lie groupComputer configurationPerspective (visual)3 (number)Wave packetVirtualizationSound effectEndliche ModelltheorieFood energyMixed realitySet (mathematics)Different (Kate Ryan album)GodProjective planeFlow separationMereologySign (mathematics)Video gameThetafunktionStress (mechanics)Computer clusterStatement (computer science)Line (geometry)Software developerMultiplicationWhiteboardResultantLevel (video gaming)Lattice (order)Goodness of fitEntropie <Informationstheorie>1 (number)Marginal distributionDesign by contractWeb 2.0TrailCache (computing)Surface of revolutionPhysical systemCASE <Informatik>Computer programProgram slicingBuffer solutionMetropolitan area networkGravitationBitVideoconferencingOverhead (computing)DemosceneComplete metric spaceEqualiser (mathematics)Boss CorporationUniverse (mathematics)Conservation lawReliefServer (computing)System callInsertion lossPoint cloudMobile WebOnline chatComputer animation
XML
Transcript: English(auto-generated)
My name is Russell Keats-Bagee. You've probably heard my name before. I am an almost 12 year veteran of the Django core team.
I was president of the Django Software Foundation from 2011 to 2015. And as she said, along with Andrew Godwin, I hold the title of most Django Cons attended and having attended every Django Con US. And if you'd met me at one of those Django Cons in the last six years, or in Sydney speak generally, I probably would have introduced myself as the CTO and co-founder of TradesCloud.
TradesCloud was a software as a service company for tradespeople, plumbers, electricians, carpenters, people like that. TradesCloud was my startup. And I say was because in January of this year, my business partner and I closed the doors on TradesCloud, which shut down the service.
As an industry, we're really fond of promoting the glossy side of startups, that a plucky bunch of engineers can take an idea and a personal credit card and build an entire business empire, drive off to the sunset in gold-plated Lamborghinis. And yes, those unicorns and the gold-plated Lamborghinis actually do exist. There's even a couple of them in the Django community.
The unicorns, not the gold-plated Lamborghinis. But it's important to remember that these stories are unicorns. They're not the normal startup experience for most people. In the VC-backed startup world, the general expectation is if the VC firm invests in 20 companies, only one of them will actually succeed spectacularly.
Four will have some sort of exit that at least results in a breakeven financially. But 15, they expect 15 to fail outright with a significant or complete financial loss. Interestingly, this isn't something that's unique to tech. Tech does it at a much grander scale, especially when VCs are involved. But open any small business advice book,
the sort that is targeted at the plumbers and electricians of the world, and they'll warn you that 50% of businesses fail in their first year. And yet, despite the fact this failure happens all the time, we don't talk about it. We don't talk about why things fail. And as a result, many of the same lessons end up having to be learned over and over again.
Those that experience failure often feel like they're doing it alone because of the significant social stigma that's associated with failure. So this is my small attempt to restore that balance. In this talk, I'm gonna talk about TradesCloud, my failed business. TradesCloud was a slow train wreck. We survived for six years, almost to the day.
And we had plenty of optimism that success was just around the corner. But that never quite happened. But what was TradesCloud? What prompted me to dedicate six years of my life to it? Well, it started as a problem that I thought I could solve. If you find yourself needing a plumber, how do you pick one? Well, 15 years ago, when I first had the idea for what became TradesCloud,
the best option was opening a phone book and looking for the brightest, shiniest ad, maybe arranging a couple of quotes, picking one basically at random. If you were really lucky, you might have been able to use Google, more likely in the US than in Australia, but you were still looking for what was basically the shiniest ad. If they turned out to be good, well, that's great, but you probably won't need another plumber for a while,
so that knowledge is almost useless. And if they turned out to be awful, well, you can't warn anyone off either. There has to be a better way. And of course, I did nothing about it. I say nothing, I did start tinkering around with this web framework. You may have heard of it. It's called Django. I originally got involved in the Django project
because I wanted to add aggregation functions to the ORM so that I could compute average ratings of plumbers. And in 2008, I mentored a student, Nicholas Lara, who added aggregation as a summer of code project. So, success. Then in late 2010, I met up with a former boss
for a drink, and he tells me about his brother. His brother owns a pest control company in Australia, or in Perth, and he had the same problem, but from a different angle. I'm looking for tradespeople in my area that can be recommended. He is a small pest control company that wants to compete with the big players with the shiny ads based upon the quality
of the service that he could provide. And so, Trades Cloud was born. We had an idea. At the time, it actually wasn't even called Trades Cloud. It was called Clever Pages because it was going to be a clever Yellow Pages. And in my spare time, we started hacking together a proof of concept. That was my first mistake, and the first mistake that most tech-oriented people make.
As much as Django sells itself as a rapid development framework, and it is, any non-trivial project still takes up time and effort. And I spend a couple of months of spare time hacking together a proof of concept. German military strategist, Helmut von Moltke, once noted that no battle plan survives with first contact with the enemy.
Or in non-military terms, Scottish poet, Robbie Burns, the best-laid schemes of mice and men going after Gley. And so it is with business ideas. All the time that I spent working on that initial prototype, I could have eliminated if I'd actually gone to the trouble of speaking to a plumber first. Just because we had an idea, and I could implement the idea in software, that didn't mean we had a good business idea.
It meant we had a good idea for a hobby project. And the difference is crucial. A business is an idea that generates revenue. A hobby project may be fun to work on. It may even be useful for other people. But if you can't sell something, if you can't pay the bills with that revenue, it isn't a business. And conflating the two ideas is a major problem.
What we should have done first is validate the idea and then build it. But we did need to do that, and when I finally had something to show off, my business partner opened the local newspaper, picked a bunch of local plumbers, and called them in an attempt to sell this grand new idea that we had with our prototype. And he called 10 plumbers. Five of them suggested that he place the idea
in an anatomically implausible location. Four of them had their secretary provide exactly the same advice. But one plumber did sound interested, and he said he wanted to have a chat. This was mistake number two, or at the very least it should have been a warning flag. At the end of the day, a business is about selling something. Selling a physical product, a subscription,
selling a service. But whatever you're doing, you're selling something. And in order to sell something, you have to have customers. If all your prospective customers hang up when you call, you have a problem. You don't have a sales channel. It doesn't matter if you've got a machine that turns lead into gold. If you can't get that idea in front of people who are going to buy your product,
you might as well shut up shop right now. The fact that it was very difficult to get plumbers to answer the phone should have been a warning sign that our prospective audience wasn't going to be easy to crack even if we had a perfect technical solution. But we persisted, and we had a chat with the one plumber who would actually speak to us. And we did our pitch, and he said, nope, not interested.
But if you can make that pile of paper disappear, I'll give you as much money as you want. This was a conversation that set the direction of our company for years to come. Was this a mistake or a success? Well, that's a little bit hard to judge. There is an extent to which we changed direction because it was the only direction that seemed open to us, which in itself was a bad move. But it was also a very lucrative direction,
so maybe it's a wash. What we identified in this conversation was a significant business problem, a business process that was being performed manually. It took three hours a day to perform, and we identified a simple and reliable way that it could be automated. We identified a couple of other business processes
that we could automate and a way to report on some key performance indicators in the business as a result of doing that data processing. And we identified a path forward where we could use mobile technology to improve process management, communication, and overall business outcomes. By the time we were done, we worked out how to immediately free up one full-time employee with potential for a lot more.
So in theory, as long as we charge less than the cost of that employee, about 50,000 Australian a year, the business owner would be ahead on paper. Our costs were next to nothing. Our newfound customer told us these business processes were due to one specific contract that they had. There were many other people on the same contract, so it should have been easy to take the same software
to everybody else on the contract and profit, right? Well, okay, let's keep it simple. Offer them a 50% saving on what they were originally spending, and do a little bit of fancy footwork to reverse engineer a good explanation of why that was what we were charging. Just start making $25,000 per year per customer, right? Well, no. That was mistake number three.
Mistake three is that we didn't take into account the human factor. In theory, charging anything less than $50,000 a year should have been, rationally, a no-brainer decision. Easy sale. But we were selling to humans, and humans don't ever behave rationally. There is an almost bottomless body of research
about how bad humans are at evaluating economic consequences and decisions. And so, when we walked in the door of a prospective customer, we did our pitch, and they were almost universally blown away. And then we told them the price, and they went back to describing anatomically implausible locations again. Why? Well, first off, humans aren't rational.
A sale of that size, $25,000 a year, isn't easy. Ask a plumber to spend $100 a month, they know they can afford that. It's probably less than what they spend on coffee in a month. But ask them to spend $2,000 a month, that's a lot harder for them to justify. That actually starts to make a dent in their bottom line. So they're gonna take some convincing. They're gonna want some proof that it actually works,
that it's actually gonna deliver the benefit that you're promising. Secondly, we were selling software. While we were completely honorable and completely truthful, and were able to deliver everything we promised, and our software made birds suddenly appear every time we were near, we weren't the first IT salesperson to darken their door.
And we, collectively, have a part of an industry that for 40 years has systematically over-promised and under-delivered what software can do for businesses. That's something you need to overcome. Third, we were selling software. Who here is currently holding a phone worth a couple of hundred, maybe even $1,000?
Pretty much everyone in the room. Now, how many of you give more consideration to whether you should buy a 99-cent app than you did on the decision to buy the phone? Almost exactly the same subset. That's the problem selling software. Multiply it 1,000 times when you start dealing with a non-tech audience. We have been conditioned to expect
that physical, tangible things are expensive, but software, that should be cheap, better still, free. As a side note, this is one of the major problems we face funding open-source projects as well. That's a subject for a completely different rant, one that I've had many times before. Come see me if you want that rant.
Lastly, we were dealing with personal relationships. If we walked into a small plumbing business to speak with a manager, there was an odds-on chance that the bookkeeper or another significant employee in the business was the wife of the manager. And if you start talking about the benefits of being able to cut one administrative employee, you can guess how well that conversation goes.
And even if it wasn't a family member, people don't generally want to fire people. They do it if it's necessary, but they like the idea that they're building this big family. Mistake number four happened as the result of an unfortunate coincidence. After closing our first sale, we got that customer to give us an introduction to some other possible customers, and he gave us the best options first. So our first two sales were both $2,000 a month.
Our third sale was only $500 a month, but that gave us the confidence that we had something that we could sell to both medium and small businesses. We closed three sales in rapid succession. We had $4,500 a month in revenue. Sales were really painfully easy to close. We thought we'd found a money printing machine. And then we hit a wall.
The next few sales calls we made went nowhere. Never a hard no, but lots of eh, it's about price. We'll have to think about it and balance it up, and my wife's gonna have to weigh into this. We confused initial success with a pattern that was going to continue. After three sales in less than a month, we essentially didn't close another sale for eight months.
And that's not a good sign. Now, arguably, we did get bitten by circumstances there. When you have lots of early success, it's easy to think that that success is gonna be ongoing. It's very difficult to be objective, and that's what you need to be. If you can't consistently close sales, if you can't reliably predict your close rate, you have a problem.
Mistake number five, though, was completely our fault. We completely failed to do basic math. Our value proposition, the business process that we had optimized, existed because the process is required by one particular home maintenance contract. Our pricing scheme was simple. We charged $1 per job completed. Our initial customer, they did about 2,000 jobs a month,
so we charged them $2,000 a month, which is great, because it also happened to be almost exactly the 50% savings target that we originally identified. What we didn't do was add up how many jobs there actually were in the system. And it turns out that if we had managed to close every company on that contract, we still would have only generated $12,000 a month in revenue,
which sounds like a lot, especially when your costs from hosting a cloud piece of software that doesn't have huge traffic requirements. But our costs weren't low. We also had two founders who were full-time and needed to be paid. Our burn rate, if we were fully paid, was closer to $22,000 a month.
And this led to mistake number six. We didn't have, my business partner and I, didn't have a serious pricing discussion until it was way too late. Misled by our initial success, our pricing was essentially determined by taking our burn rate and working backwards, not forwards from what the market would bear. My co-founder and I would end up having regular discussions about pricing, but all those discussions happened
against the background discussion of how are we going to make payroll this month, which is the wrong time to be having that discussion because two important options, drastically reducing the price and shutting down the company, are effectively off the table. So we had a product that was too expensive to sell, a market that wasn't big enough. Now the good news was that the paperwork reduction niche
that we'd found wasn't unique to that one contract, but there were many other similar contracts with very similar paperwork requirements, but we'd found the 1,000 pound gorilla in the market. Other contracts were similar and the paperwork processes were subtly different and needed to be customized for each contract. And that wouldn't have been a problem if we hadn't made mistake number seven.
We never established a sales channel. We got our first sale almost by accident. We bumped into a customer who gave us an opportunity. Subsequent sales came mostly by word of mouth. Word of mouth is an incredible sales channel if you can get it. But as a result, we never cracked the most important problem. How do we sell to someone who hasn't heard of us?
How do we get in the door? How do we establish trust? And as a result, our sales were essentially constrained by the personal networks of our existing customers. Now Perth, where I come from, is a small geographically isolated city. When we had exhausted the personal networks, we hadn't learned the most important thing.
How to sell our product to someone who didn't give us a personal introduction. Joe Smolski once noted that there's no software product priced between $1,000 and $100,000. This is because a product that costs less than $1,000 can be bought in a credit card. But if software costs more than something that can be hidden on an expense statement, you need to have sales people and that means you have to pay them
and their commissions and to pay for the steak dinners and the drinks that they use to close the sale. We had a product that was squarely in this dead zone. It was too expensive to be a casual purchase but not expensive enough to support the sales process that it needed. TradesCloud had a serious problem. Once we closed the sale, we had almost zero churn rate. The only customers we ever lost
were because the business actually shut down or they dropped the contract where we offered any sort of commercial advantage. What we didn't have, what we never really established was a good way to prove to new customers that we were indeed that good. There wasn't a good or easy way to trial TradesCloud. We were managing processes that were at the core of a trades business. Those processes have to work
and they can't be duplicated or doubled up because you're doubling the paperwork, you're doubling the overhead. So there was no way to sort of stick your toe in the water. You had to jump in or stay out. And since we had a huge price tag, most people were conservative and said no. If they got a recommendation from someone they knew, it was a little bit easier but if that didn't exist, we had a problem.
In order to close a sale, people have to believe, really believe what you're telling them. It has to be obvious and undeniable that you will give them the benefit you're promising or the cost of trying has to be vastly less than the cost of software itself. In our case, even if we dropped the price of our software to zero, we still didn't have zero cost
because the cost of institutional process change associated with adopting a new piece of software that represents the core of business operations, that's huge. Our best salesperson was completely accidental. He wasn't even our employee. He was the employee who changed employers about every six months.
He was in upper management. He had a reputation for getting things done and turning companies around and so he kept getting poached. And he'd seen the benefits of TradesCloud at one contract so when he got moved to the next one, he'd say hey, how about we introduce TradesCloud? Hey, how about we introduce TradesCloud? And because he was known around the industry and he'd been hired because he knew what he was talking about, his word was extremely valuable.
When he said this is good, people believed him. His word was trusted. But even when we did make a sale, the mistakes didn't stop. Mistake number eight, we didn't pay enough attention to onboarding new customers. A sale for a product, particularly a subscription service product, isn't closed when the contract is signed or when the user gives you their credit card. It's closed when the person who uses the software
has accepted it into their daily lives because that's what prevents churn. If you're selling a small personal tool, the person who buys it and the person who uses it, probably the same person. But in our case, the purchase decision was very rarely made by the person who actually had to use the software on the ground at the end of the day. And you have to get those people onboard too.
If anything, they're more important because they're the ones who are gonna make the boss's life a living hell if the software that they've been forced to use isn't doing the job. Or worse, is doing the job too well. Over and over, we saw internal sabotage when TradesCloud was rolled out in companies. People would simply refuse to change processes
and they would find any excuse. Oh, the software doesn't work, so we had to go back to doing it manually. Oh, TradesCloud was down again. It was like I couldn't access it all afternoon. And after a month or two, the boss would then call us and say, what happened to all the benefits you promised? They said you were down all last Friday. And I was like, no, we were not down all last Friday. Your guys weren't hitting the website.
And by the way, here's the logs of all the hits we had from your employees last week. But that didn't matter because they only got the benefits if they used the software. They weren't using the software, so they weren't getting the benefit, so they weren't happy about paying for it. What we learned the hard way is that you have to sell the business owner, but you also have to sell to the users. If you're dealing with software
that is a key part of business process, change management is key. You have to show the people using the software how your tool helps them do what they currently do by hand. You have to show them that their jobs aren't at risk. The first employee whose three hour a day task we replaced, she wasn't fired. She was redeployed inside the business.
She went from doing a mindless office task for most of the day, and she could start expanding into other parts of the business. About two years after we first deployed TradesCloud, she was running accounts and payroll in that company. But despite all these mistakes that we'd made, we were able to stumble along and we were completely funded, or self-funded for almost two years. Yes, that did mean burning a lot of personal funds.
And my co-founder doing a bunch of consulting on the side, which should have limited how much time he could spend doing sales, which was its own set of problems. But that's just part of the startup experience, right? Well, maybe it is. But in retrospect, mistake number nine was an entirely personal one. I shouldn't have lost as much money on the experience as I did. I knew what I considered success criteria,
the gold-plated Lamborghini sitting in the driveway. But I never considered what my failure criteria would be. After two years, I'd reached a point where my personal financial runway was running out. TradesCloud either needed to start paying a full-time wage, or I wasn't gonna be able to continue. And that pivoted the business. Fundraising is a full-time job.
Everything else goes on hold. Sales, support, development, everything. We tried to get VC investment, but the VC scene in Australia, particularly in Perth, is pretty bad. Eventually, we managed to secure a $250,000 cash investment from a colleague of my business partner. We got a bit of matching funding through an Australian government R&D program. And that gave us another two years of runway.
But the way we were able to secure that runway was by changing our tactics. Instead of going after individual plumbers, we started going after the head contractors, the multimillion dollar facility management companies that were imposing this paperwork overhead on the smaller companies. And we were able to sell them a really great story. The companies are all really, really competitive. They're all looking for any advantage they can get to slice another half a percent profit margin out of things.
But they're also technologically laggards, because they are big, established companies. So we were able to walk in and promise them a mobile-enabled workforce and real-time employee tracking and enforced health and safety provisions and practices, all sorts of things that made them really excited, because they could use those features as differentiators against their competition.
But, and here's mistake number 10, we forgot who we were and who we were selling to. We were selling to multimillion dollar companies. The reason these companies are technologically laggards, they're conservative. They don't take risks. There's no incentive for an individual employee at a multimillion dollar company to take any risk.
And so, they consistently make safe decisions. When they adopt new technology, they don't just pick something. They put it out to tender, and they get multiple bids. And then they invite the bidders to come into the head office and interrogate them. And eventually, after six months, they pick someone, the safe option. We got into a tendering process with almost every major facility management company in Australia.
The tendering process almost always started, because we pitched them the idea of providing Trades Cloud to their subcontractors. What they heard was provide software to our subcontractors. And so, at the end of a six month tendering process, multiple trips over across the country on flights and staying and day long interviews and meetings and writing tender papers and so on.
We were told, every time without fault, we prefer your technological solution, but we're gonna go with your competitor because you're just too risky. A two person company was too much of a risk for a multimillion dollar company to trust. Nevermind the fact that the minute you sign a multimillion dollar contract, you cease being a two person company.
So, after two years of trying this tactic and being turned down by pretty much every facility management company in Australia, the money was running out again and I built up a cash buffer again. In between failing to sell to multinational companies, we'd accidentally found a little bit of success selling to smaller facility management companies and large construction companies. And the good news is that these companies were big enough that when they bought software,
they wanted to customize to exactly what they want. So, as well as the $2,000 a month they were willing to pay, they'd pay 40, $50,000 up front so that everything matched their requirements exactly like they wanted them. And on the back of that change, we got a loan from our investor and between making some more personal sacrifices, we got that cash injection, we were able to stumble along for another 18 months.
This was mistake number 11. We didn't take the hint. Each one of these points where we took investment was potentially a point that would have been a natural place to shut down the business and in retrospect, we should have. The writing was on the wall. The simple truth is if you can't close sales, you do not have a business and yeah, you can stumble along hoping you're gonna find
that missing sales ingredient but that takes resources, it takes money, it takes emotional capital as well. One of the reasons the failure of TradesCloud was personally so galling to me is that it didn't fail for any reason that I would consider to be my fault. From a purely technical perspective, we were significantly more reliable than the multinational companies we were integrating with.
We delivered new features in timeframes that our customers considered inconceivable. When I went in and did demonstrations to these multimillion dollar head contractors, they expressed doubt that we could actually do what I said we were doing right up until the moment that I showed them doing it live but none of that mattered. TradesCloud failed ultimately because we couldn't sell what we had
or at least we couldn't sell it in quantities that enabled us to cover our costs and when you're there giving your all and doing things that are being called magic by prospective customers and you're still failing, that's hard to internalize and when you layer on the fact, layer on top of that, the fact that I'm a husband and a father and the sole income for the family, that introduces all sorts of guilt and fear into the mix
and then you take all that stress and add in all the long hours and the weekend work and the desperate hope that this will be the thing that saves the company and you start to understand why two years ago I had a major depressive episode. Mistake number 12, I lost sight of the fact that quitting is always an option and quitting doesn't mean failure.
If after two years I had taken an honest audit of where we were as a company and said, you know what, this isn't working, I'm out. I would have had four years of my life back. That's four years I could have sunk into a different project but I didn't pay attention or enough attention to my signs. I conflated the success of this company with my own personal success
and I lost sight of the fact that at the end of the day, it was a job. It was meant to provide some income, some intellectual engagement and if it wasn't doing that, walking away was always an option but I never really considered that seriously. Why not? Well, that's kind of mistake number 13 and it was another personal failure.
I didn't stand up to my co-founder as much as I should have and as a result, we wasted a lot of time and effort, in some cases money. Now, I have to be clear if only because there's a chance that Mark might actually see this video. I'm not blaming Mark here. Mark is a great guy. He's extremely talented. He's got absolutely no shame at fronting up the companies thousands of times bigger than his and telling them how they should be doing things.
He opened doors that I wouldn't even consider knocking on, let alone opening. He was a real asset to the business. The failure here was a personal one and it was mine. We didn't go into TradesCloud as complete equals. Now, okay, sure, we were 50-50 partners on paper but when I met Mark, he was my first boss out of university. I worked for him for four years as a relatively junior employee
and a lot of that power dynamic remained. I let him do a lot of things because well, he must know what he's doing, right? I caved on decisions because I could see his side and he was more experienced. And unfortunately, or fortunately, Mark is a great sales guy. He can make you believe in things and he made me believe in TradesCloud but that's a double-edged sword. It got me through all sorts of lows
but it also meant that I believed in things when I probably shouldn't have been. I should have put my foot down and said no more a lot more often than I did both for the benefit of the business and for my own mental health. And so when the money ran out for the third time, neither Mark nor myself had the energy to continue. We had a couple of last minute Hail Mary options
that we thought might have saved us but one by one, they fell through and in the end, we were eventually able to pay back the loan to our investor but his equity investment was essentially lost and in January of this year, we closed our doors for the last time. And that's the TradesCloud story. Now, I do warn you, the plural of anecdote is not data. This is my story. There are many stories that are like it
but this one is mine. I don't profess to having any particular business insight. I just know that TradesCloud didn't work and these are the 13 reasons that I can identify why. In the aftermath, I've had a lot of people, many of them in this room who have reached out and given me a virtual hug or spoon and many of them have asked me if I was sad to see TradesCloud go
but frankly, the emotion that I had was relief. On January 31st, 2017, I slept like I hadn't slept for six years because I knew I wasn't gonna be woken up at two o'clock in the morning by a server alarm and I knew I could sleep in because I wasn't gonna get a support call at six o'clock from someone who couldn't find the on switch on their phone. The fact that I wasn't even slightly disappointed
by the loss of TradesCloud for my life, that's the biggest sign for me that I waited far too long to walk away. The good news though, is that the process of running TradesCloud hasn't burned me out completely. It was an amazing learning experience and I landed on my feet at JagoCon US last year. I put my name up on the jobs board saying I was potentially looking and it had been there like all of half a day
before my good friend Andrew Pinkham approached me and said, are you that Russell Keith-McGee? The other silver lining is that the TradesCloud experience drew my attention to problems in the world of mobile development which has influenced the path of my new toy, Bewear. And I've been busy trying to work out how to turn Bewear into something.
But this time, I'm a little older, I'm a little grayer, hopefully a little wiser, and I should have a better idea of what I'm looking out for. If you wanna talk about Bewear and that story, come and have a chat. I will be around till the end of the sprints working on Bewear, thanks to Revolution Systems. We have a stash of contributor coins. Oop, we're down there, nice Chinese.
So if you own one or you'd like to earn one, you can get one by contributing to Bewear. Come and grab me. Thanks to GitHub, we also have yak herder coins for people who help other people get involved with the project. And with that, that's all I've got to say. Thank you.