← Back to Blog

Why I Stopped Building AI Tools and Started Building Data Extractors

Two months ago, I shut down SHRP.app, my AI image enhancement tool. That failure taught me something important: just because you can build with AI doesn't mean you should.

Two months ago, I shut down SHRP.app, my AI image enhancement tool. I'd spent weeks building it, integrating Replicate's models, adding features like black-and-white to color conversion, headshot generation, even those trendy LinkedIn photo transformers. The site got decent traffic. Sales? Zero.

That failure taught me something important: just because you can build with AI doesn't mean you should.

The SHRP.app Story (And Why It Failed)

I thought I'd found a gap in the market. People had blurry, distorted images that needed fixing. AI models could fix them. Simple, right?

I built SHRP.app with all the features I thought users wanted. Image enhancement, restoration, professional headshots, e-commerce photography tools. I used Replicate's API for the heavy lifting and wrapped it in a nice interface. The tech worked great.

But here's what I didn't realize until it was too late: Canva was already doing this. So was Adobe. And about fifty other tools with million-dollar marketing budgets. I was competing with companies that offered the same features plus a hundred others, often for free or bundled with tools people already used.

More importantly, I missed a crucial insight: image enhancement is something people need maybe once or twice a year. You find an old family photo that's blurry? You enhance it once and you're done. Need a professional headshot? You generate it and use the same one for the next two years. These weren't daily pain points – they were occasional inconveniences.

The traffic came – people found my site through SEO. They'd upload an image, see the result, think "cool," and then... leave. Why pay for my tool when Canva's free tier did the same thing? And why subscribe to something you'll use once every six months?

The Pivot That Changed Everything

I keep travelling a lot and once during my trip to Hoi An, Vietnam, I met a hotel manager who was manually doing entries from customer bills and receipts into Excel. Every evening from 6 PM to 8 PM, he'd sit there typing numbers from paper into spreadsheets. Two hours every single day just copying data.

I built him a simple data extractor that could read those receipts and dump everything into Excel. What took him two hours now took two minutes.

That's when it hit me. People don't need another AI image tool. They need simple, reliable ways to get data out of files. And unlike image enhancement which you might need once a year, businesses deal with this every single day.

So I built an OCR tool. Nothing fancy. Upload an image or PDF, get the text out. Clean, simple, works every time. I used Python scripts for the OCR processing, hosted everything on Railway (seriously, if you're not using Railway for Python apps, you're making life harder than it needs to be), and slapped a Next.js frontend on it.

No AI hype. No "revolutionary" claims. Just a tool that does one thing well.

SHRP.app current interface showing PDF to Excel extraction tools

SHRP.app today - pivoted to data extraction tools that people actually need

From OCR to Table Extraction

Once the basic OCR was working, I started noticing what people were actually uploading. Tons of business documents. Financial reports. PDFs with complex tables that they needed in Excel.

Anyone who's tried to copy a table from a PDF knows the pain. It comes out as garbage text. You spend an hour reformatting. And if you have multiple tables? Forget it.

So I built a table extractor. Upload a PDF with financial statements, P&L sheets, balance sheets, revenue projections – doesn't matter how complex. My tool finds the tables, understands the structure, and spits out a clean Excel file.

The technical part wasn't even that hard. Python has great libraries for this stuff. The hard part was making it work reliably with messy, real-world PDFs. But that's also what makes it valuable. Every edge case I fix makes the tool better than whatever hacky solution people were using before.

Why This Is Working (When SHRP.app Didn't)

The difference is night and day. With SHRP.app, I was trying to convince people they needed something they'd use once in a blue moon. With data extraction, they already know they need it – and they need it regularly. They're literally googling "how to extract tables from PDF" at 2 AM because they have a deadline. And next week, they'll have another PDF to extract.

When someone lands on my OCR tool, they don't need to understand AI or compare features. They have a PDF with text they need. They upload it. They get their text. Problem solved.

The best part? There's no race to the bottom on features. Adobe isn't going to suddenly make their table extraction free because it's not sexy enough to drive subscriptions. OpenAI isn't going to add it to ChatGPT because it's too specific. It's a boring problem that needs a boring solution, and that's exactly why it works as a business.

The Technical Stack (Keep It Simple)

Here's what I'm using:

No Kubernetes. No microservices. No AI APIs eating into margins. Just straightforward code that solves a specific problem.

The whole thing costs me about $50/month to run right now. Compare that to SHRP.app where I was burning through Replicate credits every time someone just wanted to test it out.

Early Traction (It's Not Much, But It's Honest Work)

I launched the tool two weeks ago. No ProductHunt launch, no Twitter threads, just posted in a few forums where people actually ask about PDF extraction.

The numbers aren't huge yet – maybe 50-100 users per day. But here's the difference from SHRP.app: these users actually use the tool. They upload their PDFs, extract their data, and come back when they need it again.

I've already had three people email asking if I can handle specific types of documents. That's three potential customers who actually need this enough to reach out. With SHRP.app, all I got were feature requests for things that already existed elsewhere.

What I'm Building Next

The beauty of data extraction is that every format is a new opportunity. Right now I'm working on:

Each one is a small, focused tool that solves one specific problem really well. No AI wrapper BS, no competing with tech giants, just useful tools for people who need to get data out of annoying formats.

Lessons Learned the Hard Way

If you're thinking about building a SaaS, here's what I wish I'd known six months ago:

Don't build AI wrappers. Just don't. The market is saturated, the margins suck, and you're one OpenAI update away from being irrelevant.

Boring problems pay. Nobody's going to tweet about my PDF table extractor. But they'll quietly pay $20/month to save three hours of manual work every week. That's the difference – it's not a once-a-year need, it's a recurring pain point.

Start with one specific thing. I tried to build five tools at once with SHRP.app. Now I'm building one tool at a time, making sure each actually works before moving on.

Talk to users who have the problem. Not people who think the idea is cool. People who are actively searching for a solution right now.

Railway + Python is underrated. Seriously, for data processing tools, this combo is perfect. Stop overengineering.

The Path Forward

I'm not trying to build the next unicorn. I'm trying to build tools that people actually need and will pay for. Data extraction isn't sexy, but it's a real problem that millions of people face every day.

While everyone else is racing to build the next ChatGPT wrapper, I'll be over here building boring tools that extract data from PDFs. It's not revolutionary. It won't get me on any "30 under 30" lists. But it might actually build a sustainable business.

And honestly? After burning time and money on SHRP.app, sustainable sounds pretty good.


If you're dealing with PDF extraction hell, check out my tool at SHRP.app. And if you're building SaaS, maybe skip the AI wrapper and look for boring problems instead. Trust me on this one.