DEV Community: Кирилл Несмелов

How I added Gemini + GPT-4 + Claude support in one settings toggle (Next.js SaaS)

Кирилл Несмелов — Tue, 23 Jun 2026 12:30:06 +0000

Build log from this week: I added multi-provider AI support to Melororium — users can now switch between Gemini, ChatGPT, and Claude in workspace settings, and it applies across the whole platform.

Here's the pattern I used.

The problem with hardcoding one provider
I had Gemini wired directly into every AI action. Every ai.ts function called the Gemini SDK. If a user wanted a different provider, I'd have to touch every function.

Beyond the code problem: different teams have different constraints. Some can't send data to Google's servers. Some are standardized on OpenAI internally. Forcing one provider was my product decision intruding on their infrastructure policy.

The solution: one adapter layer
I created a single getAIClient() function that reads the workspace's aiProvider setting from the DB and returns the right SDK client:

export async function getAIClient(workspaceId: string) {
const settings = await getWorkspaceSettings(workspaceId);

switch (settings.aiProvider) {
case 'openai':
return new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
case 'anthropic':
return new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });
default:
return new GoogleGenerativeAI(process.env.GEMINI_API_KEY);
}
}
Every AI action calls getAIClient() first. Prompt construction, response parsing, and error handling stay the same regardless of which client gets returned.

Why BYOK matters here
Melororium uses BYOK (bring your own key). Users paste their own API key in settings. This keeps costs transparent — they see exactly what they're spending on AI inference. It also keeps me out of the billing relationship entirely.

The adapter pattern works cleanly with BYOK because each provider's key is stored separately in workspace settings.

One thing I'd do differently
Response shapes differ between providers. OpenAI, Anthropic, and Gemini return structured responses in slightly different formats. Right now I normalize them after the call in each action. A better approach would be a thin response adapter inside getAIClient() that normalizes everything before it returns. Planning to refactor that.

Also shipped this week
Along with the provider switching:

AI analytics at two levels: all-projects overview and per-project drill-down
Subtasks inside the task drawer (kanban nested structure)
Work timer day view redesigned to show graphical time blocks per team member
Per-worker timer breakdown with task-level detail
Building Melororium as a pay-once team workspace (one-time purchase, no subscription). Writing about the build as I go.

Anything you'd do differently with the provider switching pattern? Curious whether others use a similar adapter or something more formal.

I built a modular SaaS and let users bring their own AI. Here's why.

Кирилл Несмелов — Tue, 16 Jun 2026 08:18:08 +0000

I've been building Melororium — a lifetime project management workspace for small teams — and the two most interesting product decisions I made weren't about features. They were about what not to include by default.

The architecture problem with "all-in-one" tools

Every project management tool eventually tries to be everything. ClickUp added Docs. Notion added tasks. Asana added timelines. The result is tools that are bloated for most users and still missing the one thing you actually need.

When I started building Melororium, I kept asking: what does every team actually use every single day?

The answer was shorter than I expected:

Task management (Kanban + List + Calendar)
Time tracking inside tasks
Client CRM
Financial reporting + invoicing
Team management + work reports
Dashboards
That became the 12 core modules — shipped in every plan, no exceptions.

Everything else became opt-in. Not locked behind a higher tier. Just... not forced on you if you don't need it.

The AI decision

This is the one I want to talk about most.

When I built the first version of AI features, the obvious move was to pick one provider, wrap it, charge for it in a premium tier.

I didn't do that. Here's why.

First: teams already have AI preferences. Some are locked into OpenAI for compliance reasons. Some prefer Claude's reasoning for analytical tasks. Some use Gemini because they're already in the Google ecosystem. Making them switch providers — or pay twice for the same model through my platform — felt wrong.

Second: the margin math is bad for both sides. If I host the AI calls, I'm paying inference costs and either subsidizing them or marking them up. Neither is great. The user pays more than they should. I'm running a business I didn't sign up for.

Third: AI usage patterns are unpredictable. Some teams will use the AI analytics module ten times a day. Others will open it once a month. Flat-rate AI pricing is always wrong for someone.

So I built BYOK — bring your own API key.

