DEV Community: Tobiloba Ayomide

Rethinking Trust Boundaries in Auth and Billing Flows

Tobiloba Ayomide — Mon, 18 May 2026 13:10:53 +0000

When subscription logic first gets added to an app, it usually starts in the most convenient place: the frontend. The browser handles the UI, initiates checkout, reacts to redirects, and often ends up carrying more responsibility than it should.

That approach works early on, but it creates a structural problem. The browser is a useful interface layer, but it is not a reliable trust boundary for payment-sensitive decisions.

I recently reworked my application so billing and authentication flows no longer depend too heavily on browser-trusted state. Instead, authenticated billing operations now run through server-validated routes, session transport is tightened in production, and subscription state is synchronized through reconciliation and webhook-driven updates rather than optimistic UI assumptions.

The goal was not to “make the app secure” in some absolute sense. The goal was to make the system more correct, more defensible, and easier to reason about when authentication and billing state diverge.

The Problem With Client-Shaped Billing Flows

A lot of billing implementations become frontend-heavy by accident.

It usually happens through a series of reasonable decisions. The client starts checkout. The client handles the redirect back. The client updates plan state immediately. The client becomes the first place subscription state is interpreted.

The problem is that those are not equivalent events.

A redirect is a user experience event. It is not proof that the local application state is correct. Once money and account access are involved, that distinction matters.

The more billing state depends on browser timing, browser assumptions, or optimistic UI updates, the harder it becomes to trust the system when something goes wrong.

The Architectural Shift

The main change was simple: the browser should request billing actions, but it should not be the authority on billing outcomes.

That led to a cleaner model:

The New Model:

Browser requests an authenticated server route.
Server validates the session.
Server interacts with the billing provider.
Database records the persistent update.
Client receives a normalized response.

In this model, the browser handles interaction, the server validates identity, the billing provider confirms commercial state, the database records entitlement, and webhooks correct subscription drift over time.

This was the real shift. The browser stopped acting like the system of record for billing state.

Why This Boundary Matters

When billing logic sits too close to the browser, a few failure modes become common. Stale UI state gets mistaken for real entitlement. Redirects are treated as successful activation. Provider and app state drift apart. Billing correctness becomes harder to audit. Failures become harder to localize.

Moving billing behind server-validated flows does not remove complexity. It moves that complexity into a more appropriate runtime.

That is an important distinction. Good architecture is not about having less logic. It is about putting logic in the right place.

How I Actually Made the Change

I made the change in four parts.

1. I moved billing-sensitive actions behind authenticated server routes
Instead of letting the browser directly coordinate plan reads, billing management, and checkout logic, the client now talks to server-controlled endpoints.

That matters because billing routes should not trust arbitrary browser state. They should first prove who the caller is.

A simplified pattern looked like this:

export const authenticateUserRequest = async (req: ApiRequest, res?: ApiResponse) => {
  const session = await resolveSessionFromApiRequest(req);
  const userSupabase = createUserScopedSupabaseClient(session.accessToken);

  const { data: profile } = await userSupabase
    .from('profiles')
    .select('account_status')
    .eq('id', session.user.id)
    .maybeSingle();

  if (profile?.account_status === 'suspended') {
    throw new HttpError(403, 'This account is suspended.');
  }

  return {
    supabase: userSupabase,
    user: session.user,
  };
};

This was the first important boundary correction. Billing routes no longer relied on the browser to define the user context.

2. I tightened session handling in production
The next step was to stop treating session transport as an afterthought.

In production, the app now treats session cookies differently and ties that behavior to secure deployment conditions.

A simplified example:

const getIsSecureCookie = (): boolean =>
  process.env.NODE_ENV === 'production' || process.env.VERCEL_ENV === 'production';

That lets the application issue cookies with stricter attributes such as Secure, HttpOnly, and SameSite=Lax.

This does not solve security on its own, but it does narrow the attack surface around authentication and session transport. More importantly, it aligns production auth behavior with the sensitivity of the billing flows it protects.

3. I stopped treating checkout redirects as proof of subscription activation
A user returning from checkout does not automatically mean the app’s local billing state is correct.

That is why I added reconciliation after the return flow.

The idea was simple. The user starts checkout. The billing provider handles payment. The user returns to the app. The app triggers reconciliation. The server verifies provider-side state. Local entitlement updates only after verification.

A simplified request looked like this:

const response = await fetch('/api/plan?view=reconcile', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  credentials: 'include',
  body: JSON.stringify({ customerSessionToken }),
});

That extra step matters because return URLs are UX signals, not trust anchors.

4. I added webhook-driven subscription synchronization
Even reconciliation on return is not enough by itself.

