Reportify turns a pile of source files into a structured report-writing workflow

The report-writing bottleneck is often upstream

A polished report rarely begins with writing. It begins with finding relevant passages across PDFs, notes, scans, and templates, then deciding where each piece belongs. That work can be slow even before an author starts shaping an argument or revising prose.

Reportify is an attempt to put those stages into one application. Its documented workflow combines document upload and processing, semantic search, AI-assisted drafting, and final export. The intended result is not simply generated text: it is a report organized into sections, grounded in uploaded material, and available in PDF or DOCX formats.

That makes the project relevant to builders exploring retrieval-assisted writing tools, especially where users need to work from their own reference files rather than prompt an empty text box.

A workflow built around report sections

Reportify starts with a user creating a report with a title and description. A PDF template can optionally be uploaded, and the README says the application can extract the template's section structure. That gives the writing process a defined destination before content generation begins.

Users can then upload notes in PDF, text, or image formats. The documented processing path extracts text from PDFs, performs OCR, or optical character recognition, for scanned documents and images, and generates embeddings for the resulting material. An embedding is a numerical representation of text that lets a system compare passages by semantic similarity, meaning similarity in context, rather than only exact word matches.

The search interface is therefore meant to answer a report-oriented question such as, “What material in my notes relates to this section?” The README describes results as ranked by similarity and searchable across uploaded documents. That retrieval step is important because it gives the generation stage a route to context drawn from the user's files.

From a selected report section, the documented interface offers content generation, improvement, and expansion modes using OpenAI GPT-4. Reportify also lists automatic citation tracking among its generation features. The README does not explain how citations are formatted, validated, or connected to source passages, so those details remain an area a prospective user or contributor would need to inspect in the code.

Once the author has reviewed and edited the section content, the report can be exported as a professionally formatted PDF or as an editable DOCX document.

A separated frontend, API, and background-processing design

The repository describes a React 18 and TypeScript frontend communicating over HTTP/REST with a FastAPI backend. The backend is organized around authentication, report, upload, content-generation, search, and export services. This kind of separation gives the user interface a clear API boundary, while keeping the document and AI operations on the server side.

Longer-running work is delegated to a Celery worker. The documented worker handles PDF processing, OCR, and embedding generation. That is a practical choice for file-heavy workflows: parsing a large document or preparing vectors for search should not need to occupy the same request that keeps the web application responsive.

The supporting services are also explicit. PostgreSQL is the primary database. Redis is used as a cache and message broker, which supports the Celery task queue. MinIO provides S3-compatible object storage for files. Qdrant is the vector database that stores or searches the embeddings used for semantic retrieval.

Docker Compose is documented as the way to start PostgreSQL, Redis, MinIO, and Qdrant locally. The application itself is then started as separate FastAPI, Celery, and frontend development processes. This is a more involved setup than a single-process demo, but it mirrors the distinct responsibilities in the architecture.

The stack maps closely to the product promises

Reportify's technical choices correspond directly to the capabilities it advertises:

• FastAPI provides the Python API layer that serves application features.
• React 18 and TypeScript power the browser interface, with Tailwind CSS and shadcn/ui listed for styling and UI components.
• PyMuPDF is identified for PDF text extraction, while Tesseract is used for OCR when text is embedded in scans or images.
• Sentence Transformers supplies the embedding models, and Qdrant enables similarity search over those representations.
• OpenAI's GPT-4 API is the documented engine for content generation.
• ReportLab and python-docx produce the two export formats.
• PostgreSQL, Redis, MinIO, and Celery support persistence, queued work, storage, and asynchronous processing.

The project also documents JWT-based authentication with access and refresh tokens, protected API endpoints, and user-specific data isolation. Those are useful baseline concerns for an application that accepts private source documents, although the README alone is not enough to assess the security implementation in depth.

Two lessons for builders of retrieval-assisted writing tools

First, report generation is best treated as a pipeline, not a single model call. Reportify makes that visible: ingest documents, extract text, create embeddings, retrieve relevant material, draft within a section, let the user edit, then export. Each stage has its own failure modes and operational needs, which is why moving extraction and embedding work into Celery tasks is a meaningful architectural decision.

Second, semantic search improves discovery but does not eliminate review. The project describes similarity-ranked results and context-aware GPT-4 generation, then explicitly places a review and manual-edit step after generation. That is a sensible workflow for reports, where a passage that is semantically related may still be incomplete, outdated, or inappropriate for a specific claim. The documentation's citation-tracking claim is promising, but builders should verify source attribution behavior before relying on generated output in high-stakes settings.

Reportify was built for the Dynamous Kiro Hackathon, according to its README, and is available under the MIT License. Builders interested in combining document ingestion, vector search, background processing, and report export can inspect the project at github.com/MuLIAICHI/Reportify.