mooreds

I do know that very few systems are designed to handle a 14x increase in traffic painlessly (275M*52 = 14.3B), especially at scale.

   Commit volume went from 1 billion total in all of 2025 to 275 million per week by early 2026. 

and then click on 'view open positions'.

The reason for the 2 steps is because we may change ATSes in the future, but https://fusionauth.io/careers will always be a live page.

That's the joy and pain.

I looked at the docs last week and didn't see anything about that.

At FusionAuth, our mission is to make authentication and authorization simple and secure for every developer building web and mobile applications. We are building the only CIAM platform built to deploy anywhere, give you total control, and scale across any modern architecture–no matter how complex.

There are a lot of companies in the auth space, but we feel like we have something special:

* a relatively unique deployment model (self-host on-prem, run in your cloud or let us operate it for you in ours)

* A well designed API first approach; one customer compared our APIs to petrichor

* a mature product (the code base is nine+ years old and we've found and fixed a lot of the sharp edges around core login use cases; but don't worry, there are plenty more features to add)

* a full featured free-as-in-beer version which makes the sales cycle easier; prospects often come in having prototyped an integration

Our core software is commercial. We open source much of our supporting infrastructure. Technologies and standards that you will work with: modern Java, PostgreSQL, Docker, Kubernetes, MySQL, OAuth, SAML, OIDC.

Visit https://fusionauth.io/careers and click 'View Open Positions' for applications or more details.

What was your experience if so?

An excerpt:

> “I've spent the last several months talking to people all over Casa Grande, and one thing keeps coming up: Safety. So, today I'm excited to announce a new company called Shepherd Safety,” he said. “Our mission is simple. Keep government officials and their families safe.” It would be no different than how the city monitors its citizens using Flock cameras, he said; he planned to launch satellites that would use AI to monitor “where government officials go, where they stop, who they meet with, and when they return home.”

It was satire, but drove the point home well.

While I think that makes sense, I also think more controls are a good solution. That is, prevent access to the sales data without escalation, probably to a human, but possibly to another AI. The issue there is twofold:

- if you start with least privilege, the agents become less useful

- need to balance escalation with frequency otherwise it's just another version of MFA fatigue

Agree that auditability is important because otherwise you don't know what you don't know.

In all cases, there needs to be some payback to the folks putting in time. And it can't just be money, because volunteer organizations never have enough money to compensate appropriately. Otherwise they'd be businesses :) .

Other forms of compensation:

   * fun, as you outline
   * recognition from others
   * impact on the world
   * legacy/connecting to the past
   * satisfaction of helping others
   * increased leverage toward other goals
   * learning new skills
   * connection and community

Without any special insight into fly.io, I'd bet the situation is the latter. You keep the lights and fix security issues for the existing infra (which incidentally gives you money out of cashflow to invest in new efforts).

Creating software with AI is super easy--plan, prompt, test, go, go, go!

Owning software means you're responsible for maintaining it over time, fixing edge cases, operating it well, and more.

If you're building a one-off custom webapp to meet your needs, create away. If you're writing software for a business to run on, you're owning it. My fav article on this topic is this post[1] on durable vs disposable software.

0: https://www.linkedin.com/feed/update/urn:li:activity:7482123...

1: https://www.honeycomb.io/blog/disposable-code-is-here-to-sta...

I've heard plenty of stories of folks moving from homegrown auth to a off-the-shelf solution, but that's because I'm in the off-the-shelf auth space.

It'd be super interesting to hear stories of folks who went the other way, and outgrew their service provider's auth.

I work in the auth space (for FusionAuth) and we run into plenty of folks that started out rolling auth themselves. Just username and password right? A bit of hashing, salting and leveraging a built-in crypto library.

But then you need to add account recovery. And then MFA. And then registration. And then progressive registration. And then webhook integration. And then passkeys. And then SAML integration. And the delegated SAML setup. And then and then and then.

You're distracted from your core application by feature requests for your login system.

You have lots of options nowadays. Use a library provided by your framework (Rails, Spring, and Django have them), use a tool like Better Auth, use a third party system like FusionAuth or Auth0. But don't build undifferentiated functionality that impacts your user experience.

PS Of course, where I stand depends on where I sit, but I firmly believe that you should not build an auth system the same way you should not build a database.

Anything that makes it easier for developers to build secure applications is a win!

Nice bit of shade.