Your framing seems somehow backwards. Based on the other article[0] Nate and David bought out the business from Blue Systems. Jonathan (previously employed by Blue) proposes a co-op model, the new owners say “no thanks, we’re good”. Jonathan is surprised at this, storms out, detonating all the bridges on the way.
It’s commendable to want to start a “cooperative socialist paradise”, you can pitch it and see if there’s interest with others. But it’s totally OK as well for others to not want to join that, and go the more conventional way.
It sounds like Nate is set on starting a conventional company, and that should be fine. The previous company apparently never made financial sense so it also doesn’t work to just continue that model directly and so things and people get cut. It can be both hard to communicate and to hear, doubly so when you’re emotionally invested. That’s why IMO it’s important to separate your self worth from your job at some level, for your own mental wellbeing.
We bought our .com after we became "successful" and had significant revenue, however it just redirects to our non-dot-com, because it's too much of a hassle and SEO risk to change at this point.
If I as a SaaS provider get my SSO SAML integration via a provider like Okta or Auth0, the auth provider pricing itself is also on a "call us" tier, with a per-federation pricing in the low four figures for each individual company connecting to me via SAML.
It's pretty insane, so I'll state it again: To have a company connect to my SaaS via SAML, I as the SaaS provider have to pay my auth provider $X,000 per year for the privilege. Not counting the base enterprise tier pricing for the auth solution itself. So then I have to roll my own solution if I want to provide it for free, and I get the joy of supporting the long tail of broken SAML implementations on both the service and identity provider sides. For free. In a perfect world SSO wouldn't be a shitshow and everyone could have it for free, unfortunately that is not this world.
Does Deno have some built in way to vendor / download the imports pre-execution? I don't want my production service to fail to launch because some random repo is offline.
If business travel is reduced, you can expect the cost of regular coach class tickets to increase massively as the former pays for the flight and the latter is just there to wring a bit more profit out of the trip.
Business travel right now is non-existent and many companies are finding that things still work just fine without it and will not return to previous spend levels.
Zoom works great on Linux, it's a proper native app and the quality is excellent. Screensharing is notoriously tricky on Wayland and has been a shifting target that is just now starting to settle, I'm sure it'll eventually work.
A primary driver of SaaS sales is trust. Nobody wants to bet on a platform that is going to pivot or shut down within 12 months. It's not about price, it's about disruption to business in both adopting and offboarding from any solution more complex than a todo list. For a lot of established companies, that unfortunately means they won't even consider you until you've been around for 1-2 years. We have a lot of customers who checked us out on day 1, and now 3-4 years later are coming back saying "Cool, you guys are still in business, now we can try you out for real".
If you're building SaaS, go ahead and take that SaaStr article as gospel (and a lot of their other writing as well). Maybe you're a special unicorn where it doesn't apply, but most likely you aren't.
As a user of a library, I don't really care how it works. Under the hood it can be arbitrarily complex or simple, and please feel free to change the implementation weekly for all I care. I care very deeply about my own components, when they render, what causes them to re-render, and that I can control and reason about when they re-render. Also, stability of API (in number of years) is way more important than new whiz-bang features.
I feel that with class components I have a really good understanding of what is rendering and most importantly, when. componentDidMount, shouldComponentUpdate, PureComponent, etc. With hooks, it's much more magic. And clarity of rendering is literally the one thing I want from React.
We have two projects, one using class components and one using hooks, and working on the class components one is unexciting, straightforward, sometimes repetitious, but never confusing. When writing hooks on the other hand it's constant gotchas; can't do that here, didn't memoize this, can't call that within this, etc. fuzzing until it works as Reacts expects. And then the bloody thing still renders on every frame. Back to the drawing board to figure out the right magic incantation. Probably memoize a few more layers, ugh.
At the end of each PPP application with your bank, you get the same SBA PPP form to sign as the SBA has publicized on their web page. You then have to sign and pinkie swear that the funds are necessary and going to payroll.
The banks are doing jack shit in terms of useful work except shoveling application's SBA's way, with the SBA being the ultimate approver of the loan anyway! Bank are just in middle and limiting applications to their existing customers for no good reason whatsoever.
That sounds like an ad business version of the efficient market theory. E.g, that can't possibly be a hundred dollar bill on the ground, because if it was someone else would surely already have picked it up by now.
I think you're overestimating Google's sophistication.
That was however the intent of the statement: Companies that pay dividends or make share buy-backs are more vulnerable in a crisis [compared to otherwise identical companies who build a cash buffer].
I disagree that companies that pay a dividend by definition have a buffer. If the income plummets (like in non-essential retail at the moment), they have no hypothetical dividend buffer to fall back on, that if not paid out would keep them in business.
Companies that intentionally run with razor-thin balance sheets and don't have any buffers built in to withstand shocks, are more fragile than companies with some buffer, all other things being equal.
If the company chooses to pay out said buffer as dividends, it's to the benefit of shareholders. That's completely fine, market working as intended! But they shouldn't then be able to turn around and get state aid because the lack of said buffer now makes their company non-viable, at least not without restrictions like the Danes are imposing (no future dividends). To do otherwise incentivizes creating these fragile bufferless companies, and puts companies that do have a buffer at a competitive disadvantage.
What Denmark is doing, is saying you can get some aid to help your company, but going forward you must pay us (the society who supports you) back before you pay your investors. Unfortunately the dividend restriction period is capped at two years, while it should really be for an indefinite time.
[0] https://pointieststick.com/2025/03/10/personal-and-professio...