PDF to App · Your App Cloud
Build an app from your PDF document
Upload a report printed from another system, or a few PDFs of one kind. Choose whether each table row or each file becomes a record, check values against the page, and add the status a PDF can't change.
From a finished PDF to records people keep working on.
Choose what one record is, add what the page can't hold, then check the app against the PDF before anyone relies on it.
01
One PDF, or one record per PDF
Attach the file with the upload button above. Say which kind you have: one document holding many records, like a report whose table runs for thirty pages, or one of a set where each file is a record, like a certificate. For a set, start with three or four files that look different from each other.
02
Add what a printed page can't hold
Name the fields from the column headings or from the labels on each page. Then add what the PDF never had: a status people change, who owns each record, and the next date that matters, such as a due date or an expiry.
03
Hold records up against the pages
Open records from the first page, from either side of a page break and from the last page, each beside the PDF. Compare every field. Then sign in with a second test account and change a status the way a colleague would.
What each part of the PDF becomes.
Each row pairs something you can point to in the PDF with its place in the app and a check you can run. Numbers and wording in quotes are invented, as if from a property management office in San Diego.
| In the PDF | In your app | How to confirm it |
|---|---|---|
| A table that runs over many pages, one work order per row | A collection with one record per row, in a list you sort and filter | The report's last page often prints a count, such as 'Total open work orders: 212'. Compare it with the number of records, then look at the rows on either side of two page breaks. |
| A cell that wraps onto a second line, such as a long issue description | One field that holds the whole text | Find a row whose description takes two lines. The second line should belong to that record, not show up as a record of its own with empty columns. |
| Page subtotals, and lines such as 'Carried forward: $18,420.00' | Nothing. Ask for totals worked out from the records instead | Search the records for 'Subtotal' and 'Carried forward'. A total that became a record gets counted again in every sum the app shows. |
| The header on every page: 'Status: Open · 01/01/2026 to 06/30/2026 · Printed 07/02/2026 9:14 AM' | A note on the collection saying what the report covered and when it was run | A header like this means the PDF is a filtered subset. Closed work orders are not in it, and the print date is not a date on any record. Decide whether you need the missing ones before trusting a total. |
| A folder of certificates, one PDF per inspection | One record per file, with the PDF attached to it in File storage | Count the files and the records. Open each record's attachment and make sure it is the certificate for that equipment, not the one next to it in the folder. |
| Labels and values on a certificate, such as 'Unit ID: ELV-2' and 'Next inspection due: 03/2027' | Fields with a type: text, a date, a pass-or-fail choice | Certificates from different inspectors put the same fact under different labels, like 'Expires' and 'Valid through'. Tell the prompt which labels mean the same field, then compare five records with their PDFs. |
| Amounts in accounting style: '(1,250.00)' for a credit, and a dollar sign in some cells but not others | Amount fields in USD, with credits kept as negative amounts | Parentheses usually mean a negative amount. Find one credit and check the app shows minus $1,250.00. Then total the amounts of one page's rows in the app and compare the sum with that page's subtotal. |
| Stamps and initials across a page, such as 'APPROVED' or 'PAID 07/14' | A status or approval field, with who set it and when | Write down what each stamp means and who sets that status from now on, and put both in the prompt. Then open the records whose PDF carries a stamp and check the field on each. |
| Numbered clauses with deadlines, such as '5.3 Send the owner a statement within 15 days of each month end' | A task for each obligation, with a due date, an owner and the clause number | Read the whole clause, not only the number of days. A deadline counted from another date needs that date, so compare the first three due dates in the app with your own reading of the clause. |
| Comments and highlights a reviewer added in a PDF reader | Notes on the records they refer to, where they still matter | List the comments that still matter in the prompt, each with the item it belongs to. Then open those records and check every note landed on the right one. |
A PDF is the last step of someone else's process.
Most PDFs are output: a report run from a system, a certificate an inspector sent, an agreement both sides signed. The file shows the result, not the rules behind it or what was left out. Settle these before you upload.
Find out what printed the report
A footer such as 'Printed from' or a run time in the header usually means software produced the file. Ask whether that system can export the same rows as a spreadsheet or CSV. If it can, start from that export on the CSV to App or Excel to App page, and keep the PDF to compare against.
Which copy is current
PDFs get reissued as 'Rev B', 'signed' or 'final_v2'. Keep the latest certificate for each piece of equipment, and say in the prompt which copy wins when two disagree. Older copies can stay attached to the record as history.
Details that were fine on paper
A work order may carry a tenant's phone number or a lockbox code. On a printout sent to one vendor that was acceptable. In an app, keep details like these in a collection of their own with the access you describe for each collection, or delete them from the copy you upload.
Where the next PDF goes
An upload is a snapshot of these files. Next month's report or next year's certificate won't appear by itself. Decide now whether people add and update records in the app, or whether you bring in each new report on purpose and match rows on the work order number.
An illustrative starting point
Records to work on, with the source PDF beside them.
Records from your report's rows or from each PDF in a set, with fields you can filter, a status people update, and the source PDF attached.
A record for every row or every file
A thirty-page report can become work orders you sort by property, vendor or age. A folder of certificates can become one record each, found by building or equipment rather than by file name.
The source PDF beside each record
Attach each PDF to the record it produced, so someone who doubts a value can open the PDF and find the line it came from. Saved records and stored files need a backend.
Status and dates the page couldn't change
A printed PDF stays as it was on the day it was run. In the app, people close a work order, note who closed it and when, and see which certificates expire next quarter.
A reminder before a date passes
A task on a schedule you set can email the building manager the certificates due in the next 60 days. Send the first one to yourself and compare the list with the records.
Together in your app cloud
The pieces behind the possibility.
Choose the models and services that support the experience you want to create.
Database
Keep data and context for apps and agents
File storage
A home for your documents and media
Vision models
Make sense of images and documents
Authentication
Give the right people access
A little more context
Good questions.
Does this turn my PDF into an app page by page?
No. A PDF viewer shows the pages as they were printed. Here you turn the content of the PDF into records and fields that people search, update and add to. If readers only need to read the document, PDF to Website is the closer fit, and a manual people look things up in fits PDF to Knowledge Base.
Can I bring in a whole folder of PDFs?
Start with a few files of the same kind that differ in layout, such as certificates from two inspection companies, and check the fields on each. Then plan how the rest arrive. The app can have a form where someone attaches each PDF to a new record and fills in or confirms its fields.
Will a long report table come out right?
Check before you rely on it. Long reports often print a group heading, such as a property name, above its rows instead of repeating it in a column. Say in the prompt that each row belongs to the heading above it, even after a page break. Then open rows from two groups and confirm each shows the right property.
Can a model suggest the values in each new PDF?
You can ask for a step where a Vision model suggests fields from a PDF someone attaches, such as a certificate's next due date. Plan on some suggestions being wrong. Show each one beside the page and have a person confirm it before it is saved. Check which models your app can use, since model usage is metered separately.
Who can open the original PDFs?
Say who signs in and what they may open, using the access you describe for each collection. An elevator certificate may suit every building manager; work orders with tenant phone numbers may not. Then try a restricted PDF from a test account. The technicians and managers who sign in are app users, with the access you describe.
If the report is printed again next month, does the app change?
No. An upload supplies a snapshot. Either people update work orders in the app from now on, or you bring in the next report on purpose and match rows on the work order number. Then open a few work orders whose status changed and compare them with the new PDF. Try it with two months of reports before you rely on it.
Can technicians use the app on their phones?
The app is published at a web address and opens in a browser, including on phones. A report laid out for a wide page has too many columns for a small screen. Pick the three fields a technician needs in the list, then close one work order on a phone before you share the address.
Which plan does an app built from PDFs need?
Records people change, attached PDFs, sign-in, email and scheduled tasks all run on a backend, so the tracker is an app with data, and putting it live needs a paid plan. A read-only page would be a one-page site. Model and service usage is metered separately. Compare what each plan includes on the pricing page.
Explore Pricing for plans, included capabilities, and usage details.
Keep exploring.
Build a document and receipt organizer ↗
See the outcome and the capabilities behind it.
From a PDF to a reviewed, published app ↗
An illustrative workflow for reviewing the first version of an app built from a PDF before you publish it.
Understand data and context ↗
Give information the right place in your app.
Prepare to publish ↗
Check the experience you will share.
Your ideas, up and running
Your next idea has a home.
Build an app. Run an agent. Make it yours.
Start building