We Shipped Auth in 48 Hours With an AI IDE. The 48 Hours Were Not the Point

In May 2025, GPT0 went from having no authentication at all to running it in production in forty-eight hours. We used Cursor, an AI-native IDE, and a managed authentication platform, and the number is accurate. It also gets quoted back to us in a way that credits the wrong thing.

The forty-eight hours contained about twenty-two hours of application code. An AI coding assistant genuinely compressed those. They contained roughly ten hours of FERPA, GDPR, and CCPA verification, which no coding assistant compressed at all — that block was short for an entirely different reason, and if we had been building authentication ourselves it would not have been ten hours. It would have been the whole project.

This is the two days taken apart, honestly: what the AI tooling did, what it could not touch, why an education product could not treat compliance as something to catch up on later, and what our three-month numbers actually establish.

Key Takeaways

• AI tooling compresses the work you own, and nothing else. Cursor accelerated GPT0's SDK integration, boilerplate, test generation, and debugging — roughly 22 of the 48 hours. It had no effect on the 10 hours of compliance verification, because that work was reading and confirming someone else's certified controls rather than writing code.
• FERPA is why this was a buy decision, not the speed. GPT0 serves students, so US student-record rules applied from the first account. Compliance was the constraint that made building authentication in-house unattractive; AI-assisted development would have made the coding part faster and left that constraint exactly where it was.
• The "4 to 6 weeks" alternative is a counterfactual, and the honest version is worse than it sounds. A self-built system is not 4-6 weeks and done. It is 4-6 weeks of construction, an open-ended compliance tail, and permanent maintenance — against 48 hours plus a subscription.
• 250,000 users in 3 months is not a result authentication produced. GPT0 was already growing virally as an open tool. Authentication converted that traffic into accounts; it did not create the demand. The claim we will defend is 250,000 authenticated users accumulated over three months, which is a different sentence.
• Two of our published figures come from the platform, not from us. The sub-50ms authentication latency and 99.99% uptime are the provider's specification and SLA. GPT0 has not independently measured either, and the section below separates them from the numbers we did measure.

Why an AI Detection Tool Needed Accounts at All

GPT0 launched as a completely open platform. Paste text, get a confidence score on whether a language model wrote it, see the breakdown by paragraph and sentence, leave. No login, no email, nothing.

That openness is most of why the product spread. It is also why, by early 2025, GPT0 had a growth problem shaped like a business problem. Without user identity there was no mechanism for premium tiers, no way to meter usage for billing, and no relationship with any of the people using the platform daily. Our detection engine, multi-language support, batch processing, and API were all built. The thing standing between them and revenue was that we could not tell one user from another.

The second reason was less obvious and turned out to be the binding one. GPT0's fastest-growing segment was academic: students checking their own work, instructors verifying submissions, institutions running originality checks at scale. The moment a meaningful share of your users are students in US schools, you are handling data that sits inside the Family Educational Rights and Privacy Act, and the question stops being whether you want accounts and becomes what your accounts are legally required to do.

So the requirement was not "add a login." It was: add a login that a school district's counsel will approve, without slowing down a product whose appeal is that it answers instantly, in a market where a quarter of engineering time spent on infrastructure is a quarter spent not improving detection accuracy.

Two Clocks Running in Opposite Directions

GPT0's product team was working against two deadlines that do not usually appear in the same project, and reconciling them is the actual story here.

The first clock is market speed. AI tooling is a category where a quarter is a long time. Every week our engineers spent on authentication was a week not spent on detection accuracy, language coverage, or the enterprise API — the things our users choose us for. A four-to-six week infrastructure project is not just a cost; in this market it is a position surrendered.

The second clock runs the other way. FERPA is the US Family Educational Rights and Privacy Act, and it governs the handling of student education records, imposing obligations around access control, parental consent for minors, disclosure limits, audit trails, and annual notification (US Department of Education Student Privacy Policy Office). GDPR is the EU General Data Protection Regulation, which adds data residency, right of access, right to erasure, portability, and documented consent. CCPA is the California Consumer Privacy Act, which adds rights around disclosure, opt-out of sale, deletion, and non-discrimination. None of these reward speed. All of them reward having done the work properly and being able to demonstrate it.

