Saaster

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.

[0] https://pointieststick.com/2025/03/10/personal-and-professio...

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.

The code running in my browser isn't a multi-tenant production server, with access to the filesystem and DBs.

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.

Let's keep moving those goalposts 'til the other team can't even see the goal anymore!

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.

It's still the exact same potato-cam in every model, from the Air to the $$$ MacBook Pro "16.

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.

My biggest worry with React is that it has restless developers with idle hands.

I have (a lot of) component code that will never be converted to hooks. Can I rely on you not to flake out and pull an Angular on me?

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.

The IRS has the capability to put money directly into business bank accounts, or require businesses to sign up for EFTPS.

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.

And they can definitely still do that. AFTER they've paid back the state aid they received.

If the company is itself not based in NY or SF, it makes little sense and often isn't possible to offer NY and SF salaries. If remote work became the new standard, it doesn't mean that everyone is suddenly paid SF wages, instead wages will probably start to average out over a long period of time.

Firms applying for Danish state aid must promise not to pay dividends or make share buy-backs in 2020 and 2021. Companies would be allowed to pay dividends again if they pay back the aid.

This makes perfect sense, otherwise it's a textbook case of socializing the losses and privatizing the profit. Paying dividends (and stock buybacks) is a trade-off that companies make, that makes the company less resilient. Risk/reward needs to work in both ways, both in terms of gains as well as losses.

It's a good common sense start. Companies that pay dividends or make share buy-backs are more vulnerable in a crisis (not only the current one), meaning they are riskier investments. Risk needs to be inversely correlated with reward for the markets to function. Investors in riskier companies deserve to get wiped out, not propped up.

Companies registered in tax-havens should have no business applying for EU or US aid. I would say, simply barring them doesn't go far enough. If one did apply while being simultaneously registered in the EU/US and any tax haven, that is fraud and should result in jail time.

Unfortunately the demand for SAML is 100% customer driven. As service providers, we don't control the other end (the customer's IdP/AD).

Even in cases where the IdP supports both SAML & OIDC, I see almost no one choosing to use OIDC (a case of the devil you know?). The only real users of OIDC in an enterprise setting I see as a service provider, is G Suite businesses.

I've looked at Cognito in depth, and it seems like an abandoned service. Hundreds of open issues that got rolled into the Amplify issue tracker, with little to no response. It lacks some pretty basic SAML capabilities, like IdP-initiated logins. If your customers want to put you as an icon in their Okta dashboard or whatever, can't do it. They reported that as being "on their roadmap" in 2017.

It does work for the basic use cases, so I would still consider that an better option than rolling your own for the average service provider.

100% agreed, GitHub SAML is unequivocally good. I'm in the "cat sharing startup", so my view and comments are colored by that perspective. Our options are to pay $$$ for a competent auth provider, or take on a much larger and complex security responsibility than it would seem at first, that might end up compromising our entire service.

I have a theory that one reason we don't see many your-SAML-implementation-is-completely-broken reports is precisely because it's a gated enterprise feature, so few independent security researchers have the access or ability to poke and prod at them outside of private penetration tests.

SSO is a great benefit to the customers, with real tangible security and management benefits.

I'm however speaking from the point of view of the service provider (the SaaS app) and about SAML in particular. I feel that the addition of SAML into a given service is a net-negative from that service's security point of view. It's a large additional complex attack surface, many open source SAML libraries that I've reviewed have a history (and in some cases open issues right now) of "pants on head" type of security errors. A popular library in use right now, has a known race condition where it gets confused if there are concurrent SAML requests happening.

And that's just the libraries. Then you have to use them correctly. The libraries do the absolute minimum checking since they don't have the context, you have to add a laundry list of your own checks to them. Just recently there was a HN article about taking SAML assertions posted to provider A and re-using them on provider B, where clearly the most basic of checks aren't in place at all. There's all kinds of confused-deputy type of problems I believe most service providers don't think about at all. And that was an easily offline checked attribute, I believe if you'd start to check how many services correctly implement even the basic "inResponseTo" check on SP-initiated flows (which requires a distributed cache on the service provider side), you'd find they don't.

I agree. There's a million SAML for Java/Python/Node.js/Foo libraries out there, all with a long list of issues and known cases that don't work correctly, security issues etc. but it's the wrong model in my opinion.

Instead of directly bolting SAML into your app, I think a FOSS implementation of an independently running service is the way to go. You run the battle tested open source service (locally / in your cloud), it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta. Doesn't even need to do any user management, just focus on rock solid interoperability and forward all decision making to the actual app server.

Passwords, rate limits, resets, etc. are the same for everyone, and so are the problems and the solutions to those.

SAML on the other hand is different for each organization. Providers pay Auth0 and the like to have developers on staff who know the pitfalls and quirks of ADFS 3.0 on Windows Server 2012 R2, so they don't have to. Dealing with a single Okta as IdP integration is like the absolute best-case scenario there is. There is also zero consistency in what actual data IdPs returns out of the box to the SPs, so now you're walking the customer's admin through setting up the proper attribute mappings, etc.

I also very much disagree that SAML is a net security benefit, at least directly. It's for convenience, top-down visibility and control into what people are using, de-provisioning services, onboarding and offboarding users at scale etc. e.g. problems that only big companies have. Many SAML implementations are just as likely to add truck-sized security holes to the service provider when done poorly, and a lot of them are done poorly.

SAML (and 2FA to a lesser extent) comes with some serious support burdens on the companies offering it. There's a long tail of more or less broken SAML implementations on both the service and identity provider sides, provisioning issues, configuration issues, "Sally can't login on Tuesdays" issues, duplicated slightly-inconsistent data in IdP and Service side records issues...

If you as a SaaS provider outsource your SAML integration to a third party provider like Okta or Auth0, the auth provider pricing is immediately on a "call us" tier, with a per-federation pricing in the low four figures for each company connecting via SAML. Let me just state that again, to have company X 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.