DEV Community: Iheme Uchenna Uchenna

Switch Icons v0.2.0: A React Icon Library Built for the Icons Developers Actually Need

Iheme Uchenna Uchenna — Thu, 20 Aug 2026 06:21:20 +0000

Modern web applications rarely need only arrows, menus, and generic interface icons.

A fintech dashboard needs payment and banking icons. A logistics platform needs waybills, packages, warehouses, and delivery trucks. An AI application needs model, prompt, and AI-related visual language. An African commerce platform may need icons that represent local payment methods such as Naira, USSD, POS, and bank transfers.

That is the idea behind Switch Icons.

Switch Icons is a modern, developer-focused React icon library designed around practical icons for real-world applications—not simply another collection of unrelated SVGs.

Why Switch Icons?

There are already plenty of excellent icon libraries available. But while building modern applications, there is often a gap between the generic icons most libraries provide and the domain-specific icons developers actually need.

Switch Icons is being built around that gap.

Instead of focusing exclusively on generic UI elements, the library combines familiar interface icons with categories such as:

Fintech and payment rails
Logistics
AI
Commerce
Technology
Security
Social
Business and CRM
Communication
Media

The goal is simple: make it easier for developers to find the right icon without having to create or hunt down an SVG every time they build a feature.

What's New in v0.2.0?

Switch Icons has now reached its first public npm release.

Version 0.2.0 includes 93 icons across 9 major categories, along with 14 solid variants for icons where a filled visual style makes more sense.

The current collection includes:

Navigation & UI

Essential icons for navigation, actions, and common interface patterns.

People & Communication

Icons for users, teams, messaging, communication, and related functionality.

Business & CRM

Icons designed for business applications and customer-management interfaces.

Fintech & Payment Rails

This is one of the areas that makes Switch Icons particularly different.

The library currently includes icons such as:

Naira
BankTransfer
USSD
POS
QR Code
Mobile Money
Escrow

These are useful for applications dealing with payments, financial products, commerce, and African fintech workflows.

Logistics

For logistics and delivery applications, Switch Icons includes:

Waybill
Delivery Truck
Package Box
Warehouse
AI

AI-focused interfaces are becoming increasingly common, so the library includes icons such as:

AI Spark
Prompt Input
Model Chip
Security

Security-related icons include:

Fingerprint
Shield Lock
OTP
Lock
Commerce
For storefronts and commerce applications:
Storefront
Barcode
Receipt
Technology

Technology and developer-focused applications can use icons such as:

API Connector
Webhook
Terminal

The collection also includes dedicated Media and Social icons covering common concepts such as images, video, music, hashtags, mentions, reposts, bookmarks, polls, and trending content.

Built for React and TypeScript

Switch Icons is built with React and TypeScript, with an API designed to remain simple and predictable.

Installation is straightforward:

npm install switch-icons

Or with pnpm:

pnpm add switch-icons

Or Yarn:

yarn add switch-icons

Then import only the icons you need:

import { ArrowRight, Naira, BankTransfer } from "switch-icons";

export function Example() {
  return (
    <div>
      <ArrowRight size={24} />
      <Naira size={24} />
      <BankTransfer size={24} />
    </div>
  );
}

No complicated API. No custom configuration required.

Just import an icon and use it.

Designed to Be Customizable

Icons inherit the current text color by default through currentColor.

That means they work naturally with CSS and utility frameworks such as Tailwind CSS.

<ArrowRight
  size={32}
  strokeWidth={1.5}
  className="text-blue-500"
/>

You can also specify a color directly:

<Naira
  size={32}
  color="#111827"
/>

Size, stroke width, and color can therefore be controlled without modifying the SVG itself.

Consistency Is the Point

One of the biggest problems with mixing icons from different sources is visual inconsistency.

You might have one icon with a heavy stroke, another with a thin stroke, different proportions, different viewBox dimensions, and completely different optical weight.

They technically work together—but they don't look like they belong to the same design system.

Switch Icons is designed to solve that problem.

Every icon follows a shared visual system:

24×24 viewBox
Consistent optical weight
Consistent stroke behavior
Controlled geometry
Predictable scaling
currentColor compatibility
Developer-friendly APIs

The icons are also built through shared icon factories, including createIcon and createSolidIcon, so common behavior remains consistent across the collection.

Solid Variants

Not every icon works best as an outline.

Switch Icons v0.2.0 introduces 14 solid variants for icons where a filled treatment provides better visual communication.

The current solid variants include:

Star
Heart
Bell
Home
User
Users
Mail
Lock
Shield Lock
Escrow
Play Circle
Pause Circle
Bookmark
AI Spark

The goal isn't to create a solid version of every icon simply because it is possible.

Solid variants are being added where they genuinely improve the visual result.

Tree-Shakeable

Switch Icons is also designed with modern frontend tooling in mind.

The package uses named exports and sideEffects: false, allowing bundlers to remove icons that aren't being used.

That means importing a small number of icons doesn't need to mean shipping the entire icon collection to the browser.

For modern applications where bundle size matters, this is an important part of the architecture.

More Than Generic Icons

The philosophy behind Switch Icons can be summarized in one sentence:

Build the icons developers actually need.

A developer building a dashboard shouldn't have to create a custom SVG every time they need a bank transfer icon.

A logistics startup shouldn't have to search through multiple libraries for a waybill.

A fintech application shouldn't have to settle for a generic dollar icon when the interface is specifically dealing with Naira transactions.

An AI application shouldn't have to combine unrelated icons to communicate AI concepts.

These are small problems individually, but they appear repeatedly across projects.

Switch Icons is an attempt to solve them at the library level.

What's Next?

