Ionio partnered with Width.ai to design, build, and scale Pumice—a product classification platform that transformed their AI consultancy into a SaaS business.
What started as a custom tool for agency clients became a standalone product processing two million runs per day, creating a new recurring revenue stream and adding seven-figure enterprise value to the business.
E-commerce businesses burn tens of thousands of dollars annually on product categorization. Every item in a catalog needs to be tagged, classified into the correct taxonomy, enriched with metadata, and kept consistent across sales channels. For most companies, this work falls on teams of virtual assistants or contractors who manually sort through product listings one by one.
The process is slow. A single person might categorize a few hundred products in a day if they're fast. Multiply that across catalogs with tens of thousands of SKUs, and you're looking at weeks of labor just to get products properly organized. Then factor in human error—typos in category names, inconsistent tagging, products placed in wrong taxonomies—and the rework begins.
Our Client kept seeing this problem across his consulting clients. E-commerce businesses would come to him asking for help with product categorization, and he'd watch them spend significant portions of their operating budgets on what was essentially data entry work. The same request, over and over. Manual categorization. Manual enrichment. Manual everything.
They decided to build a product that would let businesses self-serve this capability. A platform where you could upload a CSV of products—or connect directly to an e-commerce store—and have everything categorized automatically using AI. No virtual assistants. No manual sorting. Just results.
Width.ai brought the AI expertise. They needed a team to build the product around it—the interface, the batch processing infrastructure, the billing system, the database architecture, and the DevOps to keep it running at scale.
We began building this platform in April 2022. That was before the explosion of generative AI tooling, before established patterns for building AI-powered products, before anyone really knew how to architect systems around large language models at scale.
There was no playbook. No best practices document to follow. We were building one of the first platforms of its kind—something that automated work humans had always done manually. Every architectural decision was a bet on what would work, and we had to learn through iteration.
Within months, we went from processing hundreds of products per month to millions of products per day. When you're hitting an AI API two million times a day, everything becomes a challenge. Sequential processing won't work—you need parallelization. But parallelization introduces new failure modes.
This wasn't a side project. It was production infrastructure that businesses depended on for their operations. Every hour of downtime meant lost revenue and broken workflows. High availability became a core constraint—we built redundancy, monitoring, alerting, and incident response procedures from scratch.
In 2022, OpenAI's APIs were not what they are today. Servers went down. Latency spiked unpredictably. Rate limits kicked in at inconvenient times. Building reliable infrastructure on top of unreliable APIs required defensive engineering—retry logic, circuit breakers, and queuing systems that could absorb spikes.
The people using this platform weren't developers. They were e-commerce operators and catalog managers who understood products but not APIs. The interface needed to be intuitive enough that someone could upload a spreadsheet of ten thousand products and get results without reading documentation.
"The infrastructure that worked at hundreds of products couldn't survive at millions. We had to move from a single server to a proper master-worker architecture—before the industry had established how to do it."
We built everything around AI. Width.ai provided the classification APIs—the actual intelligence that could look at a product and determine its category. Our job was to make that intelligence accessible, reliable, and scalable.
We started with the fundamentals: user authentication, account management, subscription billing, usage tracking. These aren't glamorous features, but they're the foundation of any SaaS product. Users needed to sign up, manage their teams, understand their usage, and pay for what they consumed.
From there, we built the core workflows. Users could import products in multiple ways: upload a CSV file, connect to an existing e-commerce store, or use the API directly. Once products were in the system, they could run classification jobs individually or in bulk.
The platform used Google's taxonomy as a baseline—a standardized hierarchy of product categories that most e-commerce platforms understand. But we also built dynamic categorization, where users could define their own taxonomy trees. A business with unique categorization needs could upload their custom hierarchy and have products classified according to their own structure.
Beyond basic categorization, we implemented product similarity and image similarity features. The platform could compare thousands of products against each other to identify duplicates, variants, or related items. The same capability worked for images—upload a product photo and find visually similar items across the catalog.
Sometimes users didn't have clean CSVs of their product data. They needed to pull listings directly from e-commerce stores. We built scrapers that could connect to various platforms, crawl product listings, and import the data into the system for processing. A universal scraper extended this capability to gather data from any website.
The real engineering challenge was batch processing. When a user uploads a CSV with two million rows, you can't process them one at a time. You can't even process them in simple parallel batches. You need a robust task management system that can:
• Split the workload across multiple workers
• Track progress across all chunks
• Handle partial failures gracefully
• Restart failed chunks without losing completed work
• Report status back to the user in real-time
We built this on Django Celery, with careful attention to queue management, worker orchestration, and failure recovery. The system could handle millions of classification requests per day while keeping the user informed about progress and catching errors before they became problems.
The platform runs on a carefully selected stack optimized for our specific requirements—processing millions of AI classifications daily while maintaining the responsiveness users expect.
Powers the user interface, providing the responsive, dynamic experience users expect from modern web applications. Every interaction—from uploading files to monitoring batch jobs—happens without page reloads.
Handles the server-side logic. Django's maturity as a framework gave us solid foundations for API development, database management, and user authentication.
Manages the asynchronous workloads. When a user submits a batch job, Celery distributes the work across available workers, tracks completion, and handles retries. This is the backbone of processing millions of records reliably.
Docker and Docker Compose package the application for consistent deployment. Every component runs in its own container with defined dependencies and configurations.
Everything deploys to AWS, giving us the scalability and reliability of enterprise cloud infrastructure. As demand grew, we could add capacity without re-architecting the system.
Before Pumice, Width.ai traded hours for dollars. Clients paid for consulting engagements, and revenue scaled linearly with headcount. Pumice changed the economics entirely.
The platform enabled Width.ai to launch an automated enrichment tier—a premium upsell that clients could subscribe to monthly. What was once custom consulting work became a $197/month self-service product. Recurring revenue replaced project-based billing.
This was more than a new revenue stream—it was a strategic transformation. Width.ai went from an AI consultancy doing custom work for each client to a company with a scalable SaaS product. Pumice processed two million runs per day—volume that would have been impossible to service manually at any price point. The platform added seven-figure enterprise value to the business. Not by working more hours, but by productizing expertise into software that could serve unlimited clients simultaneously.
The platform didn't just reduce manual work—it eliminated it. Businesses that previously employed teams of virtual assistants for catalog management no longer needed them. The entire categorization workflow that once required human labor now ran automatically.
This created an operational moat for Width.ai's clients. The budget they had been spending on offshore VAs got reallocated directly to the SaaS subscription. For clients, the math was simple: pay less, get results faster, remove the management overhead of coordinating human workers.
What took human workers days or weeks now happened in hours. Products that would sit in a backlog waiting for manual categorization could be processed immediately at scale. Businesses could respond to market changes faster, onboard new inventory more quickly, and keep catalogs current without dedicated staff.
The platform allowed Width.ai to charge for compute-heavy tasks that were previously manual. Every classification run, every similarity match, every metadata generation—work that used to require human time could now be metered and monetized as software usage.
The development investment paid for itself many times over. The feature set we built became the foundation of a product generating six-figure enterprise value for Width.ai.
"Pumice added seven-figure enterprise value to the business—not by working more hours, but by productizing expertise into software that could serve unlimited clients simultaneously."
We structured the engagement in four overlapping phases, designed to deliver incremental value while managing the technical complexity of building production AI infrastructure from scratch.
We started with intensive discovery sessions to understand the product requirements. What did the categorization workflow actually look like? What were the edge cases? Where did human categorizers struggle?
From these conversations, we built wireframes and UI mockups. Every screen was designed before a line of code was written. The client could see exactly what the product would look like and provide feedback before we committed to implementation.
With real users on the platform, we learned quickly what worked and what didn't. The feedback loop was tight: users encountered issues, we fixed them, new features got requested, we built them.
This phase saw the major infrastructure evolution. Early architecture that worked fine for small volumes started showing strain as usage grew. We rebuilt the batch processing system, implemented proper queue management, and moved to the master-worker setup that could handle scale.
With core functionality stable, we expanded the feature set. Image similarity came online. The e-commerce scrapers got built and refined. Dynamic categorization gave users flexibility in how they organized their catalogs.
Each feature followed the same pattern: design first, validate with the client, build iteratively, deploy and monitor. By the end of the year, the platform had evolved far beyond that initial MVP.
We continued supporting the platform after the initial build, handling hosting, monitoring, and ongoing feature development. The relationship lasted over a year and a half, with continuous iteration based on user needs and market demands.
Building one of the first AI-powered product classification platforms taught us lessons that no documentation could provide. These insights now inform every production AI system we build.
When your core functionality depends on external APIs you don't control, you need defensive architecture. Assume the dependency will fail. Build retry logic, circuit breakers, and graceful degradation from day one.
A prototype that categorizes ten products is fundamentally different from a platform that categorizes ten million. The techniques that work at small scale collapse under real load. Production systems need production engineering.
Investing in wireframes and mockups before development saved significant rework. When everyone can see what's being built before it's built, misunderstandings get caught early. Changes to a Figma file take minutes; changes to implemented code take days.
The AI was a small part of the overall system. The vast majority of the work was everything around it: user interface, batch processing, error handling, billing, authentication, monitoring. The model is just the beginning.
Pumice transformed Width.ai from a consultancy trading hours for dollars into a company with a scalable SaaS product generating seven-figure enterprise value. The platform processes two million classifications daily—volume that would have been impossible to service manually at any price point.
What we built wasn't just software. It was the infrastructure that turned AI expertise into a productized offering. The batch processing, the user interface, the billing system, the failure recovery, the monitoring—these are the systems that separate a working demo from a production platform that businesses depend on.
You're facing a version of what this client faced—valuable data locked in fragmented systems, the need to compete with AI-native experiences, or the gap between your technical vision and the specialized talent required to execute it.
You need a strategic partner who understands both the technology and the business model—not a dev shop that builds what you specify.
You want a chatbot for your dashboard, AI for the press release, or features that OpenAI will commoditize in six months.
We'll tell you that directly.
30 minutes. No deck. We'll talk through your challenge, share some relevant work, and see if it makes sense to work together. Or honestly, just grab coffee and chat—no agenda needed.
Book an Intro Call →Prefer email? contact@ionio.ai
