DEV Community: Zero AI Developer

Handwritten faxes, tilted phone-camera receipts, messy PDFs — I built an AI pipeline that turns them all into clean structured data

Zero AI Developer — Tue, 08 Sep 2026 08:06:38 +0000

Handwritten fax orders. Receipts photographed at an angle on a phone. PDFs that all use different layouts. I built a small pipeline using Claude Code that reads all of these and turns them into one clean, structured spreadsheet — and I want to walk through exactly how it performed, including where it broke.

This is meant to demonstrate something a lot of back-office teams deal with every day: manually copying information from paper/photos/scans into a spreadsheet. How far can AI actually take that job?

The Pipeline

The idea is simple:

Watch a folder
      ↓
Detect a new file (PDF/image)
      ↓
Have Claude read it
      ↓
Extract company name, date, line items, quantities, and totals as JSON
      ↓
Append to one CSV

The key point: the same pipeline handles all of these regardless of how messy the input looks. I deliberately generated three very different test files:

A clean, well-formatted PDF (fictional purchase order, 3 line items)
A receipt that looks like it was photographed on a phone at an angle (tilt, shadow, JPEG artifacts)
A fax-style image with handwriting (broken layout, faded text, noise)

Results

All three files produced results that matched the source content exactly. Total processing time for all three: about 25 seconds (roughly 5–10 seconds per file).

Here's a sample of what came out (all company names are fictional test data):

Source file	Vendor	Date	Item	Qty	Unit price	Total
fax_handwritten.png	(fictional)	8/20	Cardboard box, size 60	40	@98	approx. ¥62,000
fax_handwritten.png	(fictional)	8/20	Cloth tape 50m	12	@340	approx. ¥62,000
order_clean.pdf	(fictional)	Aug 21, 2026	A4 copy paper, 500 sheets	20	¥520	¥38,720
receipt_photo.jpg	(fictional)	Aug 19, 2026	USB drive 64GB	5	1,280	¥15,334

What I find most interesting is the handwritten fax row. Notice "@98" and "approx. ¥62,000" — it preserved the ambiguity of the handwritten notation exactly as written, instead of silently converting it into a clean number. That's by design: the extraction prompt explicitly instructs the model not to guess when something is genuinely ambiguous. Quietly "fixing" ambiguous handwriting into a confident-looking number would actually make this system more dangerous in a real back-office setting, not less.

All three files also correctly identified the issuing vendor rather than the addressee as the vendor field — a sign this isn't naive OCR, it's actually reasoning about document structure.

Implementation Notes

Running through a Claude Code subscription instead of metered API calls

I originally called the Anthropic API directly, but switched to invoking the Claude Code CLI as a subprocess instead. Simple reason: I didn't want to rack up API costs while still validating the idea.

claude -p "<extraction prompt>" --allowed-tools Read --output-format json

Each file is processed as a separate, non-interactive CLI call. Using --output-format json gives you a structured envelope (with fields like is_error, result) that's much more robust to parse than raw stdout.

This does come with a real limitation: spinning up a new process per file doesn't scale to bulk processing. If you need to run hundreds of documents at once, going back to the metered API is the more sensible choice. For a small-scale demo like this, that tradeoff is fine.

A bug I found the hard way: "failure" wasn't actually being treated as failure

While testing, I found a real gap in the design. When you feed it a corrupted file, Claude correctly returns all fields as null, per the instructions. The problem: that was being treated as a "success" — an empty row got appended to the CSV, and the source file got moved into the "processed" folder and effectively disappeared.

That meant a failure could silently destroy the only copy of that file's data, with no error surfaced. I fixed this by treating "all key fields are null" as an error case, so failed files stay in the input queue for retry instead of vanishing.

What this is actually useful for

The point of this demo isn't "it can read purchase orders." It's that work assumed to require manual handling — because every input looks different — can actually be automated with AI, with reasonable reliability.

The same pattern applies to things like:

Reconciling invoices that use a different format for every vendor
Digitizing orders that only ever arrive by fax
Turning paper forms/surveys into structured data

If you're trying to figure out how to actually wire this kind of thing into a real business process — not just "chat with an AI," but an actual pipeline — I take on contract work designing and implementing systems like this. Feel free to reach out.

Closing thoughts

This was a small-scale demo, not a production system. But it validated something real: turning messy, inconsistent input into meaningful structured data — a boring but very common back-office problem — is something AI can genuinely do today, not just in theory.

Hope this is useful if you're exploring something similar.

I Tried to Build a Company Where AI Autonomously Finds, Wins, and Delivers Work. Here's Why It Failed.

Zero AI Developer — Tue, 08 Sep 2026 06:12:03 +0000

"Just tell Claude Code what to do, and let AI handle everything — finding leads, qualifying them, doing the work, and delivering it."

That was the idea I spent about half a year trying to build, on my own. Spoiler: the system worked. All the tests passed. And I still ended up with zero contracts, zero dollars earned, and a net loss.

In this post I'll walk through the actual architecture I built, what happened across two experiment cycles, and why "being able to build it" turned out to be a completely different problem from "being able to sell it." I'm writing this in the hope that it saves someone else from repeating the same mistake.

The Architecture

I designed a 4-stage pipeline:

Research Agent (find opportunities)
      ↓
Qualification Agent (score them)
      ↓
Delivery Agent (execute & deliver)
      ↓
Ledger (log everything, track KPIs)

1. Research Agent

This agent searches for potential work based on a configurable domain, keywords, geography, and criteria. One important design decision: none of these were hardcoded. I wanted to be able to pivot the target domain without touching the code, since I fully expected the first domain to fail.

