How We Built Texas National Bank a Versioned PDF Disclosure System on Top of Webflow

There is a class of problem that only becomes visible after a project ships. The platform you picked works beautifully for ninety-five percent of the work, the team is happy, the marketing pipeline is humming, and then somebody from compliance asks a question that the platform was not designed to answer. The right response is usually to build a small, well-scoped piece of custom software that lives next to the platform and handles the part the platform cannot.

This post is about one of those pieces. A few weeks ago we published the launch of the new Texas National Bank website on Webflow. What that post did not cover is the small custom service Sal Yanez on our engineering team built to handle a specific problem that surfaces the moment a regulated institution adopts Webflow: disclosure PDF hosting with permanent URLs.

Why URL stability matters in banking

When Texas National Bank publishes a disclosure (Truth in Savings, Regulation E, Funds Availability, Privacy Notice, fee schedules, deposit account agreements), the URL where that PDF lives gets referenced in dozens of downstream places. The application flow on the bank's website links to it. The customer's signed deposit-account paperwork includes a printed reference to it. Email confirmations sent at account opening reference it. Partner sites, regulator filings, archived consumer-complaint records, and the bank's own internal training materials all point at the same URL. Three years later, when an examiner asks "what disclosure was published at this URL on April 14, 2024," the answer has to be both true and instantly retrievable.

The constraint is straightforward: every disclosure URL the bank has ever published has to keep working forever, and the version of the document served at that URL has to be controllable on a per-publication basis.

The Webflow quirk that breaks the constraint

Webflow's native asset management is a perfectly capable system for marketing-site PDFs. It handles uploads through a friendly UI, serves files from a CDN, and tracks usage across the site. It has one behavior that does not fit a banking workflow: when you re-upload a file to replace an older version, the new file gets a fresh URL with a different hash, and the old URL stops resolving the moment the old asset is deleted.

For a marketing site that change is invisible. The CMS updates the embedded link automatically and the page keeps working. For a bank, that change breaks every external reference to the previous URL the moment a new version of the disclosure goes live. The downstream customer who clicks the link on their three-year-old account paperwork gets a 404. The examiner asking about the April 14, 2024 version has no clean way to retrieve it.

This is the kind of constraint that does not show up in a feature-comparison spreadsheet before you pick a platform. It shows up after launch, when the bank's compliance team reads the new site and asks a question the platform was not built to answer.

Screenshot placeholder: The compliance/disclosure section of texasnational.com showing the linked PDF documents in context.

What Sal built

The fix is a small custom service that sits between the bank's marketing team and S3, and gives Webflow a stable URL to embed regardless of how many revisions a disclosure goes through over the years.

The marketing team uses a purpose-built upload interface. Each disclosure has a friendly name (Truth in Savings, Privacy Notice, Funds Availability) and a permanent, human-readable URL (something like disclosures.texasnational.com/truth-in-savings.pdf). When the team needs to publish a new version of an existing disclosure, they upload the new PDF through the same interface, the system writes it to S3 with a versioned object key, and the public URL keeps serving the latest version while every historical version remains addressable for audit and recovery purposes.

The Webflow site embeds and links to these stable URLs the same way it would link to any external resource. From the editor's perspective inside Webflow, the disclosure links are no different from a link to the bank's careers page or its press contact. From the application system's perspective, the URL it embedded in last year's confirmation emails still works today and will keep working three years from now.

Screenshot placeholder: The Sal-built admin interface showing the list of TNB disclosures with their friendly names, their permanent URLs, and a version history sidebar for the selected document.

The stack

The hosting service is built deliberately small. S3 holds the actual PDF objects, with versioned keys so every prior version of every disclosure is recoverable. A lightweight Node service running on our infrastructure handles the upload UI for the bank's marketing team, serves the public-facing redirect endpoints that map the friendly URL to the current S3 object, and writes an immutable audit log every time a disclosure is replaced. Webflow embeds and links to the friendly URLs without knowing anything about S3, versioning, or the audit log.

There is no Webflow plugin, no third-party document-management product in the loop, and no monthly per-document license fee. The bank's marketing team uses a single tool that does exactly the thing the bank's compliance team needed it to do, and Webflow continues to be the right platform for everything else on the site.

Why we did not look harder for an off-the-shelf option

This is the kind of project where the build-versus-buy conversation defaults to "buy" and then runs into a wall. There are document-management platforms in the financial-services space that handle versioning, audit trails, and stable URLs. Most of them are priced for institutions an order of magnitude larger than a community bank, ship with workflow features the bank did not need, and ask the bank to migrate every existing disclosure URL into the new vendor's URL namespace as a precondition for adoption.

The cost of writing a couple hundred lines of Node and a small admin UI was meaningfully lower than the cost of standing up an enterprise document-management subscription, and the result is exactly what the bank's compliance team asked for with no extra features in the way. Our build versus buy decision tree post walks through how we approach this kind of call more generally.

What other regulated clients can take from this

Two patterns hold across most of the custom software work we do for regulated industries.

The first pattern is that the right scope for custom software is usually the smallest scope that solves the actual problem. The bank did not need a document management system. The bank needed permanent URLs in front of versioned PDFs. The piece of software we shipped does only that, and the smaller scope is what made it cheap to write, easy to operate, and trivial to debug when something goes wrong.

The second pattern is that the most valuable custom software in a regulated business is often invisible from the outside. Nobody visiting texasnational.com knows the disclosure links route through a custom Node service before they hit S3. The customer who clicks the link three years from now will not know either. The internal value is entirely in what does not break: the application flow, the customer paperwork, the regulator filings, the audit trail. The cost of the platform shortcut shows up only in the moments where it matters most, and that is exactly the kind of cost a custom-built backstop is meant to absorb. Our custom software service page covers the broader scope of work we do in this category.

Running into a constraint your CMS or hosting platform cannot accommodate? Start a conversation. The smallest scope is usually the right scope.