I built PigeonEye in 7 hours

Government documents are often written for institutions, not people.

A letter from the IRS, an environmental agency, or a local authority can contain one date or one sentence that matters more than the rest of the page. Miss it, and the cost can be serious: lost money, missed deadlines, or a delayed application.

That was the idea behind PigeonEye.

PigeonEye is a local-first macOS app that helps people understand confusing government documents. You can import a PDF or photograph a document and get:

• A plain-language explanation
• Important obligations and deadlines
• A checklist of next steps
• Exact quotes from the source document
• Confidence indicators for extracted information

The goal was not to build another chatbot that confidently summarizes everything. The goal was to build a document tool that knows when it is uncertain.

Starting with the trust problem#

The first decision was architectural: documents should stay on the user's machine by default.

A government document can contain addresses, financial details, case numbers, and other private information. Sending the entire file to a cloud API should not be the default experience.

PigeonEye therefore starts with local processing. Cloud processing is available only when the user explicitly allows it. Before anything leaves the machine, the app shows the exact page region that would be sent.

If the user declines, the app still produces the best result it can locally.

That constraint shaped the rest of the product.

I chose a narrow first version#

I built PigeonEye with Swift and Apple's native frameworks, including PDFKit and Vision.

The first working slice had a simple job:

1. Open a document.
2. Read its pages.
3. Extract text and useful data.
4. Show the result clearly.
5. Make uncertainty visible.

I did not start with a large feature list. I started with the path a real user would take: opening a document and trying to understand what it requires.

That kept the first few hours focused on the core loop instead of settings screens, accounts, or infrastructure.

Forms and documents are different problems#

One of the most important discoveries was that not every document should be processed in the same way.

A fillable PDF already contains structured fields. If a form has 105 fields, PigeonEye can read those fields directly from the file. There is no reason to run an AI model over the page and ask it to guess what needs to be filled in.

That became "form mode."

Other files, such as scanned letters and long labels, need OCR and interpretation. Those use "document mode," where PigeonEye extracts findings, dates, amounts, and obligations from the page.

The app first asks a basic question:

Does this file contain fillable form fields?

If it does, PigeonEye reads the fields directly. If it does not, it uses the document-processing pipeline.

This split made the system safer. Deterministic data comes from deterministic tools. The reasoning layer does not need to guess facts that the PDF already knows.

Every finding needs evidence#

A summary without evidence is difficult to trust.

For every extracted finding, PigeonEye keeps the original quote, the page number, and the confidence information associated with it. If the app says a deadline appears to be June 30, the user should be able to see the text that produced that result.

This also changes how errors feel.

If OCR reads a date incorrectly, PigeonEye should not display the result as a fact. It should show the uncertainty and explain what could not be read. A confident wrong date on an official document is worse than no date at all.

That principle became one of the project's rules:

When the app does not know, it should say that it does not know.

The parts that took longer than expected#

The first version was not difficult because of one huge technical problem. It was difficult because small details mattered.

I had to deal with:

• OCR quality on real scans
• Long documents
• Pages that could not be read
• Completion-order races
• Clear model and privacy settings
• UI controls that actually felt clickable
• Exporting findings
• Testing the boundaries between layers

I also benchmarked OCR options instead of assuming the first tool would be good enough. Some test documents exposed problems that were invisible on clean PDFs, especially tables and photocopies.

The tests were not an afterthought. When a review found a problem, I added the missing test alongside the fix. That made it easier to keep moving without quietly breaking the document pipeline.

What the seven hours taught me#

The biggest lesson was that speed comes from reducing decisions.

I did not need a backend. I did not need authentication. I did not need a database. I did not need to download a model before the app could run.

I needed a small product loop and a clear trust boundary.

The seven-hour build window was enough to turn the idea into a working local-first application because the scope was narrow:

• Read the document locally.
• Extract facts.
• Explain them.
• Show the evidence.
• Ask for consent before crossing the privacy boundary.

The project continued to grow after that first build, but the foundation came from keeping the first version small.

Why PigeonEye exists#

Most software treats documents as files to store.

PigeonEye treats them as instructions that need to be understood.

The app is still early, and it is not a substitute for legal or professional advice. But it can help answer the first question people often have when an official document arrives:

What is this asking me to do?

PigeonEye is available on GitHub:

https://github.com/adisagar2003/PigeonEye

Built with Swift, PDFKit, Vision, local processing, and a lot of care around what the app should refuse to pretend it knows.