NexaAI: The AI SaaS That Treats Vendors Like Building Blocks

How a lean stack turns Gemini, Cloudinary, Clerk, and Neon into one unified product, and why the smartest layer is the glue between them.

8 min read • View on GitHub • More from JasminChauhan

A wide editorial illustration of a switchboard operator routing cords between four distinct machines: a model terminal, an image processor, a database vault, and an identity ledger. It explains that the product's real power is orchestration, not a single all-powerful model. — NexaAI works like a broker for capabilities. The product decides where each task should go, then hides the plumbing behind one interface.

Key Takeaways

NexaAI is less interesting as an AI model than as a routing layer that turns vendor APIs into one product.
The stack stays lean by pushing auth, quota state, storage, and even image processing into outside services.
Using Gemini through the OpenAI SDK makes the app feel model-agnostic while keeping the code path simple.
The architecture is fast to ship, but it also binds product logic to the rules of its vendors.

The product is a broker, not a model

NexaAI’s sharpest idea is structural. It does not try to win by training a better foundation model. It wins by deciding which service should do which job, then hiding the routing behind one interface.

That matters because the product spans text generation, image manipulation, and document analysis. In most apps, those are separate systems with separate storage, auth, and billing paths. Here, they are different branches of the same control layer.

The result is a classic lean SaaS move: keep the backend thin, let vendors do the heavy lifting, and spend your complexity budget on orchestration.

A SaaS stack built from identity, storage, and AI APIs

The request flow is the product architecture. Access control, quota state, model routing, and persistence each live in a different layer, but the user experiences one app.

The stack breaks into three jobs. Clerk handles identity and quota state. Neon stores the durable record of creations. External APIs handle generation and transformation.

That split keeps the database small. The app does not need a heavy user table full of product metadata, because some of that state lives inside the identity layer itself. For a prototype, that is elegant. For a larger system, it becomes a trade-off, not a free lunch.

// Conceptual flow
const user = await auth();
const quota = user.privateMetadata.free_usage ?? 0;

if (!user.publicMetadata.premium && quota >= FREE_LIMIT) {
  throw new Error('Free limit reached');
}

const result = await generateWithVendorService(input);
await db.insert('creations', { user_id: user.id, output: result });
await clerk.users.updateUserMetadata(user.id, {
  privateMetadata: { free_usage: quota + 1 }
});

The most interesting trick: AI compute is outsourced twice

A close-up editorial illustration of a hand placing a tiny token labeled free_usage into an identity ledger box while another hand sends a request through a narrow gate toward a database and a model engine. In the background, a cloud machine stamps image files with removal and transformation seals. It explains how usage policy and compute live in different vendors. — The clever part is not just outsourcing model calls. It is letting identity metadata act like product policy while Cloudinary and Gemini handle the work.

The first trick is the model bridge. NexaAI uses the OpenAI SDK against Gemini’s OpenAI-compatible endpoint, so the application speaks one client interface while pointing at another backend. That gives the code a stable shape even if the model vendor changes.

The second trick is image work. Cloudinary is not just a file store here. It becomes an AI image engine for tasks like background removal and object removal, which means the app can ship image features without managing its own vision stack.

Dimension	Traditional AI app	NexaAI
Model integration	One vendor, one SDK, one stack	OpenAI SDK interface routed to Gemini
Image processing	Separate custom pipeline or dedicated service	Cloudinary AI effects do the heavy lifting
Quota tracking	Own billing tables and usage records	Clerk private metadata stores free usage
System of record	Application database holds everything	Neon stores creations, identity stores policy
Operational load	More services to run and sync	Fewer moving parts, more vendor dependence

How the request flow actually works

The request lifecycle is straightforward once you strip away the product surface. A user acts in the UI. The protected layout checks session state. Middleware checks usage. The controller picks a path. Then the result is persisted and the quota is incremented.

That sequence is the story. The app does not ask, “What is the AI doing?” It asks, “Which external capability should answer this request, and what state do we need to remember afterward?”

UI action → Clerk session check → free_usage lookup → route to controller → 
OpenAI SDK to Gemini OR Cloudinary transform OR document analysis → 
write to Neon creations table → increment usage → return response

Stage	What happens	Why it matters
Access control	Protected layout blocks anonymous users	The dashboard stays simple because auth is front-loaded
Quota check	Private metadata supplies free_usage	The app avoids a separate quota schema
Generation	Controller routes to the right vendor	The backend stays thin and modular
Persistence	Neon stores the creation record	Outputs become durable and queryable
Usage update	Identity metadata increments after success	Billing logic stays close to identity

Why Clerk metadata is a clever, slightly risky shortcut

Storing free_usage in Clerk private metadata is a smart shortcut. It removes a join, skips a custom quota table, and keeps the MVP moving.

But the same shortcut also couples product policy to identity infrastructure. If the quota logic grows more complex, or if you need richer audit trails, the convenience starts to fade. The app gets lighter, but the identity layer gets more critical.

Using Clerk metadata	Using your own quota table
Fast to implement	More schema work
Less database chatter	More explicit history
Tight coupling to auth vendor	More control over policy
Good for small products	Better for complex billing

What this architecture buys, and what it gives up

NexaAI buys speed. It also buys a certain kind of product clarity. Each vendor has one job, and the app composes those jobs into a single experience.

What it gives up is control. Vendor abstractions can change. APIs can shift. Pricing can move. The more elegant the composition layer becomes, the more the app depends on other companies keeping their promises.

That is not a flaw unique to NexaAI. It is the trade-off of modern SaaS architecture. The winner is often the team that can turn outside capabilities into a coherent workflow faster than competitors can build them in-house.

Upside	Downside
Fast shipping	Vendor lock-in
Small backend	Less internal control
Flexible feature mixing	API surface drift
Lower ops burden	Higher dependency risk

The bigger pattern: AI apps are becoming orchestration layers

NexaAI is a compact example of a broader shift. The valuable layer is moving up the stack, from model ownership to service composition.

That does not mean models stop mattering. It means product differentiation is increasingly about routing, policy, and experience. The smartest part of the app is often the glue between vendors.

NexaAI makes that idea concrete. It is not trying to be the brain. It is trying to be the control plane.