Forem: Arham Mirkar

I Killed Our 23-Zap Stack and Built One Database Instead — Here's Why Middleware Always Fails

Arham Mirkar — Sun, 05 Apr 2026 14:35:43 +0000

We Used to Run 23 Zaps

Slack → Asana (task from message), Asana → Notion (status sync),
Notion → HubSpot (client updates), HubSpot → Slack (deal alerts).

Every week: at least 2 silently broken. We'd find out 48+ hours
later when a client asked why nothing had moved.

The problem wasn't our Zaps. It was the architecture.

The 5 Technical Reasons Zapier Always Breaks

1. API Schema Drift
When Notion migrated to v2, thousands of Zaps broke overnight.
No warning. Silent failure until a trigger runs and errors out.

2. Rate Limiting
Slack, Asana, Notion each have API rate limits. Under heavy use,
Zapier hits them and silently drops automation runs. From your end:
nothing looks wrong. Tasks are just never created.

3. OAuth Token Expiry
Stored credentials expire. Zapier handles most renewals — but
aggressive token rotation on the tool side silently breaks auth
until a Zap runs and fails.

4. Webhook Timeouts
Zapier must acknowledge webhook receipt within 30s. Any network
blip = event lost. No retry. No trace. No task in Asana.

5. Missing Context (The Unfixable One)
Even when Zapier works perfectly, it copies fields between
isolated databases. A task created from a Slack message has
no reference to the conversation. The Asana AI has no idea
what the client actually said. This isn't fixable by better Zaps.

What We Built Instead

At Kobin, every module — inbox, tasks, CRM, vault, calendar —
shares one Supabase database with the same foreign keys.

// Every entity shares project_id + client_id
type Message = { id, project_id, client_id, content, ... }
type Task    = { id, project_id, client_id, title, ... }
type File    = { id, project_id, client_id, drive_id, ... }

When a client message arrives:

It already has project_id and client_id — no sync needed
Converting it to a task takes one click, context included
The task appears in the client portal immediately (same FK)
The AI sees messages + tasks + files simultaneously

Zero Zaps. Zero webhooks. Zero silent failures at 2am.

The Cost Comparison

Zapier stack (5 people):

Slack + Asana + Notion + Zapier = $231/month
+ HubSpot = $281–321/month
+ ~8hrs/month maintenance @ $75/hr = ~$900/month total

Kobin: $49/month. All of the above, natively connected.

Full post with the architecture breakdown and FAQ:
https://www.kobin.team/blog/zapier-slack-asana-notion-alternative

Happy to discuss the real-time WebSocket approach we use for
cross-module updates vs polling in the comments — it's an
interesting tradeoff for unified workspaces.

Building Kobin in public — agency OS replacing the Zapier stack.
Closed beta: kobin.team

I Compared 10 Productivity Tools for Agency Founders — Here's the Full Stack Analysis

Arham Mirkar — Fri, 03 Apr 2026 12:59:17 +0000

The problem I was trying to solve

After running a small agency for a year on the standard tool stack (Slack + Notion + HubSpot + Linear + Google Drive + Calendly), I was spending $310/month on tools that couldn't talk to each other.

The worst part wasn't the cost. It was what happened when I tried to use AI on top of a fragmented stack.

Slack AI saw messages.
Notion AI saw documents.
Linear AI saw issues.

When I asked any of them "what should I focus on today?" — none of them could give me a real answer. Because the real answer required data from all three tabs simultaneously.

So I built Kobin. And then I wrote this comparison.

How I approached the ranking

I evaluated 10 tools across five criteria:

Coverage — how many agency workflows does it handle natively?
Context — when the AI responds, how much of your actual operation does it see?
Cost — total monthly spend including all the tools you still need alongside it
Client experience — does it include a client portal, or do you need to build one separately?
AI scope — is the AI siloed to one module, or does it see the full workspace?

The Quick Comparison

Tool	Price (5 seats)	Client Portal	AI Scope
Kobin	$49/mo	✅ Built-in	Full workspace
Notion	$16/mo	❌	Notion only
Slack	$87/mo	❌ (guest only)	Messages only
Asana	$55–125/mo	❌	Asana only
ClickUp	$0–95/mo	❌	ClickUp only
HubSpot	$50–90/mo	❌	HubSpot only
Linear	$0–80/mo	❌	Issues only
Monday.com	$60–120/mo	Enterprise only	Monday only
Basecamp	$299/mo flat	~Basic	❌ No AI
Todoist	$6/mo	❌	Tasks only