The mistake we watched other teams make was treating these as sequential — ship authentication fast, add compliance when a deal requires it. That sequence does not work, because compliance in this domain is largely a property of how identity data is stored, where, with what consent, and with what audit trail. Retrofitting it means changing the storage model after you have real student records in it. The two clocks are not a scheduling conflict you resolve by picking one. They are a design constraint you resolve by not owning the thing that has to satisfy both.

The 48 Hours, Taken Apart

GPT0's implementation ran in six blocks across two days in May 2025, and the composition matters more than the total.

Hours 0–4, planning. Reading the platform documentation, mapping integration points into our React and Node.js application, and configuring the OAuth providers. Cursor generated initial SDK integration templates here, which helped, but this block is mostly decisions and decisions do not compress much.

Hours 4–10, backend. SDK integration into our Express services, JWT validation middleware, user profile endpoints, and webhook handlers, against PostgreSQL for profiles and Redis for session caching. This is the block where AI assistance was most visible.

Hours 10–18, frontend. The One Tap modal, social login buttons, email OTP interface, and authentication state management in React with the Context API, responsive across mobile and desktop.

Hours 18–26, testing. Chrome, Firefox, and Safari; iOS, Android, and desktop; OAuth flows, session persistence, and the failure cases. Cursor generated a substantial share of the test scaffolding.

Hours 26–36, compliance verification. Confirming FERPA, GDPR, and CCPA requirements against the platform's controls — data handling policies, consent workflows, audit logging, regional residency. Not code. Reading, checking, and documenting.

Hours 36–48, deployment. Production rollout, monitoring the first real authentication traffic, validating performance, and confirming global routing. Twelve hours, and deliberately unhurried. A botched authentication deploy does not degrade a feature; it removes every user's ability to get in, and it removes yours at the same moment.

What Cursor Compressed, and What It Left Alone

GPT0's engineering team used Cursor with GPT-4 integration throughout, and the honest accounting is that it was a real multiplier on a specific and limited class of work.

The specific accelerations were unglamorous and real: autocompleting SDK integration against documentation it could read in-editor, generating test cases for authentication flows, catching errors as they were typed rather than at compile time, and iterating quickly on the login UI. Boilerplate and lookup are exactly what this tooling is best at, and a platform integration is unusually rich in both.

What we would caution against is the inference that got made about this project internally before we looked closely: that AI tooling had reduced our authentication project from six weeks to two days. It did not. It reduced roughly six weeks of coding to roughly twenty-two hours of coding. The reason the rest of the project was small is that we had bought it. Those are two different savings, and only one of them came from the IDE.

The failure mode this protects against is real. A team that concludes "AI tooling makes infrastructure cheap" may reasonably conclude that building authentication in-house is now viable. For a product with our compliance exposure, that inference is wrong in a way that surfaces months later, during a security review, with a school district on the other side of the table.

FERPA Is Not Something You Can Generate

GPT0's compliance obligations were the reason this was a purchase, and they are worth stating concretely because "compliance" gets used as a vague noun.

FERPA is a US federal law protecting the privacy of student education records at institutions receiving Department of Education funding (studentprivacy.ed.gov). For an authentication layer it means access controls over records, parental consent handling where users are minors, limits on disclosure to third parties, audit trails showing who accessed what, secure storage and transmission, and support for annual notification requirements.

GDPR is the EU regulation governing personal data processing, and the obligations that land on an authentication layer are EU data residency, right of access to the data held about a user, right to erasure, data portability, and documented, revocable consent (Regulation (EU) 2016/679, EUR-Lex).

CCPA is California's consumer privacy statute, and it adds state-specific rights: disclosure of data categories collected, opt-out of data sale, transparency about third-party sharing, deletion on request, and non-discrimination against users who exercise those rights (California Attorney General).

Read as an engineering task, that list is not enormous. Read correctly, it is not an engineering task at all. Most of those items are not "write code that does X" — they are "be able to demonstrate to a reviewer that X holds, and keep demonstrating it." The artefact a school district's counsel wants is not a feature. It is evidence, maintained over time, about a system somebody is accountable for.

That is the thing GPT0 bought, and it is why our compliance block was ten hours instead of the indefinite period it would otherwise have been. We were not constructing controls. We were verifying that controls we had contracted for behaved as specified and documenting that verification. Those two activities have almost nothing in common except their name.