Subscriptions change over time. Renewals happen. Cancellations happen. Revocations happen. Those events should not depend on the user actively sitting inside the billing page.

That is where provider webhooks became important.

The backend flow became:

Billing provider event
-> webhook endpoint
-> signature verification
-> event normalization
-> user resolution
-> subscription state update

This made provider events part of the architecture instead of pretending the frontend was the primary coordinator of subscription truth.

A Typical Billing Read After the Change

Once the redesign was in place, even a plan or billing read followed a different shape.

A simplified version looked like this:

if (view === 'billing') {
  const { supabase, user } = await authenticateUserRequest(req, res);
  const customerState = await fetchProviderCustomerState(user.id);

  const subscriptionSummary = customerState
    ? resolveSubscriptionSummary(customerState)
    : null;

  sendJson(res, 200, {
    billing: {
      hasActiveSubscription: subscriptionSummary !== null,
      status: subscriptionSummary?.status ?? null,
      recurringInterval: subscriptionSummary?.recurringInterval ?? null,
      currentPeriodEnd: subscriptionSummary?.currentPeriodEnd ?? null,
    },
  });
}

The point is not the exact implementation. The point is the decision flow: authenticate first, query provider state on the server, normalize the result, and return a constrained response to the client.

That is a stronger model than letting the browser infer too much.

Why HTTPS and Secure Cookies Matter Here

This change also made HTTPS more meaningful.

It is important to be precise here: HTTPS does not magically stop JavaScript attacks, and it does not replace XSS prevention.

What HTTPS does do in this architecture is protect session-bearing requests in transit, support secure cookie behavior in production, and reduce the chance of sensitive auth transport being treated casually.

So the right claim is not that HTTPS solved frontend security.

The right claim is that HTTPS and secure cookies became part of a larger design where auth and billing moved into server-validated flows.

What This Solved

This redesign improved a few things immediately.

It reduced how much billing logic depended on client state. It made the server responsible for validating identity before billing operations ran. It created a clearer distinction between interaction state and entitlement state. It also made debugging easier, because failures became easier to trace to one of a few boundaries: session validation, provider interaction, reconciliation, persistence, or webhook delivery.

Most importantly, it changed the browser’s role from authority to requester.

That is the right direction for any application where subscription state controls access.

What It Did Not Solve

This kind of redesign should not be overstated.

It did not eliminate XSS, authorization bugs, bad secret hygiene, broken webhook verification, environment drift, or incorrect sandbox/live billing configuration.

What it did do was establish a stronger foundation: less browser authority, clearer trust boundaries, more reliable billing state, and better separation between interaction and decision-making.

That is a meaningful architectural improvement even though it is not a complete security story on its own.

Closing Thought

The biggest lesson from this change was that billing is not just a payments feature. It is a trust-boundary problem.

Once I started treating it that way, the architecture became much clearer. The browser initiates. The server validates. The provider confirms. Persistent state records entitlement. Webhooks correct drift over time.

That model is harder to get wrong than a client-heavy billing flow, and it scales much better as the application becomes more real.

Building ResumeeNow: The Engineering Behind an AI-Powered Resume Platform

Tobiloba Ayomide — Wed, 08 Apr 2026 19:13:36 +0000

How I built an AI-powered resume app with resume parsing, ATS audits, cover letter generation, and reliable PDF export.

A few forms, a live preview, a couple of templates, a PDF export button, and that would be it.

That assumption did not last long.

As soon as I added resume import, AI tailoring, ATS audits, cover letter generation, and export that actually had to look right on paper, the project stopped being a simple CRUD-style frontend. It became a set of connected systems that all had to agree with each other.

That was the real challenge.

The hard part was not just building screens. The hard part was making import, editing, AI workflows, export, notifications, and account-aware behavior feel like one coherent app.

What I Was Actually Building

At first, I described ResumeeNow as a resume builder.

A more accurate description now is this: it is an AI-powered resume platform where users can import an existing resume, edit it in a structured builder, tailor it for a role with AI, run an ATS audit, generate a cover letter, and export a polished PDF.

That shift matters, because it changed the engineering constraints.

A simple form app can get away with loose state and one-directional flows. This project could not. The moment imported data, AI-generated content, and exported documents all had to match, I needed stronger architecture and clearer boundaries.

The Stack I Chose
I built ResumeeNow with:

React 19
Vite 7
TypeScript
Tailwind CSS 4
React Router 7
React Query 5
Zustand 5
Supabase Auth + Postgres
Vercel API routes
Supabase Edge Functions
pdfjs-dist, unpdf, and mammoth
Playwright Core for browser-based PDF rendering
Zod for validation

That stack let me move quickly, but only because I kept the responsibilities separated.

