Is there any reason you can't just leave current the product as-is and keep running it on autopilot, with the only expenses being hosting and the occasional security vulnerability mitigations?
You mention you had 100K users - I'm assuming those are paying users. Could they not keep using the product (especially if they've already onboarded)? Or are there significant ongoing costs beyond hosting?
Products don't run themselves. Software must be upgraded because of security patches; if you don't keep up, after a while you can't because of skew. Customers require support when stuff goes wrong. Infrastructure changes from underneath you. SDKs change all the time. The law itself changes what is allowed or what is required.
Depends on what kind of product. I've built an app that I haven't touched in many years with about $1M in monthly revenue (extremely low margin) and it's all good. Yes, it hasn't had any security patches in years and it's just a matter of time before it gets hacked but no big deal. If shit really hits the fan I will just shut it down. Not offering any support. Customers know I don't add anything. Not sure what law would affect anything.
> I've built an app that I haven't touched in many years with about $1M in monthly revenue (extremely low margin) and it's all good. Yes, it hasn't had any security patches in years
You have a product bringing in $12 million per year (EDIT: I misread the profit remark originally, apologies to Kiro), and you can’t be bothered to do basic security updates?
> it's just a matter of time before it gets hacked but no big deal. If shit really hits the fan I will just shut it down.
You’re basically waiting to get hacked and your response plan is to just shut it down? And turn off $12 million in annual revenue because you didn’t feel like applying security updates?
Are you sure you mean $1 million per month in revenue? Because this doesn’t make any sense at all.
If this is true and accurate, you can at least see why this wouldn't apply to virtually anyone else running a high-profit software app, right? Especially not something like Friday.app which includes customer data.
taking a guess that your app is an API wrapper of some kind? the $ you move is basically through your account from customer to service provider on each call and you charge some low flat rate per month for access?
That really depends on the product and how you built it. With platforms like Google App Engine or Heroku, there's no infrastructure to take care of and the only thing you have to patch/update is your own code. Customer support can be an issue, but some products are naturally self-service. Or cheap enough that there's no expectation of quality support.
I do think you need to plan for this sort of thing if you want to be able to walk away (even for a short vacation). If your natural inclination is to start with k8s, you're going to need ongoing devops work in perpetuity.
> You mention you had 100K users - I'm assuming those are paying users
Definitely not. A company of that size with 100K paying users (so like $10M+ ARR) would be considered wildly successful. In their case it was probably a tiny tiny fraction of that.
Did you try asking users to pay? I.e. tell your users, you're shutting down unless everyone starts paying. It could be Kickstarter style in that X number of users have to put in their payment information by some date, or you still shut down. That way, there's no chance that some people start paying, but you still shut down.
Great question. I wish Pebble had done this before shutting down. I would have paid double for my pre-ordered Time Steel 2.
Wyze did this recently with their subscription, which they let you pay as little as $0 for. They forced anyone who didn't subscribe onto a lower tier, which only stored still images instead of videos in the cloud.
I believe couple of days ago Wordpress made some changes to their pricing and some people immediately reached for their pitchforks. We all have an inherent tendency to associate greed to any business asking for more or any(!) money.
I believe for that reason, for some founders it is, "you either die a hero or...."
One of the things I appreciated about Friday was the information you all provided about remote work, and the book you wrote named "The Anywhere Operating System"[0].
Would you be willing to keep the information you provided up as a statically hosted website so that the knowledge is not lost to the ether of the internet, accessible only via archive.org[1]?
I knew we needed to build a suite of tooling, as our goal was to be a "hub" for the most important stuff at work. In retrospect, we built too much product.
If I start another company, I will spend all my time focused on solving a very big pain-point with a few simple product.
With Friday, I wanted to keep the product simple, but the people we talked to always were talking about the "yet another tool problem" - so there was a desire to consolidate. How I interpreted this was that we needed to build the "suite" vs. spending all our time on one feature.
I could go on and on about what I would do differently, but I'm thankful for the opportunity and have learned a lot that will (hopefully) make me more effective in the future :)
This answer is so generic, but so apt. Everyone can throw around phrases like KISS or MVP or try to implement methodology like agile, but it's so hard to just identify _what_ you want (or need) to build.
We're looking at a major revamp/rewrite/refactor of our main product that previously had been built with the idea of being able to solve every problem our customers face. This decrepit, aging codebase has so many bandaid fixes for every conceivable "what if" scenario that it's just become unmaintainable.
Maybe the "yet another tool problem" can be addressed by making your tool easy to integrate with other tools, rather than trying to build a big all-in-one suite.
This was precisely our approach, but we built our own features for the "gaps" that we believed existed in the other products.
If an existing app was doing a decent job, we didn't want to compete with them. The issue is that we ended up arriving in this "dead-zone" where we didn't replace an existing tool and pull budget from an existing category of tooling.
It depends on if their target audience was small companies or enterprises. It may have made a difference, but it wouldn't have changed much for Enterprise customers. At BigCo (a global telecom[0]), it was much easier to add business from a vendor that we already had a relationship with than it was to purchase anything from anyone we didn't. It was also, of course, much easier to buy software/SaaS from one of the existing, boring, established vendors than lesser known/smaller ones. There was a mess of "Purchasing" involvement, legal, and everything else just to set things up so we could make the purchase. I don't know what Friday was for (had never heard of it until, today), but it sounded like it was something that would be company-wide, probably, so sneaking it in with an "expense card" isn't likely going to be defensible.
Then there's the "easy to integrate" side. Expect it to have to pass security reviews if it's SaaS of any kind and will touch any of our IP[1], and particularly detailed ones if it's very easy to "integrate with."
Azure AD Login was easy for us at "BigCo", but tied up several days of more than one grumpy security architecture team member's time with a variety of pen-tests that are required before they'll grant approval for it in our domain. That goes up exponentially to the impossible pretty quickly if it wants permissions to access things on our end via OAuth grants; even things that are typical (profile photo).
IT Architecture might get involved if there would be a need to make sure it worked with our systems, minimally to set up monitoring for it if we're making it available to a large amount of staff because if it goes down, we'll get a million calls into our 4-6 person (state-side by contractual/security requirements) Help Desk over something we can't do anything about and we're going to make sure we have a way to react to it when that happens. Someone's going to have to learn how to do any administrative/integration requirements, because configuration changes, we merge with companies somewhat frequently, and someone's going to have to make sure they know how to set it all back up, correctly, later -- just in case -- even when it doesn't make sense. Likely, BigCo want it to be used, so someone's going to have to write copy for an article for the company landing page explaining what it is, how it works and what problem it solves. There'll be other activities related to this when adoption doesn't take off. IT will have to dedicate some time to tracking usage to make sure we're getting ROI on it when the quarterlies come around and they have to justify every recurring expense, including the ones outside of the sticker price, all over again, and it's easy to trim off the add-on. Plus, they're often the ones who take the budget hit in the first place.
Legal/HR/The Business(tm) might get involved if employees can communicate, uninhibited, through it -- just like they do with E-Mail while they apply a flobbidy-jillion set of restrictions/disclaimers bits of nonsense around. We were not a Defense Contractor, we were just big, spread out and had a lot of employees. At scale, you end up with increasingly many who lack common sense, and a small fraction who still need to be warned about Nigerian Prince scams when one slips through. In a strange alteration of Rule 34, someone will upload porn to it or store porn on it if it is possible to store things on it. For the person who wants the product, it's going to be requiring phone calls, follow-ups, and general "going to bat for the vendor's product" against a hurricane-force headwind.
In fact, an add-on might be less likely to be purchased -- by BigCo, anyway -- because it doesn't do enough to pass the "Why do we need to tie up all of these people to bring this easy-to-integrate product into our environment when they can just use (some terrible excuse for a thing by comparison)?" The "we don't need that bad enough" answer is usually the case for Add Ons, and having a number of ancillary capabilities to distract with sometimes makes it more attractive to "the business" side of the above groups, which has the ability, often, to over-ride all of the rest of the "No"s going around.
At BigCo, an add-on requiring anything that the "good enough to somewhat OK" solution/solutions we already have kind-of sort-of covers doesn't stand much of a chance of being purchased. The one thing that can get in the door is the simple solution that solves a big problem, especially if there's nothing else out there that much of any part of it from any of the big vendors. I spear-headed a small handful of those. It has to be amazing and some reasonable combination of inexpensive, simple to maintain, highly available, non-critical if down (many, many things are unexpectedly critical).
[0] I worked there about a decade for 17 years, incidentally, most of it remote at an organization that was notoriously against remote work ... basically against a major service we enabled and often provided for other businesses. I worked as a software developer in the architecture organization working primarily on security-focused projects (figure that out) and had to go through this process enough to make my soul die a little.
[1] Basically, everything. At least, anything that would have a reason for the company to purchase it.
You mentioned in your post that your primary reason for shutting down was that you didn't find sufficient evidence that your product/service was meeting the needs of your users. Was there also pressure from investors to shut down due to this lack of evidence, or was this a personal decision made based on your principles?
I made the decision after a lot of reflection. We still had ~6 months of runway so I could have spent more time "pivoting" around.
The issue was that what I was hearing from prospects, customers, users signaled a bigger issue that could not be solved with a product tweak or two.
At the end of the day, I felt like the story I would need to tell a future investor (and new/existing employees) would increasingly become disconnected from the reality I was experiencing talking to customers/users.
I didn't feel at peace about it at all. I considered it to be a form of lying.
This is a great answer, I felt the same way about my previous start-up Ayvri.com
We make enough to cover our costs, so I've kept it going for the last 2 years.
As I kept looking for new ways for us to grow, and what pivots might work, one of our existing investors said to me [paraphasing] "we'll invest more if you know what to do with it, but I [the investor] think you should start thinking about what your next thing is. We'll invest in that, but there comes a time you need to move on".
That chat was really impactful, they were happy to see us launch a product, get customers, and try to build something really amazing (and we kinda did).
The same team that created Ayvri (most of us) have come back together to create https://soundmind.co - we haven't taken investment yet, but the same investors are ready to back us when we do.
Did you have that kind of support from your investors @Lukethomas?
I think many of us are so scared of letting our investors down, but I am super happy with the character of our investors, who supported us in the best way possible.
much respect. those are hard feelings to deal with especially given you had users, customers, investors, and a team to think about as well, none of which you can easily and cleanly ask for advice on this matter.
You mention you had 100K users - I'm assuming those are paying users. Could they not keep using the product (especially if they've already onboarded)? Or are there significant ongoing costs beyond hosting?