Auth would have cost us our entire runway. We shipped it in 5 days.

We costed authentication in the first week of planning and got four to six weeks, which was near enough our entire runway before launch. Two developers, no funding, and the most expensive thing we owned was a system that has never once been the reason someone chose a product. We bought instead of building and shipped in five days. Ninety days later: 1,847 users, 87% signup completion, and effectively zero engineering time on auth.

MojoIndie is an AI blog engine for indie hackers and solo founders - it researches topics, drafts posts, optimises them, and publishes to your platform, so that one person can run a content operation that would normally need a team.

We built it with two developers and no funding. This is a write-up of the single decision that most affected whether we shipped at all, and it was not a decision about AI.

Key Takeaways

• The real cost of "add a login form" is not the login form. It is sessions, MFA, workspaces, teams, API keys, rate limiting, lockout, enumeration and secure token storage, plus maintaining all of it forever.
• Our honest estimate was four to six weeks, roughly our entire pre-launch runway as a two-person unfunded team.
• Our customers are developers. Half of them have built auth themselves and will notice a sloppy password reset flow. That removed "ship something basic" as an option.
• We shipped in five days, broken down day by day below. 1,847 users in the first 90 days, 87% signup completion, 34% MFA adoption.
• What we gave up, honestly: a dependency, some control over the edges, and a recurring cost instead of a one-off one.
• The decision with the longest shadow was not authentication. It was the workspace model, which gets into your data model, billing and URLs and never comes out.

The maths that made it obvious

We wanted to launch in a couple of months. Not a landing page - a real product people could pay for.

Somewhere in the first week of planning, we costed authentication. Not "add a login form", which is an afternoon. The actual list for a B2B product you intend to charge for:

• Signup, login, password reset, email verification
• Session management that is correct - expiry, revocation, refresh, multiple devices
• Multi-factor, because our users are technical and would notice its absence
• Workspaces, because our users manage several projects and expect them separated
• Team invitations and roles, because even solo founders share access with a contractor
• API keys, because power users automate everything and will ask on day one
• And then the parts nobody puts on the list: rate limiting on login, account lockout, the enumeration attack you did not think about, secure token storage, and the ongoing maintenance of all of it

Four to six weeks, honestly estimated. Which was, near enough, our entire runway before launch.

Spending our whole pre-launch budget on a system that has never once been the reason someone chose a product is a bad trade. But shipping bad auth was also not available to us, and this is the part that is specific to our market: our customers are developers. An indie hacker evaluating a tool built for indie hackers will notice if your session handling is sloppy or your password reset flow leaks whether an account exists. Half of them have built this themselves. You cannot bluff to that audience.

So: six weeks we did not have, or a credibility problem with exactly the people we needed. That is the whole build-vs-buy case in two sentences.

We bought, and it took five days

We used SSOJet and had authentication in production in five days. Here is how those days went, because "five days" without detail is the kind of claim that should make you suspicious:

Day 1 - Setup and configuration. Account, branding, and reading the documentation. Mostly reading.

Day 2 - Core authentication. Signup, login, password reset, email verification. These are the flows with the highest ratio of "seems simple" to "actually has security-relevant edge cases", and not writing them ourselves is where most of the saved time came from.

Day 3 - Workspaces. Our users manage several blog projects and expect them properly separated, so each user can create unlimited projects as separate workspaces. Getting this shape right early matters more than it appears to - it is very hard to change later, because it ends up embedded in your data model, your billing and your URLs.

Day 4 - API keys and team features. API key generation for power users, and a team invitation system. API access was not optional for our audience; indie hackers automate things, and an API needs credential management that is not an afterthought.

Day 5 - Testing and launch. Comprehensive testing across the signup flows, then deployed.

We also defined roles that match how content work actually happens - Owner, Editor, Contributor, Viewer - rather than generic admin/user, and set sessions to expire after 30 days of inactivity, which suits a tool people use in bursts.

Five days against a four-to-six week estimate. That is the entire post, really. The rest is detail.

What happened next

Two of these are worth more than the others.

87% signup completion. For a technical audience with no patience, that is the number that tells you the flows are not annoying anyone. It is also a number we did not have to earn - we inherited it from an implementation we did not write.

34% MFA adoption. That is high for an SMB product, and it is not because we nagged anyone. It is there, it is easy, and about a third of our users switched it on. If we had built auth ourselves in six weeks, MFA would have been in the "later" pile and that number would be zero.

And "effectively zero" engineering time on auth post-launch is what a two-person team is actually buying. Not the six weeks up front - the absence of a system that needs someone's attention forever.

Nearly two thousand users, and essentially no authentication issues. For a team our size, that is the difference between shipping features and firefighting.

What we gave up

Every honest build-vs-buy post should have this section, so here is ours.

