• 

  meetric

• 

  processing

• 

Meetric — Project Story

(formerly Minutely)

Inspiration

Every team has the same problem: meetings happen, things get discussed, decisions get made — and then nothing moves. Someone writes notes, another person writes different notes, and by the next day half the action items have evaporated into the ether.

I've watched this play out in startups, remote teams, and growing SMEs across Africa. The cost isn't just lost time — it's lost trust. Clients wait. Deadlines slip. People blame each other because no one really knows who committed to what.

The frustration is universal, but the tools to solve it have always been either too expensive, too complex, or built for enterprise teams with dedicated ops staff. I wanted to build something that works for a two-person startup just as well as a twenty-person agency — something that turns the messiest meeting transcript into a clean, actionable task board in seconds.

That's what became Meetric.

A note on the name

This project started life as Minutely. Partway through development, a naming-overlap check turned up significant existing products already using that name — so the project was rebranded to Meetric across the codebase, documentation, and every integration touchpoint (Google OAuth consent screen, Slack app name, Notion integration, email sender identity). The rename touched more of the stack than expected, but it was worth doing early rather than launching under a name with prior art.

---

What it does

Meetric is an AI-powered meeting intelligence agent built on Qwen Cloud. You upload or paste a meeting transcript, and Meetric runs it through a 6-agent parallel pipeline that:

• Summarises the meeting
• Extracts every action item — including implicit commitments, not just explicit ones
• Assigns owners, deadlines, and priorities based on context
• Surfaces key decisions made during the meeting
• Identifies participants and their roles
• Generates contextual follow-up suggestions based on the meeting's content

Everything lands in a 9-tab results dashboard, and a human-in-the-loop approval flow means nothing gets dispatched anywhere — Slack, Notion, a calendar invite, an email — without your sign-off first. An ActionModeSelector lets you choose exactly how each follow-up gets sent out, and an MCP tool dispatch layer handles the actual delivery once approved.

---

How we built it

Frontend + Backend (unified)

Meetric is a single Next.js 16 (App Router) + TypeScript application — the frontend and the API layer live in the same codebase, with all backend logic implemented as Next.js API routes (app/api/...). There is no separate Express server.

• Tailwind CSS + shadcn/ui for the component system
• Clerk for authentication
• Supabase (PostgreSQL) for meetings, action items, and integration data
• Integrations with Google Calendar, Slack, Notion, and Resend (email)

AI Agent Layer

• Qwen Cloud (dashscope-intl), accessed via a single config file (lib/ai-config.ts) that centralizes model selection:
  • Free tier: qwen-plus (primary, used across all 6 agents) + qwen-turbo (fast/legacy routes)
  • Paid tier: qwen-max + qwen-turbo, toggled by a single environment flag once paid credits are active
• A 10,000-character transcript cap keeps requests within reliable context limits
• Agents run in parallel rather than sequentially, which was a deliberate fix after an earlier version dispatched follow-ups one at a time and felt sluggish

Alibaba Cloud Deployment

Meetric's backend runs on Alibaba Cloud ECS (Singapore region), containerized with Docker and served through nginx with a Let's Encrypt SSL certificate. This was set up end-to-end as part of the hackathon submission:

• ECS instance (2 vCPU / 4GB, CentOS 7.9) provisioned under the Alibaba Cloud free trial credit
• Application containerized with Docker (Node 20 base image) — necessary because CentOS 7's glibc can't run Node 20+ natively
• nginx configured as a reverse proxy in front of the container
• HTTPS via Certbot, using a free wildcard DNS service (nip.io) to get a valid domain name pointing at the server's IP, since Google's OAuth consent screen (in production status) rejects both bare IP addresses and non-HTTPS redirect URIs
• Google Calendar OAuth reconfigured to use the new live HTTPS domain

---

Challenges we ran into

1. The rebrand mid-build Discovering the Minutely name collision partway through development meant touching every surface of the app — code, docs, OAuth consent screens, third-party integration names — to migrate to Meetric without leaving stale references behind.

2. CentOS 7's glibc wall The Alibaba Cloud ECS free-trial instance defaults to CentOS 7, whose glibc (2.17) is too old to run Node.js 18+ — Next.js 16 requires Node 20+. NodeSource's install script kept silently trying to install Node 20 regardless of which setup script was run, due to a stale yum repo cache. The real fix was sidestepping the OS package manager entirely: Docker, with a Node 20 base image, isolated the app from the host's ancient system libraries completely.

3. Google OAuth's redirect URI requirements Getting the Google Calendar integration working on the new server surfaced three separate rejections in sequence: bare IP addresses aren't accepted as redirect URIs, then (after switching to a nip.io pseudo-domain) HTTP-only URIs were rejected because the app is in "production" publishing status, which requires HTTPS. Solving this meant issuing a real Let's Encrypt certificate for the nip.io domain — which works because nip.io resolves as a genuine DNS name, unlike a raw IP.

4. pnpm workspace misconfiguration The repo's pnpm-workspace.yaml was missing its packages: field, causing pnpm install to fail immediately on a fresh clone with ERR_PNPM_INVALID_WORKSPACE_CONFIGURATION — a one-line fix, but one that would have blocked anyone else trying to spin up the project from scratch.

5. Implicit vs. explicit action items Most meeting action items are implied, not stated outright. "Let's revisit this next week" is an action item. Training the agents to catch these without over-extracting noise was a careful balancing act in prompt design across all 6 agents.

6. Sequential dispatch performance An earlier version of the follow-up dispatch system sent items one at a time, which felt slow with more than a couple of action items. Moving to a parallel 6-agent pipeline resolved this.

---

Accomplishments that we're proud of

• A genuinely production-shaped 6-agent parallel pipeline with a 9-tab results dashboard, not a single-prompt demo
• Human-in-the-loop approval before anything gets dispatched anywhere — nothing goes to Slack, Notion, a calendar, or an inbox without explicit sign-off
• A real, independent Alibaba Cloud ECS deployment — Docker, nginx, valid HTTPS — built and verified end-to-end, not just a code reference to Qwen Cloud
• Clean recovery from a mid-project rebrand without leaving the codebase in a half-migrated state
• MCP tool dispatch layer connecting to four real external services (Google Calendar, Slack, Notion, Resend)

---

What we learned

• Qwen Cloud's models are strong for structured extraction — qwen-plus reliably handles messy, informal transcripts once the system prompt is well-engineered, and the free-tier quota is generous enough to build and test an entire 6-agent pipeline against it.
• Deployment friction on older base OS images is real — a free-tier CentOS 7 instance looks like a shortcut until you hit a modern JavaScript runtime's minimum glibc requirement. Docker isn't just a nice-to-have for reproducibility; on legacy hosts it's often the only practical path forward.
• OAuth providers have gotten stricter about what counts as a valid redirect URI — bare IPs and plain HTTP are both non-starters for a production-status Google app, which shaped the entire domain/SSL strategy for this deployment.
• A rebrand touches more surfaces than you expect — code is the easy part; OAuth consent screens, third-party app names, and documentation all need to move together.

---

What's next for Meetric

• Voice note upload — direct audio input processed via Qwen's speech capabilities
• Team workspaces — shared meeting boards with assignee notifications
• Deeper CRM/project tool export (Linear, Trello, Asana, beyond the current Notion/Slack integrations)
• Meeting pattern analytics — tracking which action items get completed, which keep slipping, and who's consistently overcommitted
• Migrating the live deployment from the current nip.io/IP-based setup to a proper custom domain as the product moves toward a public launch

Built With

• next.js
• node.js
• pnpm
• qwen
• shadcn
• supabase
• tailwindcss
• typescript
• vercel