I started LedgerLens with a simple observation: important financial information is often buried inside documents that are technically accessible but practically difficult to understand.
Annual reports are a good example.
They can contain hundreds of pages, tables, notes, management discussions, financial statements, and repeated information. A human can search them, but understanding the relationships between sections takes time.
I wanted to build a financial document intelligence platform that could help turn those documents into useful answers.
The interesting part was not generating a summary.
The interesting part was everything that had to happen before a summary could be trusted.
A document is not just text
My first instinct was to think of a PDF as a text file with formatting.
That assumption breaks quickly.
A document can contain:
- paragraphs
- tables
- headings
- page structure
- footnotes
- repeated headers
- financial numbers
- scanned content
- charts
If extraction destroys that structure, the AI receives a distorted version of the source.
That means document intelligence begins before the language model.
The pipeline matters more than the prompt
A useful architecture looks roughly like:
Upload → Validation → Extraction → Cleaning → Chunking → Retrieval/Context → AI → Structured Output → User
Each stage can fail independently.
If the upload is invalid, the pipeline should stop cleanly.
If extraction is incomplete, the system should not pretend the document was perfectly understood.
If the context is wrong, a beautiful AI response can still be wrong.
This changed my thinking about AI projects.
The prompt is only one part of the pipeline.
Why summaries are dangerous
A summary feels authoritative because it is written fluently.
That is exactly what makes it dangerous.
A model can produce a confident sentence from incomplete or incorrectly retrieved information.
For financial documents, that is not a cosmetic problem.
It means the product needs to make source grounding and context quality first-class concerns.
The right question is not:
“Can the model summarize this document?”
It is:
“Can I explain where this answer came from and what information was available to the model?”
That question is much harder.
Supabase made the product feel real
Using Next.js with Supabase and PostgreSQL gave LedgerLens a real application backbone.
Documents, users, processing state, results, and metadata need durable storage.
This also forced me to think about asynchronous work.
A large document should not make the browser sit there waiting for every stage to complete.
The product needs states such as:
uploaded → processing → extracting → analyzing → completed → failed
Again, I found myself designing a state machine.
That pattern appears everywhere once you start looking for it.
What went wrong
LedgerLens is one of the projects that reminded me that an interesting idea is not the same thing as a finished product.
The concept was exciting, but the deeper I went, the more engineering remained: extraction quality, processing reliability, AI cost, long documents, error recovery, UI feedback, and evaluation.
It was tempting to add more features.
The better move was to improve the core pipeline.
That taught me a useful rule:
When the core result is not trustworthy, adding features is usually procrastination wearing a developer costume.
The evaluation problem
Traditional web applications can often be tested with assertions like “this button creates a record.”
AI document systems need another layer: quality evaluation.
If the user asks a question, what counts as a correct answer?
If the model produces two valid phrasings, are both acceptable?
How do we detect hallucinations?
How do we compare a new prompt or model against the old one?
I did not have perfect answers to these questions.
But learning that they existed was valuable.
The lesson
LedgerLens taught me that AI product engineering is mostly about controlling uncertainty.
You control uncertainty by validating inputs.
You control it by preserving structure.
You control it by retrieving relevant context.
You control it by tracking processing state.
You control it by evaluating outputs.
The model can be impressive, but the surrounding system determines whether that intelligence is useful.
That is the part of AI engineering I want to keep exploring.