DeckFit AI — Slides adapt to screens. Why not rooms?
Inspiration
Independent trainers often reuse the same PowerPoint presentation across different classrooms and training venues. A slide that looks clear on a laptop may have text that is far too small for someone sitting at the back of the room.
The problem isn't always the presentation itself. Sometimes it's the room where that presentation will be delivered.
DeckFit AI brings the room into presentation preflight.
A trainer enters the projected image height and farthest-viewer distance, reviews suggested improvements to supported text, and approves an exact repair plan before a copy of the presentation is modified and independently checked.
The goal isn't another presentation generator. It's a repeatable way to prepare an existing deck for a specific room.
What it does
DeckFit AI follows a six-stage workflow:
1. Understand the presentation
Upload an editable PowerPoint or use the built-in demo. The system inspects the deck's structure, supported text, and rendered evidence while identifying content that cannot be safely analyzed or changed.
2. Analyze the room
Enter the active displayed-image height and the distance of the farthest viewer.
DeckFit evaluates eligible text against a versioned viewing-demand reference. It identifies text that falls below the modeled target for those room conditions.
3. Explore bounded improvements
Instead of freely redesigning slides, DeckFit generates narrowly defined font-size adjustments for supported text.
Each candidate is simulated and checked for problems such as wrapping, overlap, unsupported content, or violations of editing constraints.
4. Generate a repair plan
The system selects from server-generated, validated candidates.
An optional Gemini planner can recommend among these candidates. A deterministic planner provides the fallback, and the model cannot introduce arbitrary document operations.
For the accompanying qualification evidence, the validated workflow used deterministic planning. A successful live Gemini invocation is not claimed.
5. Require human approval
Before making any changes, DeckFit shows the proposed adjustments and their simulation results.
The user must approve the exact plan. Approval is bound to the source presentation, constraints, planning revision, and selected modifications.
6. Modify and independently verify
DeckFit creates a repaired copy, preserving the original.
It then reopens and renders the saved PowerPoint, checks the intended improvements, and verifies that protected content and document properties were preserved.
When the evidence is insufficient, the system requires review or refuses the operation rather than reporting an unsupported success.
The AI recommends. The user approves. The verifier decides.
How we built it
DeckFit AI uses Python and FastAPI for its backend, with HTML, CSS, and JavaScript for the frontend.
The document-processing pipeline combines:
- python-pptx to inspect and perform bounded edits on PowerPoint files.
- LibreOffice Impress to independently render presentations.
- PyMuPDF to examine rendered PDF evidence.
- Deterministic geometry and validation rules to evaluate supported text against room conditions.
- Optional Gemini integration for constrained candidate selection.
- SHA-256 integrity checks, approval binding, and independent verification to protect the original presentation and validate the saved result.
- Docker and Railway for deployment.
The architecture separates candidate generation, planning, user authorization, document mutation, and final verification. A decision from the AI planner is never sufficient by itself to authorize a document change.
Challenges we ran into
Trusting what the presentation actually contains
PowerPoint files can contain hidden content, overlapping objects, embedded media, compatibility structures, and formatting that different libraries interpret differently. We had to make document inspection conservative and refuse cases where the system could not establish reliable evidence.
Improving text without damaging the slide
Increasing a font size can create new problems, including wrapping, clipping, or overlap. We addressed this by simulating bounded changes and checking the saved artifact rather than assuming that a successful edit is automatically a safe edit.
Making approval and verification meaningful
A repair should not be considered complete merely because a file was saved. We implemented exact-plan approvals, source and output integrity checks, controlled session states, and final verification so that completed work corresponds to what the user actually authorized.
Accomplishments that we're proud of
The strongest achievement is an end-to-end workflow that takes an existing PowerPoint from room analysis through proposal, human approval, bounded modification, and independent saved-output verification.
The exact RC5.3 FINAL-01 r2 candidate passed its unchanged local release gate:
- 208 non-resource tests passed.
- 46 isolated LibreOffice/resource tests passed.
- 254/254 total tests passed.
Additional real API workflows verified supported repairs, downloaded-file integrity, completed-session immutability, deletion, and rejection of altered outputs.
Adversarial testing also identified a case where visible PowerPoint compatibility content could be omitted from verification. The qualified r2 candidate rejects the affected unsupported structure before session creation instead of reporting a misleading success.
These results apply to the tested local candidate. They are not a claim that every PowerPoint format or deployment environment has been verified.
Qualification evidence: https://github.com/saikiranpulagalla/deckfit-venue-preflight/blob/main/docs/FINAL01_INDEPENDENT_QUALIFICATION.md
Business model and financial sustainability
My initial customer hypothesis is independent trainers and small training providers who repeatedly reuse presentations across different classrooms and venues.
For occasional users, DeckFit could offer a free supported-deck evaluation followed by per-deck credits. For repeat training providers, monthly credits could provide a more predictable workflow and revenue model.
These are proposed business models, not launched pricing or proven customer demand.
The key financial measure is contribution per successfully processed supported deck:
Collected revenue minus rendering and simulation compute, optional AI inference, storage and network costs, attributable support, and payment processing.
A critical factor is that unsupported or unrepairable uploads still consume resources. Sustainable operation therefore depends on the percentage of uploads that DeckFit can safely process, the percentage that lead to useful improvements, and the cost of failed or review-only jobs.
The next business-validation step is to observe real trainers using their own decks, measure supported-upload and successful-repair rates, and test whether the workflow addresses a recurring problem they would pay to solve.
The longer-term opportunity is to make room-aware presentation checks part of the preparation process for training providers rather than a one-off technical demonstration.
What we learned
A model producing an answer is not the same as a system producing a trustworthy result.
For an AI-assisted document workflow, the important question isn't just whether the proposed change sounds helpful. It's whether that change was permitted, whether the user approved it, and whether the saved document actually satisfies the checks.
We also learned that a technically sophisticated product still needs a clearly defined customer and a realistic financial model. Reliability matters, but so do usability, supported-document coverage, processing cost, and whether the problem is frequent enough to justify payment.
What's next?
The next steps are to:
- Evaluate DeckFit with real training providers and consented presentations.
- Measure useful-repair rates, unsupported-content rates, processing costs, and end-to-end latency.
- Improve explanations when presentations need manual review.
- Test proposed pricing against actual customer behavior.
- Expand support for additional editable presentation elements only when safe analysis and verification can be established.
- Evolve the single-instance MVP into a more scalable architecture with durable storage and managed rendering workers.
The current system deliberately limits its automatic changes to supported, eligible text. It does not guarantee accessibility, subjective readability, sufficient contrast, or identical rendering across presentation applications.
Here, VERIFIED means that the saved artifact passed DeckFit's defined checks—not that every person in every room will find the presentation readable.
Development and AI assistance disclosure
DeckFit AI evolved from earlier room-aware presentation work and was refined into this startup-oriented workflow through additional product, engineering, and adversarial-testing iterations.
I used AI coding assistants, including ChatGPT and Codex, to assist with development, debugging, testing, and review. This development assistance is separate from the application's optional runtime Gemini planner.
Consequential authorization, document mutation, and verification decisions remain under deterministic application controls.
DeckFit AI — Design for the room, not just the screen.
Log in or sign up for Devpost to join the conversation.