2. Qualification Agent

Every candidate opportunity gets scored on:

Willingness to pay — is there real evidence someone would actually pay this amount?
Existing alternatives — could this be solved with a free tool or in-house resources already?
Reachability — can I actually contact this person/company?
Risk factors — reputational or terms-of-service risk

I iterated on this scoring logic quite a bit. For example, I changed the risk-score weight from -3 to -5 partway through, so that an extremely risky candidate could single-handedly sink an otherwise strong score below the pass line.

3. Delivery Agent

Once a job was won, this agent used the Claude Code CLI as the execution engine to produce the deliverable. I deliberately avoided metered API billing and ran everything within an existing Claude Code subscription — I didn't want to rack up AI costs before earning a single dollar.

4. Ledger

Every opportunity, from discovery to outcome, gets logged. To avoid the trap of "this feels like it's working," I tracked exactly six KPIs:

KPI	Description
Opportunities discovered	Number of candidate jobs found
Jobs completed	Number of jobs actually finished
Revenue generated	Cash actually received (not invoices, not verbal agreements)
AI cost	Cost of AI usage
Human time	Hours of human involvement
Revenue per human hour	Revenue ÷ human hours

Deliberately excluding vanity metrics like signups or pageviews was, in hindsight, the right call. But as you'll see below, having the right metrics doesn't help much when the actual number of jobs is zero.

I also wrote 300+ tests. Engineering-wise, this system was solid.

Cycle 1: Let AI Discover Opportunities on Its Own → 10 Found, 0 Won

In the first cycle, I let the Research Agent autonomously search for opportunities from scratch. Results:

Opportunities discovered: 10
Passed qualification: 0
Won: 0
Revenue: $0

Digging into why all 10 failed, every single one fell into at least one of these buckets:

Willingness to pay was pure speculation. The pricing was based on "this seems like a reasonable amount," with zero evidence anyone had actually transacted at that price.
A free alternative always existed. Every candidate task could already be solved with a free tool or existing in-house resources.
No evidence of reachability. There was no verification that I could actually contact these targets, let alone pitch them.

In short: the AI found opportunities that looked plausible on paper, but none of them connected to a real person who was actually struggling with the problem and willing to pay to solve it.

Course Correction: Human Finds Jobs, AI Just Verifies Them

After Cycle 1, I flipped the division of labor:

Human: manually finds real job postings on freelance/gig platforms — real budgets, real clients
AI: only does supporting research on those human-sourced listings (e.g., checking if the asking price is reasonable)

This was a big shift — from "AI does discovery" to "discovery is human, AI only reinforces."

The Anonymity Wall I Didn't Expect

While comparing platforms at this stage, I hit a wall I hadn't anticipated: wanting to stay anonymous (no real name, no face photo) massively narrowed the field of usable platforms.

Requirement	Outcome
Real name + photo mandatory	Excluded
Pseudonym/business name OK, but requires ID + selfie verification	Skipped — too much friction
Anonymous-friendly, lightweight verification	Kept as a candidate

I also concluded that having AI autonomously crawl sites to find jobs was in a legal/ToS gray zone. In fact, one platform I was evaluating later discontinued its "auto-propose" feature entirely, switching to a "human must review before proposing" model. I took that as external confirmation that fully autonomous bot applications carry real platform risk.

What I ended up building instead: save search filters, receive email notifications for new listings, and have the AI read and analyze those notifications — never touching the site directly. It avoids ToS risk while still using AI for the analysis part.

Cycle 2 Results, and Why It Still Didn't Work

Even with this more careful setup, Cycle 2 also ended in zero contracts and zero revenue.

Technically, everything worked exactly as designed — the qualification logic, a "Policy Gate" that automatically filtered out sites with no-solicitation notices or bot bans, and the logging pipeline all functioned correctly.

The problem was never engineering. Winning work is not a problem software can solve.

When a person or company decides to hire someone, the deciding factor isn't "is this AI technically impressive?" It's "can I trust this person/company to actually deliver?" Trust comes from track record, referrals, and prior relationships — not something an automated system can manufacture on your behalf.

Looking back, I was essentially betting on:

Build it → put it out there → someone finds it

And the "someone finds it" part was where the whole plan broke down. Interestingly, I'd hit the exact same wall before, with a content site that depended on search traffic, and with several mobile apps I'd shipped — same structural problem every time. I could build things. I had never actually designed a distribution channel.

What I'm Doing With This Now

The original vision — "AI autonomously wins its own business" — is on hold indefinitely.

But the engineering work itself — designing and implementing a full discover → qualify → execute → log pipeline — wasn't wasted. I'm now repositioning that same technical capability: instead of using it to run my own autonomous business, I'm offering it as implementation work for companies that want to build AI-driven automation into their own operations.

Concretely, this includes:

Designing and building AI agent systems with Claude Code
Building automation pipelines that combine LLMs and APIs (scoring logic, risk evaluation, logging/dashboards — end to end)
Solo end-to-end iOS app development, from concept through App Store release (shipped 9 so far)

If you're trying to figure out how to actually wire AI into a real workflow — beyond just prompting a chatbot — feel free to reach out.

Closing Thoughts

Building something that automatically earns you money is a genuinely exciting idea for any indie developer. And with today's AI tooling, building a technically functional system is very achievable solo.

What I underestimated was the gap between "a system that correctly does what it's designed to do" and "a system that convinces someone to actually pay for it." That gap isn't closed with more code — it's closed with trust, built the slow way.

Hope this is useful to anyone chasing a similar idea.