A dependency. Our authentication is someone else's system now. If they have an outage, our users cannot sign in and there is nothing we can do except wait and communicate. We accepted that because the alternative was our own auth, written under deadline pressure by two people, which has its own failure modes and no support to call. But it is real, and if you cannot accept a dependency on that path, this decision is not for you.

Some control over the edges. There are flows we would style or sequence slightly differently if we owned every line. None of it has mattered enough to regret, but on day three you will find one thing you would have done another way.

A recurring cost instead of a one-off one. We pay monthly forever rather than spending six weeks once. For us the comparison is not close - six weeks of two founders' time at the moment of launch is the most expensive thing we own - but if you have engineering time and no cash, the arithmetic points the other way.

What we did not give up, and expected to: quality. The thing we were most worried about was that bought auth would feel bought - that our users would sense a bolted-on component. They have not. Users tell us the product feels polished, which would not be true if we had hacked together basic auth in the time we had. Nobody has ever mentioned the authentication, which is exactly the outcome you want.

What I would tell another two-person team

Cost the real list, not the login form. The reason build-vs-buy on auth gets decided badly is that people estimate the visible ten percent. Write out the whole list - including lockout, rate limiting, enumeration, token storage, and the maintenance - and then decide. The list is the argument.

Be honest about your audience's threshold. If you sell to non-technical users, you have more room to ship something basic and improve it. We did not, and knowing that made the decision straightforward rather than agonising.

Get the workspace model right on day one. Of everything we did that week, this is the one with the longest shadow. Authentication you can swap out later, painfully but possibly. The shape of your tenancy model gets into everything and never comes out.

And the general version: as a small team, your advantage is not that you can build everything. It is that you can decide quickly what not to build. Auth was ours.

About the numbers in this post

Every figure here is MojoIndie's own product data from the first 90 days after launch: user and project counts from our database, signup completion measured as the share of started signups that reached an active account, and MFA adoption as the share of users with it enabled.

The four-to-six week figure is our own pre-build estimate, not a measured outcome. We did not build it, so it cannot be verified. It is included because it is the number the decision was actually made on.

No third-party benchmark is quoted here and no claim is made about how our figures compare to any industry average.

Disclosure: MojoIndie pays for and runs SSOJet in production for authentication. This post is our account of that decision. We were not paid to write it, and SSOJet has published their own version of the same story.

Frequently asked questions

Does authentication really take four to six weeks to build?

Not the login form, which is an afternoon. The estimate covers correct session management (expiry, revocation, refresh, multiple devices), MFA, workspaces, team invitations and roles, API keys, and the security work nobody lists: login rate limiting, account lockout, user enumeration protection and secure token storage. Then the maintenance. Teams that quote a week are estimating the first item on that list.

When does building your own authentication make sense?

When you have engineering time and no cash, which is the exact inverse of our position. A recurring subscription is worse than a one-off build if the one-off is genuinely affordable to you. It is also worth building if you have a requirement no platform serves. Neither applied to us: six weeks of two founders' time at the moment of launch was the most expensive thing we owned.

Will users notice you did not build your own auth?

This was our biggest worry and the answer has been no. Nobody has ever mentioned the authentication, which is the outcome you want, because auth is only noticed when it is bad. Our audience is technical and would have noticed a sloppy implementation, which is precisely why buying was the safer option rather than the lazy one.

Why did 34% of your users enable MFA without being prompted?

Because it was there, it was easy, and our users are technical. We did not run a campaign. The relevant counterfactual is what would have happened if we had built auth ourselves in six weeks: MFA would have been in the "later" pile and the number would be zero. Adoption of a feature you never shipped is not low, it is undefined.

Why is the workspace model harder to change than authentication?

Because tenancy propagates. Your data model, your billing logic and your URL structure all end up encoding it, so changing it later means migrating data, reissuing links and reworking billing at the same time. Authentication is comparatively contained: you can replace the layer that verifies who someone is without touching the shape of what they own. Spend the day-three thinking on tenancy.

How do you justify depending on a third party for login?

By comparing it to the honest alternative rather than to a perfect one. The alternative was authentication written under deadline pressure by two people, with its own failure modes and nobody to call. A vendor outage is real and we cannot fix it, but the risk we avoided was larger, and it was one we would have owned permanently rather than occasionally.

Conclusion

The decision that most affected whether MojoIndie shipped at all was not about AI, models or product. It was a build-vs-buy call on the least interesting system we own, made in the first week of planning, on the back of one honest list.

Five days instead of six weeks. 1,847 users in the first 90 days and essentially no authentication issues. And a genuine dependency we accepted with our eyes open.

If you are two people deciding this right now: write out the whole list, including the parts nobody puts on it. In our experience the list decides the argument before you do.

MojoIndie uses SSOJet for authentication. Their write-up is here.