export async function getAIClient(workspaceId: string) {
const settings = await getWorkspaceSettings(workspaceId);
switch (settings.aiProvider) {
case 'openai': return new OpenAI({ apiKey: settings.apiKey });
case 'anthropic': return new Anthropic({ apiKey: settings.apiKey });
default: return new GoogleGenerativeAI(settings.apiKey);
}
}
One function. Every AI action in the codebase calls getAIClient() first. Provider switching is a single workspace setting. Keys are encrypted at rest, never logged.

The user connects the provider they already use. They control the costs directly. I don't touch their inference budget.

The modular pricing that followed

Once I made AI opt-in, the same logic applied to other modules. Not every team needs the same stack.

The architecture became:

Core (12 modules) — included in every plan
Add-ons — picked at purchase, locked per license
Three tiers:

Starter — $149 once → 4 users, all 12 core modules
Agency — $299 once → 10 users, 12 core + pick 5 add-ons
Studio — $499 once → 25 users, 12 core + all announced add-ons
No recurring fees. No seat tax as you grow within your tier.

What this forced technically

Making add-ons genuinely modular — not just hidden behind a feature flag — meant the core and add-on layers had to be cleanly separated from day one.

Every module has its own data schema, its own API routes, its own UI surface. The workspace config object tracks which add-ons are unlocked. Every protected route checks the license before rendering.

It's more work upfront. But it means the codebase scales to 40 modules without becoming a tangled mess of conditional rendering and permission checks scattered everywhere.

Stack, if you're curious

Next.js 14 App Router, TypeScript, Tailwind. Vercel for deployment. The AI layer sits behind a clean adapter so swapping providers is a 5-line change per new integration.

Pre-launch now, founding price closes July 30. If you're building something and want to see how the modular add-on system works in practice, drop a question below — happy to go deeper on any part of the architecture.

How I built a switchable AI provider system in Next.js (Gemini GPT-4 Claude, one workspace setting)

Кирилл Несмелов — Wed, 10 Jun 2026 10:38:52 +0000

I had Gemini hardcoded into every AI function in my codebase. Then a beta user told me her clients have data policies about Google. I rebuilt the whole AI layer in two days. Here's the architecture.

The wrong way (what I had)

import { GoogleGenerativeAI } from "@google/generative-ai";
const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!);

export async function summarizeProject(projectId: string) {
const model = genAI.getGenerativeModel({ model: "gemini-1.5-flash" });
const result = await model.generateContent(prompt);
return result.response.text();
}
Works fine until you need to support another provider. Then you're touching every function.

The pattern: one factory, one interface

I defined a single AIClient interface that every provider implements:

export interface AIClient {
complete: (prompt: string, systemPrompt?: string) => Promise;
}
One factory function reads the workspace setting and returns the right client:

export async function getAIClient(workspaceId: string): Promise {
const { aiProvider } = await getWorkspaceSettings(workspaceId);

switch (aiProvider) {
case "openai": return createOpenAIClient();
case "anthropic": return createAnthropicClient();
default: return createGeminiClient();
}
}
Each factory wraps the provider SDK behind the same interface:

export async function summarizeProject(projectId: string, workspaceId: string) {
const ai = await getAIClient(workspaceId);
const data = await getProjectContext(projectId);
return ai.complete(buildPrompt(data), "You are a project analyst.");
}
Three decisions worth explaining

Workspace-level, not user-level. Project data belongs to the workspace. The whole team should have the same answer to "what AI provider processes our data?" — not "depends who's logged in."

No silent fallbacks. If the selected provider fails, the error propagates. I don't retry with another provider. If someone chose Claude for compliance reasons, silently falling back to Gemini is worse than an explicit error.

Per-request factory call, not module-level cache. Workspace settings can change. Module-level caching means the old provider keeps running until the function cold-starts. The extra DB read per AI call is negligible next to the actual inference cost.

The one thing the pattern doesn't solve

Different models behave differently on the same prompt. Claude follows system prompts very tightly. GPT-4 tends verbose without explicit length instructions. I handle this with thin per-provider prompt adjustments in the factory. It's not elegant but it works.

If you've solved the "same prompt, different model behavior" problem more cleanly — I'm curious how.

Building Melororium — pay-once project management for freelancers. Launching July 30.

Day 7: 51 people answered my question. I wasn't ready for what they said.

Кирилл Несмелов — Mon, 08 Jun 2026 13:18:22 +0000

