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

I used 10 parallel Claude Code agents to audit 291 SEO pages at once. Here's what we found.

Кирилл Несмелов — Wed, 05 Aug 2026 07:00:19 +0000

have 291 pages on melororium.com. All of them generate from a TypeScript data layer. One person wrote all the content. Me.

The problem: I cannot audit 291 pages manually. No practical attention span for it. By the time I check page 50, I have forgotten what I saw on page 12.

So I built a multi-agent workflow with Claude Code.

The setup
Claude Code lets you spawn parallel subagents via the Workflow tool. You can structure work as phases — some sequential, some parallel — and give each agent a specific, bounded job.

The audit phase runs 10 agents in parallel. Each agent checks one quality dimension across all 291 pages simultaneously:

// SEO Audit Workflow — pseudocode
// 10 parallel agents, 291 pages, ~20 minutes total

const auditPhase = {
type: "parallel",
agents: [
{ id: "seo-desc-auditor", task: Check all seoDesc fields. Length must be 145-160 chars. Flag forbidden phrases: 'freelancer', 'lifetime deal', 'pay once'. Flag old prices: $149, $299, $499. },
{ id: "pricing-auditor", task: Scan all content for old prices ($149/$299/$499). Current correct prices: Starter $29/mo, Agency $59/mo, Studio $119/mo. Report every location where old prices appear. },
{ id: "dead-link-checker", task: Verify all internal links. Every /task-tracker/* route must exist. Every /pricing link must resolve. Report broken paths. },
{ id: "editorial-note-scanner", task: Find developer notes visible in rendered content. Patterns: 'Context:', 'CTA here', 'Note:', 'TODO', 'PLACEHOLDER'. These must not appear in production article bodies. },
{ id: "duplicate-faq-auditor", task: Find FAQ answer blocks reused across more than 2 posts. Exact-match comparison across all blog content. Flag duplicates with locations. },
{ id: "schema-auditor", task: Validate JSON-LD schema markup on all pages. Required fields must be present. No undefined or null values in required positions. },
{ id: "linkbox-auditor", task: Check all CTA linkBox labels. Correct label: 'Melororium'. Flag any instance of 'Melororium Task Tracker' or other variants. },
{ id: "internal-link-auditor", task: Find posts that mention pricing but lack a /pricing link. Find posts that describe features but lack matching /task-tracker/* links. Report gaps. },
{ id: "compare-data-auditor", task: Verify competitor pricing on comparison pages. ClickUp Business = $12/seat/month. Asana = $11/seat/month. Flag any value that differs from current public rates. },
{ id: "audience-targeting-auditor", task: Flag any seoDesc or H1 targeting 'freelancer', 'solo', 'self-employed'. Melororium targets teams of 4-25. Wrong audience targeting = wrong queries. }
]
};
Each agent reads the relevant data files, runs its check, writes findings to a shared results file. Total time: about 20 minutes for all 291 pages.

What it found: 155 defects
The critical ones:

35 sections with developer notes in production. Strings like "Context: Natural mention — include CTA here" were inside published blog article bodies. Not in HTML comments. In rendered text. Google crawled those pages. Real visitors read that text. I shipped scaffolding to production and left it there for weeks without noticing.

28 linkBox labels with wrong product name. CTA buttons across the site said "Melororium Task Tracker." That is the old product name. Inconsistent across 28 locations — this one was purely a find-and-replace problem that slipped past review.

7 posts with old pricing. Articles showed $149 as the price. The current Starter plan costs $29/mo. These articles predated the pricing model change and I never updated them. Any reader who hit one of those posts before the pricing page got the wrong product in their head.

11 seoDesc fields targeting wrong audience. Meta descriptions with "freelancer" or "solo" positioning. Melororium targets agencies and studios with 4 to 25 people. Wrong audience targeting ranks you for queries that drive visitors who will never convert.

The fix workflow
Parallel agents writing to the same large file cause conflicts. The main content file is 13,000 lines. For that file, I run sequential agents, each handling a line range:

// Fix Workflow — pseudocode
// Sequential for the big file, parallel for everything else

const fixPhase = {
mainFile: {
type: "sequential", // prevents write conflicts on one large file
agents: [
{ id: "fixer-1", task: "Fix all defects in content.ts lines 1-3250" },
{ id: "fixer-2", task: "Fix all defects in content.ts lines 3251-6500" },
{ id: "fixer-3", task: "Fix all defects in content.ts lines 6501-9750" },
{ id: "fixer-4", task: "Fix all defects in content.ts lines 9751-13000" }
]
},
otherFiles: {
type: "parallel", // separate files, no conflict risk
agents: [
{ id: "data-fixer", task: "Fix all defects across /data/.ts" },
{ id: "config-fixer", task: "Fix all defects across /lib/seo/.ts" }
]
}
};
The sequential phase handles the big file cleanly. The parallel phase handles everything else at the same time.

What I learned
The audit took 20 minutes. The fixes took 2 hours. That ratio tracks: finding defects at scale is fast, fixing them carefully is slow.

The harder lesson: 35 developer notes in production, weeks of Google crawling, and I had no idea. Manual review would not have caught them either. There is no realistic way to read 291 pages and spot scaffolding strings embedded in 13,000 lines of TypeScript.

Systematic auditing scales. Human review does not.

I will re-run this audit after deploy to verify the fixes landed correctly, then wire it into CI so it runs on every merge to main.

If you generate content at scale from a data layer, build the audit workflow before you hit 100 pages. Fixing 155 defects across 291 pages is a full day of work.

The stack: Claude Code with multi-agent Workflow, TypeScript content generation, Next.js on the front end. The site is melororium.com if you want to see the output. If you have done something similar or have thoughts on the parallel-vs-sequential tradeoff for large files, I want to hear it.

Building a CRM clients section: 8 technical decisions and why I made them

Кирилл Несмелов — Mon, 03 Aug 2026 10:53:59 +0000

When I started rewriting the clients section of Melororium (a team CRM for agencies), I expected a few days of work. It took three weeks. Not because the features were complex individually, but because the design decisions compounded — each one constrained the next.

This post documents eight decisions from that sprint: the problem each one solved, the alternatives I considered, and what the implementation looks like in practice. It is written for developers building similar systems.

The stack: Next.js App Router, Zustand for client state, Server Actions for mutations, PostgreSQL for persistence.

1. Client health score: client-side vs server-side

The requirement: A 0–100 score per client that reflects current relationship health, recalculating when relevant data changes.

I initially planned a server-side job: run every night, write scores to a health_score column, surface them in the UI.

I killed this after thinking through the latency. If a PM logs a contact call at 2pm, the score updates tomorrow morning. That breaks the core use case.

The solution: compute client-side from the Zustand store on every render.

The algorithm is additive:

base = 50

// Work signals
if (client.activeTasks > 0) score += 25
else score -= 15

if (client.activeProjects > 0) score += 10

// Contact recency
const daysSinceContact = diffInDays(today, client.lastContactDate)
if (!client.lastContactDate) score -= 10
else if (daysSinceContact <= 14) score += 15
else if (daysSinceContact <= 30) score += 5
else if (daysSinceContact <= 60) score -= 10
else score -= 25

// Follow-up
if (client.followUpDate) score += 5

return clamp(score, 0, 100)

This runs inside a useMemo with [clients, tasks, projects] as dependencies. Zero latency.

The tradeoff I accepted: no cross-session consistency. Two users compute the same score from the same data — fine. When one changes data, their view updates and the other's will on next render — also fine.

What I would add next: Invoice payment status as a negative signal.

2. Health buckets: three states not two

Most health score implementations produce a number and render it as a gradient. I wanted actionable buckets.

function getHealthBucket(client, score) {
const hasNoActiveTasks = client.activeTasks === 0
const neverContacted = !client.lastContactDate
const staleContact = diffInDays(today, client.lastContactDate) > 60

if (hasNoActiveTasks && (neverContacted || staleContact)) {
return 'dormant'
}
if (score < 50) {
return 'at-risk'
}
return 'healthy'
}

Dormant is not just "very low score." It specifically identifies: no active work AND (never contacted OR contact older than 60 days). These clients may have churned silently — they are not unhappy, they are just gone.

The reasons array builds in parallel with score calculation:

const reasons = []
if (!client.lastContactDate) reasons.push('Never contacted')
else if (daysSinceContact > 60) reasons.push(${daysSinceContact}d since contact)
if (client.activeTasks === 0) reasons.push('No active work')
if (overdueFollowUp) reasons.push('Follow-up overdue')

Renders as: "No active work · 47d since contact." The PM reading this row knows what to do.

3. Briefing status: three-state tracking

Requirement: Track whether a recipient received, opened, and responded to a briefing form.

Three states: Awaiting, Viewed, Responded. The middle state (Viewed) requires a tracking endpoint.

async function markBriefViewed(recipientId) {
await db
.update(briefingRecipients)
.set({ viewedAt: new Date() })
.where(eq(briefingRecipients.id, recipientId))
}

This fires on form page load. Known limitation: if the recipient forwards the link and a colleague opens it, the original recipient's record shows Viewed. Fixing this requires email-specific tokens — a larger implementation. For V1, Viewed means "the link was opened from somewhere."

4. Booking system: timezone handling

Requirement: Agency in Kyiv configures availability. Client in London books a slot. No timezone confusion.

Store all availability in the configured timezone. Convert to local timezone at display time in the visitor's browser.

function computeAvailability(date, config) {
const slots = []
const windowStart = setTimeInTz(date, config.startTime, config.timezone)
const windowEnd = setTimeInTz(date, config.endTime, config.timezone)

let cursor = windowStart
while (cursor < windowEnd) {
const slotEnd = addMinutes(cursor, config.duration)
if (slotEnd > windowEnd) break
slots.push({
startUtc: cursor.toISOString(),
endUtc: slotEnd.toISOString(),
})
cursor = slotEnd
}
return slots
}

Slots return as UTC ISO strings. The booking page component converts to the visitor's local timezone:

function formatSlotLocal(utcString) {
return new Intl.DateTimeFormat(navigator.language, {
hour: '2-digit',
minute: '2-digit',
timeZoneName: 'short',
}).format(new Date(utcString))
}

I limited to 16 timezone options rather than all 500+ IANA zones. A curated 16 is better UX than an exhaustive dropdown nobody can navigate.

The validation I almost missed: the slot window must accommodate at least one meeting. If duration is 60 minutes and window is 45 minutes, the system blocks you from publishing rather than showing an empty calendar.

5. CSV export: injection attack prevention

Client records sometimes start with formula characters: =, +, -, @. When a CSV opens in Excel, cells with these prefixes execute as formulas.

function sanitizeCsvCell(value) {
if (!value) return ''
const dangerous = ['=', '+', '-', '@', '\t', '\r']
if (dangerous.some(char => value.startsWith(char))) {
return '${value} // prefix with single quote
}
return value
}

A single quote prefix tells Excel to treat the cell as text, not a formula. The quote is invisible in the spreadsheet. The original value "=SUM(A1)" becomes '=SUM(A1) in the CSV and displays as =SUM(A1) in the sheet, inert.

This is not hypothetical. Melororium is multi-user. An agency might import contacts from an external source with crafted values. The person who exports the client list is not always the person who provided the data.

6. Document system: folder-based file management

Flat lists fail at scale. After 30 files, finding "the contract from March" requires metadata tags or memory. Hierarchical folders provide spatial memory.

interface ClientDocument {
id: string
clientId: string
folderId: string | null // null = root
name: string
size: number
mimeType: string
url: string
}

The UI limits navigation to two levels. Deeper nesting creates complexity that exceeds the benefit for typical agency file volumes.

The drag-and-drop zone uses a depth counter to handle nested drag events:

const [dragDepth, setDragDepth] = useState(0)
const isDragging = dragDepth > 0

const handleDragEnter = () => setDragDepth(d => d + 1)
const handleDragLeave = () => setDragDepth(d => d - 1)

Without this, dragleave fires when the cursor moves from the panel to a child element (a file row), falsely resetting drag state. The counter tracks depth and only clears when count reaches zero.

File size limit: 500MB. The cost is roughly $0.01/month per 500MB file. The constraint is upload reliability on slow connections. We mitigate with multipart uploads.

7. Recurring invoice detection in the invoice list

Invoices can be recurring. The invoice form stores recurring data in the notes field as a prefix: [Recurring: day 15 at 09:00] Original notes...

This was a schema constraint. The recurring metadata should be a separate column. It is not, because the invoice schema was locked before the recurring feature was designed, and migration was out of scope.

The solution: parse the prefix at render time.

const RECURRING_PREFIX = /^[Recurring: day (\d+) at (\d{2}:\d{2})]/

function extractRecurringInfo(notes) {
const match = notes?.match(RECURRING_PREFIX)
if (!match) return { isRecurring: false, cleanNotes: notes ?? '' }
return {
isRecurring: true,
day: parseInt(match[1]),
time: match[2],
cleanNotes: notes.replace(RECURRING_PREFIX, '').trim()
}
}

O(n) per invoice, paginated at 20-50 items — negligible cost. The cleanNotes field strips the prefix before displaying to the user. I document this as technical debt with a clear migration path.

8. Invoice aging: segment bar visualization

Aging data computed during the invoice list query:

interface AgingBuckets {
le30: number // 0-30 days overdue
d3160: number // 31-60 days
gt60: number // 60+ days
oldestDays: number // max days overdue
}

The bar renders three segments proportional to count. Edge case: if one bucket has zero invoices, its segment collapses to zero width:

// flex: count gives proportional widths
// flex: 0 with no minimum collapses to zero (not 1px line)

The oldestDays field drives a secondary indicator: if any invoice exceeds 90 days overdue, the entire stat card gets a red border regardless of bucket distribution.

9. Activity feed aggregation across event types

Requirement: A chronological feed per client showing all significant events, grouped by day.

Rather than a dedicated events table, I derive the feed from existing data on render.

function buildActivityFeed(client, tasks, invoices, documents, briefingResponses, bookings) {
const events = []

tasks.forEach(task => {
if (task.clientId === client.id) {
if (task.completedAt) {
events.push({ type: 'task_completed', date: task.completedAt, data: task })
}
events.push({ type: 'task_created', date: task.createdAt, data: task })
}
})

invoices.filter(inv => inv.clientId === client.id).forEach(inv => {
if (inv.paidAt) events.push({ type: 'invoice_paid', date: inv.paidAt, data: inv })
events.push({ type: 'invoice_sent', date: inv.sentAt || inv.createdAt, data: inv })
})

// ... similar for documents, briefings, bookings

return events.sort((a, b) => new Date(b.date).getTime() - new Date(a.date).getTime())
}

Memoized with useMemo and a dependency array. Re-computation only when source data changes.

Day grouping uses string comparison to avoid timezone bugs:

function groupByDay(events) {
return events.reduce((groups, event) => {
const day = event.date.split('T')[0] // '2026-07-31'
if (!groups[day]) groups[day] = []
groups[day].push(event)
return groups
}, {})
}

function getDayLabel(dateStr, today, yesterday) {
if (dateStr === today) return 'Today'
if (dateStr === yesterday) return 'Yesterday'
return new Intl.DateTimeFormat('en', { day: 'numeric', month: 'short', year: 'numeric' }).format(new Date(dateStr))
}

The path to a dedicated events table is non-breaking: add the table, write events on actions, fall back to derived feed for backfill.

10. State management: Zustand over context

The clients section reads the same data across many components simultaneously. A contact log update should ripple to the health score, the activity feed, and the billing section without prop drilling or a parent that re-renders everything.

React Context re-renders every consumer when any part of context changes. For 30+ clients with multiple computed values, that is expensive.

Zustand solves this with granular subscriptions via selectors:

// Billing tab only re-renders when clients change
const recurringClients = useClientStore(
state => state.clients.filter(c => c.recurring && c.monthlyPayment > 0)
)

// Health section subscribes to all three sources
const { clients, tasks, projects } = useClientStore(
state => ({ clients: state.clients, tasks: state.tasks, projects: state.projects })
)

Zustand does a shallow equality check on the selected value. If the selector returns the same reference, the component does not re-render.

Initial data loads server-side via Server Actions and hydrates the store. Mutations go through optimistic updates that update the store before the server confirms.

11. Bulk operations with optimistic updates

Select 8 clients, click "Create invoices." The user expects immediate feedback.

async function bulkCreateInvoices(clientIds) {
// Optimistic: mark all as pending immediately
clientIds.forEach(id => {
updateClientStore(id, { pendingInvoice: true })
})

// Parallel server requests
const results = await Promise.allSettled(
clientIds.map(id => createInvoiceAction(id))
)

// Resolve each independently
results.forEach((result, index) => {
const clientId = clientIds[index]
if (result.status === 'fulfilled') {
updateClientStore(clientId, { pendingInvoice: false, lastInvoiceId: result.value.id })
} else {
updateClientStore(clientId, { pendingInvoice: false, invoiceError: result.reason.message })
}
})
}

Promise.allSettled instead of Promise.all: one failed invoice creation does not reject the entire batch. The user sees 7 invoices created and 1 with an error — they retry the single failed one.

The pending state in the UI is a loading spinner per client row, not a global overlay. The user can continue scrolling while invoices create in the background.

12. CSV import validation and limits

The 2,000 row limit is not arbitrary. Above that threshold, the import runs long enough that users navigate away before it completes.

Validation runs before any write. Parse the entire CSV, validate every row, collect all errors, then either proceed or return an error report. Never partial-import.

function validateImportCSV(rows) {
const valid = []
const errors = []

rows.forEach((row, index) => {
const rowNumber = index + 2 // account for header row
const [name, email, monthlyPayment] = row

if (!name?.trim()) {
  errors.push({ row: rowNumber, field: 'name', message: 'Name is required' })
  return
}
if (email && !isValidEmail(email)) {
  errors.push({ row: rowNumber, field: 'email', message: 'Invalid email format' })
  return
}

const payment = parseFloat(monthlyPayment)
if (monthlyPayment && (isNaN(payment) || payment < 0)) {
  errors.push({ row: rowNumber, field: 'monthlyPayment', message: 'Payment must be a positive number' })
  return
}

valid.push({ name: name.trim(), email: email?.trim(), monthlyPayment: payment || 0 })

})

return { valid, errors }
}

Error report shows row numbers, field names, and human-readable messages. Not "Row 47 failed." Specifically: "Row 47, email: Invalid email format."

What the sprint taught me about product design

One pattern in retrospect across all twelve decisions: the right call was almost always "derive from existing data before adding a new data model." The health score derives from tasks, contacts, and projects. The activity feed derives from six existing collections. The recurring invoice metadata embeds in the notes field rather than a new table. Each one carries technical debt, and each one let us ship in three weeks instead of six. The refactors are on the roadmap with clear migration paths. The debt is intentional and bounded.

Three things I will carry into the next sprint:

Every feature should answer one specific question. The health score answers "which clients need attention?" The briefing tracker answers "who responded?" When I could not state the question a feature answered, the feature needed more scoping.

The "Why" column is cheaper than it looks and more valuable than it appears. Adding reason strings to scoring functions takes about 20 lines per algorithm. The payoff is a UI where every actionable item explains itself.

Two-state tracking hides the most actionable state. Sent/not-responded loses the middle. Healthy/unhealthy loses the dormant. The design question is always "what is the actionable difference between the two extremes?" — that difference is almost always a third state worth surfacing.

The full source for the features above lives inside Melororium — a team workspace for agencies at https://melororium.com. Agency plan is $59/month flat for up to 10 people. 14-day free demo, no credit card required.

If you have questions on the implementations above, I am in the comments.

I Built Full Team Management Into My Agency SaaS. Here's the Complete Feature Spec.

Кирилл Несмелов — Wed, 29 Jul 2026 06:45:21 +0000

I've been building Melororium ( https://melororium.com ) — a flat-fee workspace for agencies — for about eight months. The Team section turned out to be one of the densest features in the product. Five tabs, eight distinct data domains, two add-on modules, and one of the trickier design problems I've hit: anonymous feedback that's actually useful.

Here's the full breakdown of what I shipped.

Architecture: five tabs, one shared data layer
The Team page (route: /employees) has five tabs:

Team — the member table and sub-team management
Requests — pending join requests and sent invitations
Time Off — leave management
Onboarding — role-specific checklists (module-gated)
Sentiment — weekly mood tracking (module-gated)
All tabs read from a shared CRM store (Zustand) that loads employee data, project data, and time logs on mount. This means switching tabs doesn't trigger new fetches — the productivity metrics on a member profile come from client-side aggregation of the already-loaded store.

// Productivity metrics derived in the client — no extra API call
const myTimeLogs = storeTimeLogs.filter(log => log.user === memberFullName);
const totalTimeSeconds = myTimeLogs.reduce((s, log) =>
s + Math.round(log.durationHours * 3600), 0
);
const totalMoney = myTimeLogs.reduce((s, log) => s + (log.cost || 0), 0);
const completionRate = myTasks.length > 0
? Math.round((closedTasks.length / myTasks.length) * 100) : 0;
The header widgets: real-time team state
Four stat cards at the top answer "what's happening with the team right now":

// Active today: signed in within 24 hours
const active = members.filter(m =>
m.lastSeenRaw &&
(Date.now() - new Date(m.lastSeenRaw).getTime() < 24 * 3_600_000)
).length;

// On leave right now: approved leave covering today
function activeLeaveCount(reqs) {
const today = new Date();
today.setHours(0, 0, 0, 0);
const t = today.getTime();
return reqs.filter(r => {
if (r.status !== "approved") return false;
const s = parseDayMs(r.startDate), e = parseDayMs(r.endDate);
return s !== null && e !== null && t >= s && t <= e;
}).length;
}
The "on leave" count was deceptively tricky. Date parsing from stored strings needs to handle both ISO format (2026-07-20) and localized strings (Jul 20, 2026), and needs to treat the end date as inclusive. I ended up with a parseDayMs function that detects ISO format and parses it as local date (avoiding UTC offset drift) before falling back to new Date(str).

Sub-teams: tabs, leads, icons, drag-to-reorder
Sub-teams are stored in a teams table with members as a relation. The UI renders them as tabs above the member table. Clicking a tab filters the list to that team's members.

Key behaviors:

Team lead is set per team and gets hoisted to the top of the filtered list via the sort function
Members move between teams via moveMember(userId, teamId) — or moveMember(userId, null) to remove from all teams
Teams reorder via drag-and-drop: the dragged team's tab gets a hover target on other tabs, and reorderTeams(newOrder) persists the result
16 icon options render from a TEAM_ICONS array with Lucide components

Sorting cycles through neutral > asc > desc > neutral:

const toggleSort = (key: string) => {
if (sortKey !== key) { setSortKey(key); setSortDir("asc"); }
else if (sortDir === "asc") setSortDir("desc");
else setSortKey(null);
};
The localTime sort key sorts by timezone string — alphabetical by TZ identifier, which isn't perfect but keeps UTC-offset-adjacent timezones grouped.

Bulk select state lives in a Set of IDs. Three bulk actions: export selected members as CSV, open mailto with all their emails, move to team. The CSV export runs client-side from the in-memory member data.

Inline rate editing uses a controlled that appears on click with a ref-driven focus:

The problem: if sentiment scores are fully anonymous, I can show trend data but the admin can't act on specific problems. If they're attributable, members self-censor and the data is useless.

My solution: scores and comments are stored with a userId but the admin UI never exposes which user submitted which comment. The AI report generator also operates on aggregated data only. The only thing the admin sees per-user is whether they responded (count: "7 of 8 responded"), not what they said.

The survey rotation system lets you sequence templates across weeks so members don't see the same questions back-to-back:

// scheduled auto-send: runs when the sentiment tab loads, once per session
checkScheduleAndSend().then(res => {
if (res.sent) {
toast.success("Survey auto-sent per schedule");
setSentimentLoaded(false); // reload dashboard
}
});
The schedule check runs server-side and compares the configured day/time/timezone against the last sent timestamp. If the current time is past the scheduled window and no survey went out this week, it sends automatically.

The invite flow: everything upfront
The invite modal lets you:

Add multiple emails at once (tab/comma/semicolon separates them)
Set role (Admin or Member)
Assign to a team
Assign to projects
Attach an onboarding template
Add a welcome note
The onboarding template assignment happens in the same server action as the invite creation, so the new member's checklist is ready before they click the link. The alternative — assigning onboarding after they join — creates a window where someone's in the workspace but nobody has thought through what they're supposed to do first.

What I'd do differently
The per-member productivity tab does client-side aggregation from the full time log store. This works fine at small scale (the store caps out around 500 log entries before paginating) but it's not the right architecture if you're expecting hundreds of members or thousands of time logs. A dedicated GET /api/employees/:id/metrics?period=all endpoint would serve the aggregated numbers directly and make the productivity tab faster on load.

The sentiment scheduling also deserves its own service. Right now the auto-send check runs in the browser when someone navigates to the sentiment tab. If nobody opens the page on Friday, the survey doesn't go out. A proper cron job or a serverless scheduled function is the right fix — it's on the roadmap.

Shipping the feature with the browser-triggered approach let me validate the scheduling concept without infrastructure overhead. Now that the concept is validated, the infrastructure upgrade is worth doing.

https://melororium.com

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?