On the frontend, routes, builders, dashboards, and templates live in their own feature layers. On the backend, privileged behavior lives in API routes, and AI calls go through a dedicated gateway instead of being scattered across the client.

High-Level Architecture

The easiest way to understand the project is to look at it as four user-facing surfaces backed by two server runtimes.

This architecture evolved naturally from the project requirements.

The landing page and docs are public. The dashboard and builder are authenticated. Admin routes are privileged. AI goes through a separate edge function. Export goes through a server-rendered print path. Notifications go through a dedicated delivery route.

Once I accepted that the project had multiple surfaces with different risks, the codebase became much easier to reason about.

1. Splitting the App Into Clear Surfaces

One of the smallest but most important decisions I made was separating the app by route boundaries.

Instead of letting everything live inside one giant application shell, I split public, protected, print, and admin flows at the router level.

Source Spotlight: Router Boundaries

<Route path="/print/resume" element={<ResumePrintPage />} />
<Route path="/" element={<LandingPage />} />
<Route element={<ProtectedAppLayout />}>
  <Route path="/dashboard" element={<Dashboard />} />
  <Route path="/builder/:id" element={<BuilderPage />} />
  <Route element={<AdminRouteLayout />}>
    <Route path="/admin" element={<Admin />} />
    <Route path="/admin/users" element={<AdminUsers />} />
  </Route>
</Route>

This looks simple, but it carries a lot of architectural meaning.

The print surface is isolated. The public landing page stays outside the protected app. Admin routes sit behind their own gate. That kept responsibilities clear and prevented the project from turning into one overgrown frontend where every page inherited assumptions it should not have had.

That separation also helped later when I added more backend behavior. Once the route boundaries were clear, it was easier to decide what belonged in the client and what needed to move behind server-side contracts.

2. Resume Import Turned It Into a Real System

The feature that changed the nature of the project most was import.

It is easy to build a resume editor when users start from empty fields. It is much harder when they upload a PDF and expect the app to turn it into clean, editable data.

That forced me to build a parsing pipeline.

Import Pipeline

The import route does not just accept a file and hope for the best. It authenticates the request, validates the upload, extracts text on the server, checks whether the text is usable, and only then hands it off to the parser that produces structured resume data.

Source Spotlight: Import Route

const joined = modules.cleanupSectionText(pageTexts.join('\n\n'));
if (!modules.isReadableDocumentText(joined)) {
  throw new Error(
    'Could not extract reliable text from this PDF. This often happens with scanned or image-based PDFs without OCR.',
  );
}

That was one of the best product decisions in the whole project.

Bad parsing is worse than a clear failure message. If the app cannot build trustworthy editor state from a file, it should say so.

3. The Builder Had to Become a Stable Data Model

Once import existed, the builder could no longer be a loose collection of inputs.

I needed one normalized resume shape that could support:

manual editing
imported data
AI-generated rewrites
multiple templates
live preview
PDF export
persistence and reload

That changed how I thought about the project.

What users experience as “a resume editor” is actually a coordination layer between domain data, UI editing, template rendering, and export. If those layers drift apart, the app becomes fragile very fast.

So the builder evolved into a set of dedicated modules: domain types for resume data, builder hooks for controller logic, preview components for document rendering, and export helpers that validate payloads before they ever reach the print surface.

That was one of the clearest moments where the project stopped feeling like a page and started feeling like an application.

4. AI Could Not Just Be a Button

One of the core facts about ResumeeNow is that it is AI-powered.

But I did not want AI to be a marketing label or a thin prompt wrapper. I wanted it to behave like real infrastructure inside the project.

The app currently supports three main AI workflows:

AI Tailor
ATS Audit
Cover Letter generation

What made those workflows hard was not only generating text. It was controlling them properly.

I needed session validation, plan-aware access, rate limiting, concurrency handling, usage tracking, and a clear boundary between client requests and model execution. That is why AI goes through a dedicated edge function rather than being called directly from random components.

Source Spotlight: AI as a Policy Boundary

const { data: aiGate, error: aiGateError } = await supabaseClient
  .rpc("begin_ai_request", { user_id_param: user.id })
  .single();

beginRequest = aiGate as BeginAiRequestResult | null;

if (aiGateError || !beginRequest) {
  throw new HttpError(500, "Failed to begin AI request.", {
    error: "AI_GATE_FAILED",
    details: aiGateError?.message || "Unknown error",
  });
}

This was an important shift in how I treated AI.

The model call itself is not the whole feature. The surrounding system is the feature. Who can use it? How often? Under what plan? What happens if two requests collide? How do credits and limits behave? How does the result plug back into the builder without feeling detached?

That is why the AI layer in this project feels more like a workflow engine than a single API call.

5. PDF Export Became Its Own Engineering Problem