The AI Context Problem

This is the thing nobody writes about in these comparisons.

Fragmented tools = fragmented AI.

The model is only as useful as the context it receives. When you ask Asana Intelligence "what should I focus on today?", it answers from Asana data only. It has no idea your biggest client hasn't replied in 4 days (that's in Slack). It doesn't know the $22,000 deal in your pipeline is stale (that's in HubSpot). It can't see that your calendar is empty this afternoon (that's in Google Calendar).

Kobin AI, before responding to anything, assembles a live briefing from:

All active tasks (with overdue and blocked flags)
Full CRM pipeline (deal values, win probabilities, stage)
Team workload (live, across all members)
Calendar events (upcoming and recent)
Vault files (titles, types, folder)
Last 20 inbox messages
Contact profiles from CRM

Here's a real exchange from our workspace:

User: "What's the single most important thing I should focus on today based on my tasks, pipeline, and calendar?"

Kobin AI: "Today's top priority: Unblock and close out the overdue task 'Testing Deliverable Uploads' (Ahmed). It's the only blocked and overdue item across all active projects. Clearing it frees the pipeline for the next sprint and removes the single critical bottleneck on the Reelix project."

That answer pulled from tasks, team workload, and project context — simultaneously. No other tool on this list can do this because no other tool has a unified data model.

The Total Cost Math

Running the popular "best-in-class" stack:

Slack Pro (5 seats):      $87/month
Notion Team (5 seats):    $40/month
Asana Premium (5 seats):  $55/month
HubSpot Starter:          $50/month
Buffer Essentials:        $18/month
Zapier (to connect all):  $29/month
─────────────────────────────────────
Total:                    $279–$350/month
Annual:                   $3,348–$4,200/year

Plus 51 minutes/person/week in context-switching overhead (Lokalise 2026 research).
At $75/hr blended rate for a 5-person team: $15,938/year in lost productivity.

Kobin replaces all of this at $49/month. The math is not close.

Full write-up

I published the complete ranked guide with individual tool reviews, pros/cons, and verdict for each:

👉 https://www.kobin.team/blog/best-productivity-tools-for-agencies

If you're building something and want to see the AI context angle specifically:

👉 https://www.kobin.team/blog/kobin-ai-vs-notion-clickup

Kobin is in closed beta. Join the waitlist at kobin.team — no credit card required.

How We Built an AI Layer That Understands an Entire Agency Workspace (Not Just One Module)

Arham Mirkar — Mon, 30 Mar 2026 20:31:07 +0000

We shipped the AI layer for Kobin today — an agency operating system that replaces Slack, Notion, HubSpot, Linear, and Buffer. This is the technical story of how we built it and the specific decisions that made it work.

The problem with every AI feature shipped in the last two years

Every productivity tool adds AI. The result is always the same: a model that knows about the host tool and nothing else. Slack AI knows about messages. Asana AI knows about tasks. HubSpot AI knows about contacts.

None of them can answer the question "which of my clients has gone quiet, and what's blocking their project?" — because the answer requires tasks, messages, and CRM data to exist in the same context.

We decided to solve this before writing AI code. We spent the first year building the data model: tasks, projects, clients, CRM pipeline, vault files, calendar events, and real-time inbox — all in Supabase, all linked by foreign keys. Only then did we build the AI layer.

Architecture: MCP-style tools, not context dumps

The naive approach is to dump your entire workspace into a system prompt and let the model figure it out. This fails for three reasons:

Token bloat: A workspace with 50 tasks, 10 projects, 30 CRM contacts, and 100 recent messages easily exceeds 8,000 tokens before you ask a single question.
Hallucination risk: The more unstructured data you put in a prompt, the more the model interpolates and invents.
Staleness: Workspace data changes constantly. A context dump taken at request time is already stale for any response that takes more than a few seconds.

Instead, we built a tool-calling architecture inspired by the Model Context Protocol (MCP). The model starts with a minimal workspace summary (~100 tokens) and calls specific read tools to fetch exactly what it needs.