Worth being clear about what did not go away. Consent workflows still have to run correctly for every user. Erasure and access requests still arrive and still have to be serviced. Audit logs still have to be retained and produced. Annual notification obligations still recur. The purchase changed who builds and certifies the machinery; it did not change the fact that GPT0 is the accountable party to its users. Anyone reading a two-day timeline as "compliance solved" has read it wrong.

The Buy-Versus-Build Arithmetic, Honestly Stated

GPT0's alternative to buying was estimated at four to six weeks of engineering, and we want to be precise about the status of that figure and about what it leaves out.

Three things about that estimate deserve saying out loud.

It is a counterfactual. GPT0 never built authentication in-house, so we do not know what it would have cost. Four to six weeks was our planning estimate for the construction phase, produced by the same team that would have done the work, which is exactly the population most prone to underestimating. Treat it as our expectation at the time rather than as a measurement.

It omits the tail. Construction is the part of a compliance-bearing system that is easiest to schedule and smallest in expectation. Getting to a state where you can convincingly demonstrate FERPA handling to an institution's reviewer has no reliable duration, and it is not finished when the code works.

It omits the recurring cost entirely. A purchased system carries a subscription. A built system carries engineers, permanently: hash policy, session handling, provider integrations that change under you, audit log retention, and every regulatory update. For a company whose scarce resource is engineering attention, that recurring line is the one that actually decides it.

The Part of the Stack We Chose Not to Own

GPT0's product team applies a simple filter to infrastructure decisions, and authentication failed it in the most clear-cut way anything has.

The filter: does owning this make our product better at the thing users choose us for? Users choose GPT0 for detection accuracy, for the paragraph and sentence-level breakdown, for language coverage, and for speed of result. Nobody has ever chosen an AI detector because of its login. A perfect authentication implementation and a merely adequate one are indistinguishable to every user we have, provided both are fast and neither loses their data.

Authentication is unusual among infrastructure choices in that it combines maximum consequence with minimum differentiation. Getting it wrong is catastrophic — a breach, a lockout, a failed compliance review — and getting it exceptionally right is invisible. That asymmetry is close to a definition of something you should buy rather than build, and it holds regardless of how cheap your tooling has made the building.

The generalisation we would offer other AI-native teams is narrower than the one usually drawn from stories like this. It is not "AI tooling means small teams can build anything now." It is: AI tooling lowers the cost of the code you write, which makes it more tempting to write code you should not be writing at all. The filter matters more, not less, when construction gets cheap.

Three Months, and What the Numbers Do and Do Not Say

GPT0 went live in May 2025. The figures below cover the three months after launch, and they are separated by whether we measured them.

Five reading notes, because most of the ways this table gets misquoted are predictable.

250,000 users in three months is not something authentication caused. GPT0 was already spreading virally as an open tool with no signup; that traffic existed before May 2025 and would have continued without us adding accounts. What authentication did was convert a share of it into identified users we could bill, support, and serve premium features to. The defensible sentence is that GPT0 accumulated 250,000 authenticated users in three months. The sentence "authentication grew GPT0 to 250,000 users" is not one we will stand behind.

The +20% is a relative lift and we are withholding the underlying rate. Lifting 2% to 2.4% and lifting 10% to 12% both register as "+20%", and those describe businesses with very little in common. Use it as a direction and a magnitude of change, not as an input to a revenue model.

"Under 1 second" describes One Tap for returning users. It is not an average across all methods. Email OTP requires an inbox round trip and cannot be sub-second by construction; it exists as the fallback for users without a Google or Facebook account, and it is slower on purpose because the alternative is excluding those users.

Two figures in that table are the platform's, not ours. Sub-50ms global authentication latency and 99.99% uptime are the provider's specification and contractual SLA respectively. GPT0 has not independently instrumented either. We publish them because they were part of the decision, and we label them because a vendor specification reported as a customer result is one of the more common ways case-study numbers mislead.

Two days is not a promise about your project. It is what a two-person integration into an existing React and Node.js application took, with an AI coding assistant, against a platform whose compliance work was already done. Change any of those and the number changes.

All measured figures above are GPT0 first-party data — project records, user database, and billing analytics — covering May 2025 through the three months following launch. Figures sourced from the authentication platform rather than from GPT0's own instrumentation are labelled as such in the right-hand column.

Frequently Asked Questions

Which parts of an authentication integration does an AI coding assistant actually speed up?