In a resume app, export quality is not optional.

The PDF is the thing users actually send to recruiters, hiring managers, and application portals. So it had to be reliable.

I quickly learned that “export to PDF” is not just a button. It is its own rendering problem.

I needed:

consistent page sizing
reliable font loading
print-specific rendering
predictable pagination
a server-side render path
parity between what the user sees and what gets downloaded

That is why export goes through a dedicated print surface and a browser-based render path rather than trying to serialize arbitrary client HTML directly.

Export Flow

flowchart LR
  A[Builder state] --> B[Validated export payload]
  B --> C[/api/export-pdf]
  C --> D[/print/resume]
  D --> E[Wait for print readiness and fonts]
  E --> F[Chromium render]
  F --> G[Final PDF]

The trickiest part here was page breaks. A resume looks cheap very fast if the layout splits in the wrong place.

Source Spotlight: Pagination Logic

while (unit.bottom > pageBoundary + BREAK_TOLERANCE_PX) {
  const nextBreak =
    unit.top > currentPageStart + BREAK_TOLERANCE_PX
      ? unit.top
      : pageBoundary;

  currentPageStart = nextBreak;
  breaks.push(nextBreak);

This is one of those tiny pieces of code that carries a much bigger idea.

I was not relying on the browser to “figure it out.” I added explicit page-break calculation based on measured layout units so lines and blocks would break more predictably across A4 pages.

That made export feel much more trustworthy.

6. The Invisible Operational Work Mattered a Lot

Some of the least visible parts of the project ended up being some of the most important:

authentication
account status checks
notification preferences
notification delivery state
admin access control
audit logging
plan-aware AI usage

These are not flashy features, but they are the difference between a demo and a real app.

A good example is notification delivery. I did not want notification sending to be a loose fire-and-forget action. I wanted it to behave like a tracked event with preference checks, deduplication, and delivery status.

Source Spotlight: Notification Deduplication

let existingEvent: NotificationEventRecord | null = null;
if (isOneTimeType) {
  existingEvent = await getExistingOneTimeEvent(
    supabase,
    user.id,
    requestBody.type,
  );
  if (existingEvent && existingEvent.status !== 'failed') {
    res.status(200).send('Notification already handled.');
    return;
  }
}

This kind of logic is boring in the best way.

A welcome email should not send twice because a request retried. A waitlist event should not duplicate itself. AI usage alerts should not spam the user multiple times in the same day. Once I started thinking in terms of event state instead of just “send email now,” the system got much more robust.

The same thinking showed up in the admin layer too. Riskier actions were pushed through server-side helpers with explicit role checks and audit logging instead of being casually mixed into normal client behavior.

7. Testing the Quiet Failures

I did not approach testing as a blanket “write tests for everything” exercise.

Instead, I focused on the parts of the project that could quietly break trust:

export payload normalization
pagination behavior
inline formatting
AI request control
persistent cache behavior
runtime validation
ATS audit logic

These are not always the most visible things in the UI, but they are the places where regressions hurt most. If export starts producing subtle layout errors or AI request behavior becomes inconsistent, users do not always know why. They just stop trusting the app.

That is why a lot of my testing effort went into the seams between features rather than the flashy surface layer.

8. What I Would Do Differently

If I were building ResumeeNow again from scratch, I would do a few things earlier.

I would document the architecture sooner. The project grew from “resume builder” into a multi-surface system faster than I expected, and clearer internal docs would have saved time.

I would also split some server modules earlier. The notification route, for example, now owns parsing, authentication, preferences, deduplication, persistence, email construction, and delivery behavior. It works, but it is already a clear signal for future refactoring.

And I would formalize some contracts earlier, especially around the AI and export paths, because those are the places where frontend and backend assumptions get tightly coupled.

Final Thoughts
Building ResumeeNow taught me something I keep coming back to:

the complexity of a project usually hides in the workflows between features, not in the feature list itself.

The hard part was not making a resume builder UI.

The hard part was making all of these work together cleanly:

imported document text
normalized builder state
AI-assisted workflows
ATS audit behavior
cover letter generation
PDF rendering
notification delivery
account-aware permissions

That is what made the project interesting.

ResumeeNow started as a simple idea. What I ended up building was an AI-powered system of parsers, renderers, workflows, and boundaries that all work together to make the app feel simple.

And that, more than anything else, is what this project taught me: simple products are often powered by a lot of invisible engineering.

Check Out the Project

If you want to explore the code, architecture, and implementation details more closely, the ResumeeNow repository is available here:

GitHub Repo

I’m still improving the project, especially around architecture, AI workflows, and export reliability, but this build taught me a lot about what it really takes to turn a simple app idea into a more complete system.