// Mini context — ~100 tokens, always fresh
export async function buildMiniContext(founderId: string): Promise<string> {
  const [profileRes, tasksRes, projectsRes, ...] = await Promise.all([
    supabaseAdmin.from("profiles").select("full_name").eq("id", founderId).single(),
    supabaseAdmin.from("tasks").select("id, status, due_date").eq("user_id", founderId).eq("is_completed", false),
    // ...
  ])

  return [
    `Founder: ${profile?.full_name}`,
    `Tasks: ${tasks.length} active, ${overdueCount} overdue`,
    `Projects: ${activeProjects} active`,
    `Calendar: ${eventsCount} events this week`,
  ].join('\n')
}

Then the model calls tools like get_tasks, get_team_workload, or search_contacts to drill into exactly what it needs.

The 8 read tools

export const READ_TOOLS = [
  'get_workspace_overview',  // High-level stats across all modules
  'get_tasks',               // Tasks with filter presets (overdue, blocked, due today...)
  'get_projects',            // Projects with task completion counts
  'get_team_workload',       // Team members with active task counts + workload labels
  'get_crm_pipeline',        // Pipeline by stage with deal values and stale flags
  'get_calendar',            // Events with flexible range presets
  'get_vault_files',         // Vault documents filterable by project name
  'search_contacts',         // Full contact profile by name (fuzzy match)
]

Each tool returns compact, structured text rather than full JSON objects. This keeps tool results under 500 tokens while still providing all the detail the model needs.

// Example: get_tasks returns compact text, not full objects
lines.push(`- [${PRI[t.priority]}] ${t.title} | ${STAT[t.status]} | ${shortDate(t.due_date)}${overdue}${assignee}${project}`)
// → "- [U] Finish homepage redesign | ip | 3/28 [OD] | →Ahmed | →Reelix"

The 5 action tools

export const ACTION_TOOLS = [
  'create_task',    // Full task creation with name resolution
  'update_task',    // Partial updates by fuzzy title match
  'delete_task',    // Returns confirmation request (never auto-deletes)
  'create_project', // Project creation
  'update_project', // Partial updates by fuzzy name match
]

Name resolution

The hardest part of action tools is resolving human names to database IDs. The user says "assign to Sarah" — the model needs user_id: "uuid-here". We built a three-tier fuzzy matcher:

function fuzzyMatch(query: string, candidates: string[]): { match: string; index: number } | null {
  const q = query.toLowerCase().trim()

  // 1. Exact match
  const exactIdx = candidates.findIndex(c => c.toLowerCase() === q)
  if (exactIdx !== -1) return { match: candidates[exactIdx], index: exactIdx }

  // 2. Starts with
  const startsIdx = candidates.findIndex(c => c.toLowerCase().startsWith(q))
  if (startsIdx !== -1) return { match: candidates[startsIdx], index: startsIdx }

  // 3. Contains
  const containsIdx = candidates.findIndex(c => c.toLowerCase().includes(q))
  if (containsIdx !== -1) return { match: candidates[containsIdx], index: containsIdx }

  // 4. First name match
  const firstNameIdx = candidates.findIndex(c => c.split(' ')[0]?.toLowerCase() === q)
  if (firstNameIdx !== -1) return { match: candidates[firstNameIdx], index: firstNameIdx }

  return null
}

If the match fails, the action returns an error message with the available names — so the model can correct itself on the next attempt rather than hallucinating an ID.

Auto-fetching missing context

The model gets richer context when read tools are called first — but sometimes it tries to take an action without calling the relevant read tool first. Rather than fail, action tools auto-fetch what they need:

async function resolveTeamMember(name: string, team: TeamMemberContext[], founderId: string) {
  // If team context wasn't pre-loaded by a read tool, fetch it now
  if (team.length === 0) {
    const { data: members } = await supabaseAdmin
      .from('team_members')
      .select('user_id, position, profile:profiles!...(full_name)')
      .eq('founder_id', founderId)
      .eq('is_active', true)
    // ... populate team array
  }
  return fuzzyMatch(name, team.map(m => m.full_name))
}

The multi-step reasoning loop

Some requests require multiple tool calls in sequence. "Assign the most urgent overdue task to whoever has the lightest workload" requires:

Call get_tasks with filter: "overdue"
Call get_team_workload
Resolve name from workload results
Call update_task with the resolved assignee

We run a loop of up to 4 steps. Each iteration appends the tool call and its result to the conversation before calling the model again:

for (let step = 0; step < 4; step++) {
  const response = await groq.chat.completions.create({
    model: GROQ_MODEL,
    messages,
    tools: ALL_TOOLS,
    tool_choice: 'auto',
    max_tokens: 1024,
  })

  const toolCalls = response.choices[0]?.message?.tool_calls
  if (!toolCalls || toolCalls.length === 0) {
    // No more tool calls — stream the final response
    return streamFinalResponse(response, actionEvents)
  }

  // Execute tools, append results, continue loop
  for (const toolCall of toolCalls) {
    const result = isReadTool(toolCall.function.name)
      ? await executeReadTool(toolCall.function.name, args, founderId)
      : await executeAction(toolCall.function.name, args, ctx)

    messages.push(toolCallResult(toolCall.id, result))
  }
}

The mixed batch problem and how we solved it

Groq's Llama models sometimes try to call read tools and action tools in the same step — before the read tool results are available to inform the action. This causes the action to run with incomplete context.

We detect and defer:

const hasReadCalls = toolCalls.some(tc => READ_TOOL_NAMES.has(tc.function.name))
const hasActionCalls = toolCalls.some(tc => !READ_TOOL_NAMES.has(tc.function.name))
const isMixedBatch = hasReadCalls && hasActionCalls

if (isMixedBatch) {
  // Execute read tools, skip action tools with a "try again" message
  // The model re-calls action tools in the next step with actual data
}

Deduplication guard for create actions

One reliability issue with AI action tools: the model sometimes tries to call create_task twice for the same request. We use a Set to track which create actions have fired:

const createActionsExecuted = new Set<string>()

if (toolName === 'create_task' || toolName === 'create_project') {
  if (createActionsExecuted.has(toolName)) {
    return { success: false, message: `${toolName} already executed — task already exists.` }
  }
  createActionsExecuted.add(toolName)
}

Streaming SSE responses

The command bar streams responses using Server-Sent Events from a Next.js API route. Action events (task created, etc.) are emitted before the text stream so the UI can show success cards immediately:

function createStreamSSEResponse(stream: AsyncIterable<any>, actionEvents: Array<Record<string, any>>): Response {
  const encoder = new TextEncoder()
  const readable = new ReadableStream({
    async start(controller) {
      // Emit action events first (for immediate UI feedback)
      for (const event of actionEvents) {
        controller.enqueue(encoder.encode(
          `data: ${JSON.stringify({ type: 'action_executed', ...event })}\n\n`
        ))
      }
      // Then stream text response
      for await (const chunk of stream) {
        const delta = chunk.choices[0]?.delta?.content || ''
        if (delta) {
          controller.enqueue(encoder.encode(
            `data: ${JSON.stringify({ type: 'delta', content: delta })}\n\n`
          ))
        }
      }
      controller.close()
    },
  })
  return new Response(readable, { headers: SSE_HEADERS })
}

Why Groq + Llama 4 Scout

We evaluated several options:

OpenAI GPT-4o: Great quality, but 3-5 second response times for tool-heavy requests killed the UX.
Anthropic Claude Haiku: Fast, but tool-calling reliability was inconsistent on multi-step sequences.
Groq + Llama 4 Scout (17B): Sub-2-second responses even for 3-step tool chains. Reliable function calling. Free for users at our current scale.

Groq's inference speed is genuinely a product differentiator here. When the AI responds in under 2 seconds, it feels like a feature. When it takes 6 seconds, it feels like a bug.

The delete confirmation pattern

Destructive actions need a human in the loop. When the model calls delete_task, it never deletes immediately. Instead it returns a needs_confirmation: true flag with a confirmation_action object. The frontend renders a "Confirm Delete" button:

// action-executor.ts
return {
  success: true,
  needs_confirmation: true,
  confirmation_action: {
    tool: 'delete_task_confirmed',
    resolved_id: task.id,
    description: `Delete task "${task.title}"`,
  },
}

// Frontend: shows "Confirm Delete" button
// On click → DELETE /api/ai/command with { task_id }
// Server executes the actual deletion

What we learned

1. Start with the data model. The AI is only as good as the structure underneath it. We could not have built this if tasks, projects, clients, and vault files were in separate siloed tables without foreign key relationships.

2. Read tools beat context dumps. Structured tool calls with compact return values outperform pasting raw JSON into the system prompt. The model makes better decisions with less noise.

3. Auto-fetch gracefully. If the model skips a read tool and goes straight to an action, the action should auto-fetch what it needs rather than return an error. Failing gracefully is better than a strict execution order.

4. Name resolution is 30% of the work. Users say "assign to Sarah." The model needs a UUID. Building reliable fuzzy matching (with fallback error messages that list available options) took more work than the actual tool implementations.

