Why we started writing about how we build things

September 12, 2025

So this email chain happened, and it perfectly captures why we're starting this blog.

A customer uploaded transactions with categories, but our system couldn't map a bunch of them to our standard category set. They were frustrated (rightfully so), and I was debugging at midnight trying to figure out why our mapping wasn't working.

Three days later, I sent them this:

"Great news! We've hit 100% categorization with your transactions, thanks to major AI system upgrades."

But here's the thing - that wasn't just a bug fix. That was a complete rethink of how we handle transaction categorization. And the story of how we got there is exactly why we're starting this blog.

Why we're doing this

Users ask really good questions. The kind that make you realize there's a gap between what you built and what they actually need.

This customer wrote:

"I just uploaded some transactions with category details. However around 37 out of 248 did not have a category after upload. In the original file, only around 7-8 transactions don't have a category. I tried multiple times - but the result was the same. Any idea why?"

My first instinct was to debug the AI mapping logic. The real problem was that our system initially tried to map categories in a single pass. Now it uses a multi-stage categorization pipeline.

They had already done the work - they'd categorized everything in their spreadsheet. But our system was not confidently able to map some of their categories to Plaid's standard taxonomy so those would simply be unmapped and appear blank on the UI.

What happened next

So we built a hybrid approach that uses AI for initial mapping, PostgreSQL trigram matching to find similar merchants from their history, and contextual analysis for edge cases. The result? They went from 15% uncategorized transactions to near-perfect categorization by leveraging their own spending patterns.

But I don't want to just leave that story in a commit message or buried in our support emails. These customer conversations lead to real breakthroughs, and I think other people building similar stuff might find them useful.

What you'll find here

I'm going to write about the problems we solve and the novel ways we solve them. The customer requests that make us rethink everything. The "obvious" solutions that don't work. The weird approaches that actually do.

I'll also share the conversations that spark these breakthroughs. Because the best product ideas come from users frustrated enough to send detailed emails.

We're building Cently in public, which means your problem might become our next blog post.

Thanks for reading, and thanks to all our users who ask the questions that make us better.