For GPT0, Cursor compressed roughly 22 of the 48 implementation hours, and all of that saving was in one class of work: SDK integration boilerplate, OAuth configuration scaffolding, test case generation, in-editor documentation lookup, real-time error detection, and iteration on login UI components. It had no measurable effect on the ten hours of FERPA, GDPR, and CCPA verification, on the buy-versus-build decision, or on production rollout judgement. Platform integrations are unusually rich in boilerplate and documentation lookup, which is why the effect was as large as it was.

Does an education technology product need FERPA-compliant authentication?

If the product handles student education records at US institutions receiving Department of Education funding, FERPA obligations reach the authentication layer, and for GPT0 they applied from the first account rather than from a later enterprise deal. In practice that means access controls over records, parental consent handling for minors, disclosure limits, audit trails of who accessed what, secure storage and transmission, and support for annual notification. GPT0 treated this as a design constraint rather than a later addition, because the requirements are largely properties of how identity data is stored and consented to, and changing that after real student records exist in the system is materially harder.

Can compliance work be accelerated the same way code can?

Not in GPT0's experience, and the reason is structural rather than a limitation of current tools. Most compliance obligations are not "write code that does X" but "be able to demonstrate to a reviewer that X holds, and keep demonstrating it." The artefact required is maintained evidence about an accountable system, not a feature. GPT0's compliance block was ten hours rather than an open-ended period because we were verifying controls we had contracted for, not constructing them — a different activity that happens to share the word.

Should an early-stage AI company build its own authentication?

GPT0's filter is whether owning a piece of infrastructure makes the product better at what users actually choose it for, and authentication fails that filter unusually clearly. It combines maximum consequence when wrong — breach, lockout, failed compliance review — with zero differentiation when right, since no user has ever chosen an AI detector for its login. Cheaper construction through AI tooling does not change this; if anything it raises the risk, because it makes writing code you should not write more tempting.

What does a sub-second login figure actually measure?

GPT0's under-one-second figure describes Google One Tap for returning users, not an average across all authentication methods. One Tap surfaces contextually and completes in a single click for a user with an existing browser session. Email OTP, which GPT0 offers as a fallback for users without a Google or Facebook account, requires an inbox round trip and cannot be sub-second by construction. Any sub-second authentication claim should be read as a statement about one method and one user state.

Did requiring accounts slow GPT0's growth?

GPT0 accumulated 250,000 authenticated users in the three months after the May 2025 launch, but that figure should not be read as authentication driving growth. GPT0 was already spreading virally as an open tool with no signup, and that demand existed beforehand. Authentication converted a share of existing traffic into identified users who could be billed and served premium features; free-to-paid conversion rose 20% in relative terms. The growth and the conversion lift are separate effects, and only the second is attributable to the authentication project.

Conclusion

The forty-eight hours are true and they are the least interesting fact about this project.

What actually happened is that GPT0 faced two incompatible deadlines — a market that punishes a six-week infrastructure detour, and a regulatory regime that punishes moving fast — and resolved them by not owning the thing that had to satisfy both. The AI IDE was a genuine accelerant on the twenty-two hours of code. It was irrelevant to the ten hours of compliance verification, and it would have been equally irrelevant to the far longer compliance work that building in-house would have required.

If you take one thing from this, we would rather it be the filter than the timeline. Cheap construction is not the same as a good reason to construct. For infrastructure that carries maximum consequence and zero differentiation — authentication being the clearest case we have encountered — the question was never how fast we could build it. It was whether we should be the ones accountable for it at all, and for a company whose users are students, the answer was not close.

About this post: written by the GPT0 Product Team. GPT0 is an AI detection and writing tools platform providing confidence-scored detection of language-model-generated text with paragraph and sentence-level breakdown, multi-language support, batch processing, and API access, serving students, educators, publishers, marketing teams, and compliance officers globally. Measured figures are GPT0 first-party data — project records, user database, and billing analytics — covering May 2025 and the three months after launch. Figures originating from the authentication platform's specification or service-level agreement rather than from GPT0's own instrumentation are labelled as such in the results table and are not presented as measured outcomes. The four-to-six week self-build estimate is a counterfactual planning figure for a project that was never run. Hour-level attribution between AI-assisted and unassisted work is our own categorisation of the project record. Our authentication vendor, MojoAuth, documents this integration from its side against the identical measured figures; that write-up is the GPT0 case study.