Turn signed Dropbox Sign contracts into a renewal countdown

Build me an app that answers the question Dropbox Sign cannot: what did we actually agree to, and when does it renew. Dropbox Sign stores the executed PDF but holds no structured terms and offers no renewal view, so the notice date lives nowhere. This app is the post signature layer. It is about extracted obligations and renewal decisions, not about logging new signings.

Loading the register. A handler calls the Dropbox Sign List Signature Requests operation filtered to completed and signed requests, paginating through the full history rather than just the first page. For each request it calls Get Signature Request to pick up the counterparty signers and the signing dates. Store one row per signature request in the app's own persistence, keyed by the signature request id, so the register survives reloads and does not refetch everything on every visit. Re-running the load should update existing rows and add new ones without wiping anything that has been extracted or corrected.

View one is the register. Turn that flat list into a table I can search and filter by counterparty, document type and annual value, with the signing date and signer names visible. Each row should make it obvious whether its terms have been extracted yet or whether it is still just a signed file with no known obligations.

The important part is a Read this contract button on each row that kicks off a background agent for that single contract. The agent calls Get Signature Request Files as File URL to pull the executed PDF, reads the document, and extracts the terms nobody currently has anywhere: the counterparty legal name as written in the contract rather than the signer's display name, the effective date, the initial term length, whether it auto renews, the notice window for cancelling, the annual value with its currency, and the termination clause captured close to verbatim so a human can check it. The agent then writes all of that back into the app's persistence so the register fills in. Show live progress on the row while it runs, and never invent a value: if a term genuinely is not in the document, leave it blank and mark it unknown rather than guessing, because a confident wrong notice period is worse than an empty one.

Derive two dates in the app from the extracted terms and recompute them whenever a field changes. The expiry date is the effective date plus the initial term. The notice deadline is the expiry date minus the notice window. The notice deadline is the number that matters and it is the one the second view is built around.

View two is a renewal countdown board sorted by the date the notice window closes rather than by the expiry date, because that earlier date is the one people miss. Contracts currently inside their notice window are flagged loudest, since for those the decision is live right now. Anything that auto renews within the next ninety days is pulled to the top. Show the days remaining until the notice deadline as the primary number, with the expiry date as secondary supporting detail, and show the annual value so the size of the commitment is obvious at a glance.

Whoever owns renewals opens this monthly, so put a plain count of the decisions needed in the next thirty, sixty and ninety days across the top of the board. Plain counts, measured from the notice deadline rather than the expiry date.

I must be able to correct any extracted field by hand, inline on the row, because a human reading the clause always wins over the extraction. A corrected field is stored as human set and must never be overwritten if that contract is read again later. Make it visible which fields came from the document and which a person fixed, so the register carries its own trust signal.

From the board I want two actions. Export the filtered register to a finance spreadsheet using the Google Sheets Append Values operation, sending one row per contract and respecting whatever filter is currently applied rather than always dumping everything. And send a specific renewal warning to the owning team using the Slack Send a Message operation, naming the counterparty, the notice deadline, the annual value and what happens if the date passes, rather than a generic nudge.

One firm constraint on storage. The extracted terms live in the app's own persistence and are never round tripped through the spreadsheet. The Google Sheet is an export destination for finance only, never a source of truth the app reads back from.