Day 7: 51 people answered my question. I wasn't ready for what they said.
Last week I asked: "What convinced you to switch away from a subscription tool — or what's keeping you locked in?"
51 people answered. I read every single one.
I expected arguments about SaaS economics. Or "subscriptions are fine, you get what you pay for."
Instead, almost every answer was some version of the same thing:
"I already left. I use free Notion + Trello + a spreadsheet I built myself. I stopped paying because I refused to keep feeding the machine."
Nobody is sitting around waiting for a better subscription-free tool. They've already quit — and they're living with the consequences of their DIY stack. Things that don't connect. Manual exports every Friday. Three browser tabs open at once just to see where a project stands.
That one insight shifted how I think about who I'm building https://melororium.com for.
It's not someone who's currently paying $50/month for ClickUp and angry about it. It's someone who already said "no" — months ago — and built their own janky workaround. I'm building for the person who quit before I showed up.
So let me show you what I've actually built.
This is the part where I want to be specific, because "almost done" is the oldest lie in indie building.
I recorded a short walkthrough this week — nothing polished, just the real product as it exists right now:
https://youtu.be/Sa35DwMXAOQ
Here's what you'll see working:
Kanban board — full drag-and-drop, columns, task cards, assignees. Not a prototype. The thing I actually use every day to run my own work. You can move a task from "In Progress" to "Done" and it updates across every view instantly.
Tasks — complete system. Priorities, deadlines, subtasks, descriptions, comments. The boring stuff that actually matters when you're juggling 6 clients and can't afford to forget anything.
Clients — bring your clients in, attach projects to them, see everything related to one client in a single view. No more searching through Notion pages or scrolling through Slack to find what you promised someone.
Team members — add the people you work with. Assign tasks to them. See who has too much on their plate before they send you a panic message at 11 PM.
Work hours analytics — full time tracking with real reports. Not just "hours logged" — actual breakdown by client, by project, by task. The numbers a freelancer or small agency actually needs to answer: am I making money on this client or just staying busy?
Calendar integration — deadlines and tasks sync so your week looks like one thing, not three disconnected apps all demanding attention at the same time.
We're on the finishing straight. The core is done. Right now I'm working through the last small fixes before the founding release — and building one more thing.
What I'm building next:
A direct AI assistant integration. Not "AI features" as a marketing checkbox — a way to create tasks, log work, and get a weekly project summary just by talking to it.
The goal: you finish a client call, you tell the assistant what was discussed, the workspace updates itself. No context switching. No manual note-taking after every conversation.
I'm building this because I tracked my own time one week and found I was spending 5+ hours just on admin — logging work, reorganizing tasks, writing status updates that nobody reads. That time should not exist.
The wishlist is open right now.
While the product isn't publicly released yet — founding access opens July 30 — the waitlist is live at https://melororium.com
If you reserve a spot now, you lock in the founding price: $199 one-time. No subscription. Ever.
After launch the price goes up permanently. I'm not doing artificial scarcity — I just can't keep the founding price open indefinitely once real support costs kick in.
We also built a referral system this weekend: bring 1 paying friend → 5% off your price. Bring 5 → 10%. Bring 30 → 50%. All the discount stacks get applied at launch in July. Full pricing breakdown at https://melororium.com/pricing
Day 7 real numbers:
2 clicks from Google. First organic visitors ever. The site is already appearing at position 5 on some queries after 7 days — which genuinely surprised me
Product Hunt launch: Tuesday June 9. Auto-scheduled. No PR, no budget, no influencer outreach. Just the story and whatever this community thinks of it
0 paying customers. Still intentional. I want founding members who understand what they're getting into, not impulse purchases
40+ published articles on the site. Probably only 8 of them are indexed by Google so far. The rest are sitting there waiting to be discovered
The scary part about being this close to done: "done" isn't really a thing in software. You ship, people use it, something breaks, something's missing, something that seemed obvious to you makes no sense to anyone else.
The real work starts July 30.
But I know this: the people who've been running DIY stacks for two years — free Notion plus a spreadsheet plus three browser tabs — are going to open this and immediately understand it. No pitch needed. No onboarding email sequence. Just: oh, this is what I was trying to build myself.
That's who I built it for.
Question for this week: If you're running a DIY productivity stack right now — what's the one thing about it that drives you the most crazy? The thing you've accepted as "just how it is" but secretly hate?