I'm curious – why couldn't you raise more? Like you said, a couple million is nothing in today's market. You have a real product, real users. Why did no one give you another round of funding?
First off sorry to hear that the Friday journey is ending here.
This is a really interesting response to me - some peoples gut instinct is “keep going until you figure what that something is.”
Im curious if you could elaborate here about what story you found on the ground and what made you believe that you were quite far from building the right product?
I get the same question every time I shut down something. No, I don't want people to see my embarrassing spaghetti code. With that said, I haven't shut down any critical products so it has been more like "would be nice if you made it open source" but my point is that there are many non-obvious reasons not to open source something.
Another is that I've randomly put credentials in the source code that I don't want leaked (again, my code is an ugly mess full of shortcuts and hacks). Yet another is that it would be impossible for someone to host themselves because I don't even understand it myself.
I get your point, because I'm "baking" some code I would like to open source one day and cleanups are in order.
However, when you're closing shop dumping the code out there for others to figure out how to run, even if you can't help them set up an env from scratch still helps. I also think we need more spaghetti code out there, would help teach new developers how to maintain and refactor "legacy" code.
The credentials in source code thing, I thought by this time would have been a "solved" issue, but I guess some people still yolo it :). Credentials in source code, are the equivalent of password on post it notes ;)
> Credentials in source code, are the equivalent of password on post it notes ;)
While not the best security, post it notes are immune to hacking and really hard to leak without a home intrusion.
Credentials in source that won't be shared is a pretty efficient hack. Often it happens by mistake - eg. when you hard-code that credential into a bash script during testing when you're trying to curl a new API and then push it by mistake after a coworker asks for you to share your progress on a new branch for review.
Shameless plug: if anyone needs to get credentials out of their code, EnvKey[1] makes it really easy (disclaimer—I’m the founder.) We just launched our v2, which includes a free cloud tier for up to 7 users, or you can self-host it. Give it a try and sleep better at night :)
Agree, I think the fear of someone finding a vulnerability and the original author being held accountable is high enough for almost nobody to open source their code.
If the company publishes the code, then closes, what's the harm? Any hard-coded creds would be invalid and any license violations wouldn't matter because there would be no company.
I'd love to hear about these "non-obvious" reasons, because I can't say "I'm embarrassed by my code" sounds like a good excuse after convincing people to move to your platform, charging them a subscription for it, then kicking them off with only 60 days notice.
And "I don't think others could figure out how to host it" isn't a reason not to release. It costs nothing but a pretty insignificant amount of time to publish it, so even if it's "impossible" to re-host (and history would say it's not), I really don't see a reason not to let people try.
I think you're mistaking me for someone else. Otherwise I don't know where you got 60 days from but it's not true - I give them 0 days notice. I also never convince anyone to "move" to my projects. I tell them from day 1 that they should use it at their own risk but for some reason people insist on using it regardless. In fact, if anything I try to convince them not to use my platform (me: "it's really bad and early" they: "it's ok" me: "it probably won't work" they: "it's ok"). So don't hold me accountable for things like that.
I see I wrote that very clumsily, sorry. I was talking about the Friday shutdown and replied to your comment as a general response to the reasons for not releasing code. Obviously personal projects or anything else you don't market and sell/rent out to people are completely different. fwiw, I'm quite similar with my personal projects, but if I took people's money for something and then had to shut it down, I'd do everything in my power to enable them to keep using it without me.
A software developer who is trying to sell products to businesses, software on which those businesses would rely, admits to creating an "ugly mess" of "spaghetti code ... full of shortcuts and hacks" and to embedding security credentials in the SCM.
I wish you no ill will, but goodness, talk about an anti-ad for your products.
Creds should be outside the SCM, and there are varying levels of "best practice" - vaults, environment variables of CI servers, text files with strict permissions outside the SCM, etc.
You would be surprised how many businesses run on equally bad or worse code. At least I'm honest about it.
Your tips are true but not very helpful. I know it's bad or I wouldn't call it an ugly mess. I have better practices nowadays regarding credentials but all my projects always spiral out of control some way or another. If it's not this it's something else but I'm never proud of my code.
As a freelancer/indie dev when someone asks me to share a codebase I wrote, I get worried.
Freelance projects are bounded by NDA. And my personal projects are bounded by shame.
If I am worrying about credentials, code cleanliness, documentation etc I wouldn't have any time or energy to turn my stream of free flowing ideas into code.
That's a terrible way to think and oddly an excuse I hear a lot. If that's the case, there would be no OSS software, every OSS starts off crappy and full of bugs and usually not even close to finished.
The goal of OSS is not to show off your skills as some elite programmer.
> every OSS starts off crappy and full of bugs and usually not even close to finished.
I think the quality/bugginess isn't as much of a factor as the fact that the codebase was not written with the intention of becoming OSS. Things like lack of documentation, hard-coded secrets, inflexible hosting/deployment, etc. are difficult to account for after the fact. And if you ignore these things and just "throw code over the wall", then virtually no one will even look at your code, let alone use it. Kind of a waste of time just to indulge a few self-righteous commenters on some message board, if you ask me.
A lot of OSS software was written with the intention of being open-sourced, so many of the things that make open-sourcing a previously-closed repo difficult are considered upfront.
Easy to say, harder to do. I get anxiety just thinking about it.
What's the goal? You make it sound like I have an obligation to do it for some utilitarian reasons, while in reality maybe one or two previous customers would use it while migrating to something else. It's crap software with much better OSS alternatives already.
It either dies with me or dies as an abandoned repo I need to be ashamed of.
I am just jumping in not to pressure you specifically to dump the source but in my experience in quant finance and music software development (hobby), I see kind of a tragedy of the commons especially in finance. If more people made their source available upon winding down a project it would drive down costs in the entire industry and indeed the whole tech ecosystem.
Reimplementation saps alot of productivity from the economy.
Someone in the business likely is in-scope for licensing decisions and on the facade this sort of decision probably looks noble and altruistic. To answer your question, "is it possible" - yes.
Ethically, however, it doesn't really check out for me. If the software is a core part of your business and the (or one of the) primary reasons an investor has joined your business then it's at the very least a bait and switch to make such a decision without their involvement. To a big VC or private equity firm this may infuriate some but have little monetary impact; at a much smaller firm this could be highly damaging.
I'm also fairly certain that whatever harm comes from this decision would put the CEO in personal liability, potentially all the way up the decision chain.
The issue isn't who gets to make "day-to-day business decisions" (i'm not sure how you characterize licensing source code as open source as such, but it doens't matter).
The issue is that shareholders literally own the property owned by the company, that's what it means to be a shareholder. Including intellectual property.
Announcing you are shutting down a company, and then, without board approval, the CEO giving away what assets remain... is super sketchy and probably illegal, probably stealing from the shareholders (or even more likely other creditors, if they exist), who would probably like to partially recoup their losses from sales of any remaining assets. What those assets are you are giving away are, say, a fleet of cars, or the intellectual property of source code, legally the same.
Imagine if a car service company announced it was shutting down, and then gave away all it's cars, instead of selling them in an orderly fashion and distributing profits to anyone who was owed money, including creditors and shareholders.
Given that with a company going out of business a lot of people are going to be losing money and wanting to get what they can out of any assets... the time to release as open source is really before you go out of business.
Well giving away all company IP for free isn't a "day-to-day business decision". If the company is shutting down the assets go to the investors, and they can choose what to do with it.
His story on https://www.failory.com/interview/friday suggests it's making 10-25k MRR. If he can run it on autopilot with just occasional bugfixes and support queries, he's still got a very nice "lifestyle business" that will probably keep yielding for a couple years.
I think your idea fails for at least a couple key reasons. First, a lot of customers will probably migrate to competitor if they know the product isn't in active development anymore, so the MRR will likely drop over time. Second, investors are not going to just give up their equity while the owner directly profits off their investment, there would have to be some type of buy-back, and the owner probably doesn't have that kind of money.
25K MRR is enough to support a team of maybe 1-2 people, which probably isn't enough to answer all their customer queries, keep the infrastructure up and running and continue marketing efforts to ensure revenue at least doesn't go down year to year.
there are certainly numerous success stories. i have friends who "recapped" and went on to be quite financially successful, but that is likely the exception, not the rule.
I am considering it. I have a fiduciary duty to try to fetch a fair value for the assets, but if no one wants the codebase, I'd consider opening it up. Still TBD as I just announced this a couple days ago :)
That makes sense. I was mainly wondering for old/past companies that don't end up selling their code base versus for Friday specifically. But maybe thats the answer, most companies end up selling their codebase and it does get reused. Good luck on everything!
Hey, I'm the founder. We worked really hard to not position ourselves as a task management tool, but instead, a tool that integrates with existing systems.
Task management is extremely competitive and we didn't want to play in the space. With that being said, we viewed our job as an interface to "glue" the work together, no matter the source.
> we viewed our job as an interface to "glue" the work together, no matter the source.
Glue and integrations with third-party systems are important, for sure, but were there any other jobs that customers were expecting more of, rather than this one?
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.
tl;dr - I wrote a 200 page user manual for team leaders and CEOs to navigate working from anywhere and open sourced it online for free: https://friday.app/anywhere
I'm Luke, the founder of Friday.app. 8 years ago, I first read Remote by 37 Signals and it's what caused me to start working remotely back in 2013. At the time, the book laid out a case that more organizations should offer remote work.
Over the years, I worked for a few different distributed companies in a variety of roles. I've seen what works and what doesn't. Now, I run a software company building async tools for distributed teams. I've also spent years digging through research on distributed teams, asynchronous communication, and more. Basically, it's been a huge area of focus for the past 8 years.
When the pandemic hit, people were CONSTANTLY asking me if I had any book recommendations. Unlike 2013, people didn't need to be convinced about the benefits of working from anywhere, which Remote did a great job covering. Now, they were looking for a playbook on how to implement this stuff in a way that tapped into the benefits of distributed work - primarily the flexibility.
I never imagined writing a book, it's not really my forte. But after seeing so many companies rollout terrible policies/practices that made working from anywhere worse than going into the office, I decided to throw my hat into the ring.
The book teaches high-level principles and then dives into specific practices and playbooks, like:
- How to go async-first
- What meeting should be an email? What email should be a meeting?
- How to hire people you haven't met
- How to quickly onboard new teammates
- How to feel connected & stay accountable
These are all questions I hear all the time. This book is heavily focused on shifting towards an async-first environment, because I believe this is the #1 transition an organization needs to do.
Anyways, the entire thing is available for free online. There's an audio version too and spent quite a bit creating illustrations for each of the chapters. If you want a hardcopy, I'm offering that at cost on Amazon (I make 1 penny for every book sold).
I hope this helps you all. I'm just tired of seeing people act like this is all brand-new, when in reality, there's a mountain of evidence and best practices that can save you a lot of headaches.
async is not a losing battle. Trying to handle async communication processes manually is.
Right now, most async communication processes (like status updates or daily standups) involve a ton of manual effort to make sure that people share this information.
I strongly recommend creating systems and using automation as much as possible here.
This thread basically enumerates why I started my company. Manual control of workflow and keeping up to speed is at best a waste of time. I want my _Computer_ to do the boring repetitive crap.
Most workplace communication tools are focused on improving the efficiency of communication. I think of this as laying "pipes". It's never been easier to jump on a video call or ping someone in Slack or email. What happens is that the information/communication doesn't flow on a repeatable or predictable basis.
What people really need when remote is a way to help create and automate a series of communication habits/workflows, so instead of hunting around or perusing Slack to understand what's going on, the information flows to you. Like a series of communication pumps.
Right now, most managers manually collect this, which is an epic waste of time.
Self plug, but after 8 years working remotely and constantly running into the workplace chat firehose, I've built software to help automate any routine update at work (https://www.friday.app).
