Collectopedia: From Side Project to Production SaaS with AI

The front end is built with Next.js, TypeScript, Tailwind CSS, and Shadcn components, with Framer Motion for animations. The back end runs on Supabase with Drizzle ORM, server actions for the API layer, and Clerk for authentication. Payments go through Stripe, transactional emails through Resend. Pricing data comes from the eBay API and RapidAPI, with Inngest handling automated value updates across the platform. Analytics run through PostHog and Google Analytics. The whole thing is hosted on Vercel.

A year ago I wouldn't have been able to name half of these services, let alone wire them together into a working product. That's the point.

The biggest product challenge for any collection platform is the database: you need hundreds of thousands of items before the product is useful, and building that database manually isn't feasible for a solo founder. My solution was to use a combination of AI APIs and the eBay API to sidestep the problem entirely. Rather than maintaining a traditional product database, AI cleans and structures the data in real time, instantly making hundreds of thousands of items searchable and trackable.

The trade-off is less absolute accuracy compared to a curated database. My bet is that models and agents will close this gap quickly, and the advantage of launching with broad coverage from day one outweighs the accuracy cost. This is the kind of product decision that the current moment makes possible: using AI not just as a development tool but as core infrastructure.

The most complex feature in Collectopedia is the pricing engine. It orchestrates a multi-stage pipeline: parallel text and image search against the eBay API, AI-powered title refinement via GPT-4o-mini that strips promotional text to produce clean search queries, taxonomy-based filtering that uses category-specific fields to improve match accuracy, and robust statistical analysis with confidence scoring.

The real challenge wasn't any single piece but making them all compose reliably. Every stage needs fallback behaviour: if image search fails, fall back to text. If taxonomy filtering removes all results, fall back to unfiltered. If AI enrichment times out, proceed without it. Getting this cascade right while maintaining accuracy is where the product thinking mattered as much as the code.

I spent more time on the add-item flow than any other part of the product. As a collector myself, I knew this was the main pain point: if adding an item takes too long, people won't bother. The flow evolved from a basic form with manual image uploads, to eBay-powered search that auto-populates item details, to the current AI photo scan that lets you take a picture of an item and get it identified and valued instantly. Each iteration removed friction based on my own experience using the product daily.

Each collecting category (action figures, Lego sets, die-cast cars, vintage watches) has completely different fields. Rather than hardcoding schemas or running database migrations for every new category, the system uses a dynamic JSONB taxonomy: category definitions store field structures, items store their details in flexible JSON columns, and the UI generates forms dynamically from the schema.

This is probably the most important architectural decision in the product. It means I can add a new collecting category with zero code changes, just by defining the fields in an admin editor. For a platform that needs to cover everything from Funko Pops to vintage board games, this extensibility is the product. The fact that taxonomy fields also drive pricing accuracy (category-specific fields become required keywords in eBay result matching) means the data model is doing double duty.

Refreshing prices for potentially thousands of items across hundreds of users, within the eBay API's daily rate limits, required a proper scheduling system. The original version was a single cron job that tried to process everything at once. That didn't scale. The current system uses deterministic user hashing to distribute load evenly across the week, with per-item processing that prevents one slow lookup from timing out an entire batch. This was the kind of problem where the architecture went through several iterations, each driven by real-world constraints I only discovered by running the system with actual users.

Most collection tools are inventory lists. Discogs tracks your records. PriceCharting tracks your games. Collectopedia is deliberately positioned differently: it's a financial tool that happens to be for collectors. The portfolio view, ROI calculations, appreciating and depreciating asset tracking, and hold or sell signals all exist because I wanted the market intelligence that stock investors take for granted, applied to physical collections. This cross-category financial focus is the core differentiator.

The product uses a tiered feature gate: free users get up to 25 items with basic analytics, and encounter upgrade prompts at natural friction points like the item limit. A progress bar shows how close you are to your limit, creating urgency without being aggressive. Paid users get unlimited items, advanced analytics, and market predictions. The goal is for the free tier to be genuinely useful so people experience the value before being asked to pay.

With AI-generated pricing data, accuracy is everything. I built a comprehensive admin dashboard for monitoring prices and running evaluations, regularly auditing output with the latest models. Confidence scoring on every valuation gives users transparency about how reliable a given estimate is, rather than presenting every number as gospel.

Copy-pasting between ChatGPT and a code editor. Slow, error-prone, but genuinely transformative. This was enough to build a proof of concept that validated the idea. The eBay API integration that proved the concept would work was built entirely this way.

Moving to Cursor was a significant step up. Having the AI work directly in the codebase rather than through a chat window changed the workflow entirely. But it still required careful hand-holding. Without close attention, the models would regularly break things, and there was a clear ceiling on what you could achieve as a semi-technical user. This was the phase where I built the core application architecture: auth, payments, database, the fundamentals.

Agent mode in Cursor alongside Claude 3.6 was easily a 2x improvement in productivity. Suddenly the more complex features became achievable: Inngest processing for automated value updates, API data manipulation, the kind of back-end work that had previously hit the ceiling. This was the phase where Collectopedia went from a functional prototype to a real product.

My current workflow uses Claude Code and agentic tools for building features. The pace of development continues to accelerate with each model release. I also use V0 for design prototyping, Perplexity and Manus for research, and the general suite of AI tools that have become part of daily work.

AI coding tools are excellent at generating individual functions. Where they consistently struggled was with multi-system orchestration: the pricing pipeline's six-stage fallback chain, where each stage needs to know when to retry, degrade, or proceed, required domain judgment I had to reason through myself. Edge cases like "the taxonomy filter removed all but one result, so discard the filter and use the original set" aren't things a model naturally gets right.

The distributed scheduling system went through several architectural rewrites as I hit real-world constraints (API rate limits, timeout budgets, concurrency limits) that all interacted with each other. And cross-cutting concerns like region-aware pricing, where every price display across dozens of components needs to account for currency conversion, are hard to get right incrementally with AI tools that work best on isolated tasks.

These are the areas where 15 years of product thinking paid off. The AI could write the code, but deciding what the system should do when things go wrong, and how all the pieces should fit together, was the human contribution.

Roles are collapsing. A product designer with domain expertise can now build a full production SaaS: front end, back end, database, payments, authentication, automated processing, analytics. Not a toy. A real product with paying users. The leverage an individual has with the right tools and the right problem to solve is enormous.

Building the product was the easy part. Relatively speaking. The hard part is the same as it's always been: acquisition, retention, monetisation. There are still the same number of users and the same amount of money to chase, even as software has become dramatically cheaper to build. The wave of micro-niche software we're seeing, both B2B and B2C, is exciting, but the marketing and distribution challenges haven't gone away. If anything, the noise has increased.

Today Collectopedia is a website. Tomorrow it might be an agent, a Claude Skill, a chat interface, or something that doesn't exist yet. The form of software is changing fast. But the core problem, helping someone understand what their physical collection is worth and make better decisions about it, will remain regardless of how the software is delivered. Product thinking matters more than the medium.

AI can write code, but it can't tell you what to build or why. Every day I make decisions about what to prioritise, what to leave out, and how to balance polish with speed. The add-item flow went through three major iterations because I knew from experience that onboarding friction kills products. The financial positioning (portfolio tool, not inventory list) came from understanding that collectors who buy and sell need different tools than collectors who just catalogue. These are product judgment calls that no AI tool would make on its own. Fifteen years of design experience turned out to be the most valuable part of the whole process.