Skip to content
FLANERY
← Flanery Solutions

A wealth advisory firm · 2026 · Financial advisory

Turning public filings into a queue somebody can actually work

The information was all public and none of it was usable — scattered across federal filing systems in a dozen formats, none of which agree on how to spell a person's name. It now arrives as a deduplicated, scored queue where every entry carries a link back to the filing it came from.

This client hasn’t been asked yet whether they’re happy to be named, so they aren’t. Everything else here is exactly as it was built. If you want a reference before hiring me, I’ll ask them.

Built with

TypeScript · Next.js · Postgres · PL/pgSQL · Supabase

Where it stands

  • Around 50 documented ingestion strategies, each one a separate filing type.
  • Every record carries provenance — the filing, the date, the field.
  • Deduplication across sources that spell the same person four ways.
  • Nothing contacts anybody. It assembles; a person decides.

Before

Federal regulators publish an enormous amount in public: company filings, retirement plan disclosures, registrations, state incorporations. For a firm whose work depends on knowing when something has changed for someone, it is all theoretically available and practically unusable.

The formats disagree. The identifiers disagree. The same person appears as "Robert J Smith", "SMITH ROBERT JAMES" and "Smith, Bob" across three systems with no key linking them. Reading it by hand is a full-time job that produces a spreadsheet nobody trusts by Thursday.

What I built

An ingestion and review system. Roughly fifty documented strategies, each one handling a specific filing type, running continuously and writing into a single Postgres schema.

The parts that took the real work were not the parsers.

Deduplication. Deciding that two records describe the same person, when the only shared fields are an inconsistently formatted name and a partial address, is the actual problem. Get it wrong in one direction and the queue fills with duplicates; wrong in the other and you silently merge two different people, which is much worse and much harder to notice.

Provenance on every field. Each record links back to the specific filing it came from, with the date and the field. Nobody has to trust the system — they can check it in one click. A system that produces confident output with no way to verify it is worse than no system, because people believe it.

Scoring, and the ability to disagree with it. Records are ranked, but the ranking is visible and overridable rather than a black box that hands down a number.

Workflow state. Each record moves through a status a person sets. The system's job ends at "here is what changed, here is the proof"; a human decides everything after that.

The rule the whole thing was built around

Nothing in this system contacts anybody.

There is no send button, no automated outreach, no integration that could accidentally acquire one. It assembles public information and presents it for review, and that is the entire scope.

That was a design decision, not an omission. In a regulated industry, the distance between "a tool that helps you find public information" and "a tool that acts on it" is the distance between a research system and a compliance problem. Building the send button would have taken an afternoon and been the single worst decision available.

After

It runs in production and is actively developed — roughly 485 commits, 33 schema migrations, and around 400 connector modules, one per filing type.

The measure that matters is not volume. It is that the output is checkable: an advisor can look at any entry and see, in one step, exactly which public filing it came from and on what date. That is what makes it usable rather than merely impressive.

If any of this sounds like your operation, the first call is free.

Ask for a call