What's next

Daily morning brief (push notification, 8am, 6 sections)
Pre-meeting brief (10 minutes before every calendar event)
Client silence detection (background scan every 6 hours)
Weekly client report auto-draft

The architecture supports all of these as new read tools + a background cron calling the AI with specific prompts.

If you're building something similar or have questions about the tool-calling architecture, I'm happy to discuss in the comments.

— Arham

Founder, Kobin — Agency Operating System

Full documentation: kobin.team/docs

Slack, Notion, Asana, HubSpot — Why I Replaced All Four With One Tool for My Agency

Arham Mirkar — Sun, 29 Mar 2026 14:26:37 +0000

If you run a dev agency or freelance team, your stack probably looks something like this:

Slack for team chat and client messages
Notion for docs, briefs, and project wikis
Asana or Linear for task tracking
HubSpot for CRM and leads

Each tool is good at its job. The problem is they were never built to talk to each other.

A client sends a message in Slack requesting a change. You need to:

Create a task in Asana
Update the relevant file in Notion
Schedule a review in Google Calendar
Log the interaction in HubSpot

That’s four manual steps across four tabs for one client message. Multiply that by every project you’re running.

The real cost

Research from UC Irvine shows it takes 23 minutes to regain full focus after switching context between apps. Harvard Business Review puts daily app toggles at 1,200+ per knowledge worker.

For a 5-person team, that’s roughly 44 hours per year burned on tool-switching alone — before you even count the $200+ monthly in subscriptions.

What I built instead

I built Kobin — an agency operating system where the inbox, tasks, files, CRM, calendar, and client portal all live in one place and share the same data layer.

When a client message comes in, converting it to a task is one click. The task links to the project. The project links to a Google Drive folder structure. The client sees their slice in a scoped portal. No Zapier. No manual bridges.

I wrote a full breakdown of the tool-by-tool comparison here:

Full article → kobin.team/blog/slack-notion-asana-hubspot-alternatives

Covers:

Where Slack fails for client-facing teams
Why Notion becomes a junk drawer at scale
Why Asana is overkill for a 5-person agency
What a lightweight HubSpot alternative looks like
The actual subscription + productivity math

Happy to discuss in the comments — curious what stacks others are running in 2026.

I built a real-time inbox with Supabase Realtime to replace Slack for agencies

Arham Mirkar — Sat, 28 Mar 2026 09:45:08 +0000

I spent a year building Kobin — an agency operating system that replaces Slack, Notion, HubSpot, Linear, and Buffer. The inbox was the hardest part to build. Here’s how it works technically.

The architecture

The inbox uses Supabase Realtime WebSocket channels. Each room (project room, group chat, DM) gets its own channel subscription. Switching rooms tears down the old channel and creates a new one — this keeps memory clean and avoids stale message states.

Messages load the last 20 first. Older messages load on scroll-up demand with no flash to top. An animated skeleton UI shows while rooms are loading.

The features that were harder than expected

Replies — storing the quoted message as a nested reference without blowing up query complexity. We denormalize the preview text at write time.

Unread badges — tracked via last_read_at timestamp per user per room. Simple in theory, surprisingly tricky when you have real-time updates coming in while the user is actively reading.

@ai mentions — when a message contains @AI, the server assembles a full context payload (project status, last 20 messages, open tasks, upcoming meetings, vault items) and sends it to the model. The response streams back as a message in the thread with a purple avatar.

File attachments — images open in a full-screen lightbox with download. Office docs and PDFs get a preview card. ZIPs show a file icon with size.

Why I built it instead of using Slack

Slack’s AI sees messages. Asana’s AI sees tasks. Notion’s AI sees documents. None of them see the full picture.

When everything — messages, tasks, files, meetings, CRM contacts — lives in the same schema, the AI actually has something to work with. That’s the whole point of building the inbox as part of a unified workspace rather than integrating with Slack.

Performance

Room list loads with 5 total queries regardless of how many rooms exist. This took several iterations to get right with Supabase RLS policies in play.

The full product

The inbox is one of 8 modules in Kobin. The others: Vault (Google Drive-backed), Tasks, CRM, Client Portal, Calendar, LinkedIn Studio, and an AI layer in development.

Full writeup on the problem it solves (with data): https://www.kobin.team/blog/the-283-problem

Waitlist if you run an agency: https://www.kobin.team

Happy to go deeper on any of the technical decisions in the comments.