Version 0.2.0 is only the beginning.

The project is currently under active development, and the collection and API may continue to evolve before the first stable release.

The roadmap includes:

More icon categories
Expanded UI collection
More social icons
More technology icons
More AI icons
More logistics icons
More commerce icons
More brand icons
Icon search
Icon metadata
Copy JSX
Copy imports
SVG downloads
Additional solid variants
Full documentation website
Interactive icon playground

The project already has a separate interactive documentation and icon explorer site planned around these features.

Try Switch Icons

If you're building a React application and want a lightweight icon library with a stronger focus on practical, domain-specific icons, you can install Switch Icons today.

pnpm add switch-icons

Then:

import { Naira, Waybill, ShieldLock } from "switch-icons";

The project is open source and released under the MIT License.

GitHub: ihemehowell/switchicons

npm: switch-icons

Switch Icons is still growing, and the goal is not to become the library with the most icons.

The goal is to become the library that has the right icons when developers need them.

Building Meetric: An AI Meeting Agent on Qwen Cloud

Iheme Uchenna Uchenna — Thu, 25 Jun 2026 14:25:32 +0000

My journey building an autonomous meeting-intelligence agent for the Qwen Cloud Global AI Hackathon (Track 4: Autopilot Agent)

The problem I wanted to solve

If you've ever run a small team, church group, or SME, you know the pattern: a meeting happens, someone half-takes notes, and three days later nobody remembers who was supposed to follow up with the supplier, or what the actual decision was on the budget line. Meeting notes get written, then they die in a Notes app or a WhatsApp thread.

I wanted to build something that didn't just transcribe a meeting, but actually understood it — pulled out the decisions, the action items, who owns what, and then closed the loop by drafting the follow-up emails itself. That's the idea behind Minutely.

When I saw Qwen Cloud's hackathon had a Track 4: Autopilot Agent category — built for agents that automate real business workflows end-to-end, with human-in-the-loop checkpoints — it was a clean fit for what I was already building.

The stack

Meetric runs on:

Next.js (App Router) + TypeScript for the frontend and API routes
Tailwind + shadcn/ui for the interface
Supabase (Postgres) for persistence
Clerk for authentication
Qwen Cloud (qwen-plus and qwen-turbo, with qwen-max reserved for a future paid tier) as the reasoning layer

The core of the system is a multi-agent orchestration pipeline — six distinct agent steps that take a raw meeting transcript and progressively turn it into structured output: summary, decisions, action items, owners, and drafted follow-ups. Rather than one giant prompt trying to do everything, each agent has a narrow job, which made the output far more reliable and easier to debug.

To keep all of that manageable, I centralized every model call into a single lib/ai-config.ts file — model selection, token limits, and prompt templates live in one place instead of being scattered across API routes. When Qwen Cloud's available models or pricing tiers shift, I only need to touch one file.

*The hard part: persistence and a stale closure bug
*
Two bugs ate most of my build time, and they're the kind of thing that don't show up in a demo video but matter enormously for production-readiness.

Row-Level Security vs. Clerk JWTs. Supabase's RLS expects Supabase-issued auth tokens, but I'm using Clerk for auth. That mismatch meant writes were silently failing under RLS policies that couldn't validate a Clerk-issued JWT. The fix was a full persistence rewrite using an admin Supabase client (service role) for server-side writes, while keeping RLS intact for anything touched directly from the client. It's not the prettiest solution, but it's the correct boundary: trust the server, not the browser.

A stale closure in AnalysisChat. Users could chat with Minutely about a specific meeting's analysis, but edits to that analysis weren't reflected in the chat's responses. The cause: the send() function was capturing a stale analysis prop from the render it was created in, not the latest one. Classic React closure trap. The fix was making sure send() always read from a ref or the latest prop on each call rather than capturing it once.

Neither of these are flashy, but they're the difference between a demo that works once on stage and an agent that's actually trustworthy across sessions — which is exactly what Track 4 judging criteria are looking for.

Designing for human-in-the-loop

Track 4 explicitly asks for agents that handle ambiguous input and include human checkpoints at critical decision points — not just full autopilot. A few of Minutely's design choices reflect that directly:

The follow-up email step is editable, not auto-sent. The agent drafts the recipient, subject, and body, but a human reviews and can change the recipient before anything goes out. Meeting agents that fire off emails with zero review are a liability, not a feature.
Upload handling is intentionally scoped to .txt and .md transcripts after I discovered FileReader.readAsText silently corrupts binary formats like .docx — better to be explicit about what's supported than to fail unpredictably on bad input.
I'm currently working through a pdfjs-dist worker initialization issue in the upload zone, since PDF transcripts are a natural next input type — a good example of the kind of "ambiguous input handling" this track rewards, even mid-build.

What's left

Before the July 9 submission deadline, my checklist is:

Finalize Alibaba Cloud deployment (ECS) as proof the backend runs in production, not just on localhost
Architecture diagram showing how Qwen Cloud, Supabase, and the Next.js frontend connect
A clean 3-minute demo video
Polishing the submission write-up

Why this track, why now

A lot of "AI agent" demos are impressive in a sandbox and fall apart the moment real, messy human input shows up — bad transcripts, ambiguous action items, edge cases in formatting. Building Minutely has mostly been an exercise in handling that messiness gracefully rather than chasing a flashier demo. That's the bet I'm making for Track 4: production-readiness over toy demos, exactly as the brief asks for.

If you're building on Qwen Cloud too, I'd love to hear what you're running into — the orchestration and persistence problems in particular feel like they come up for almost everyone building multi-agent systems on top of a Postgres backend.

Meetric is built in the open. Follow the repo here: https://github.com/howelldevs/Meetric