Loading Donald Lena…
Internal tools · Lead research
Why I Built PermitPulse: Turning NYC DOB Data into a Contractor Lead Pipeline
A public permit record can tell you that construction activity exists. It still leaves work to do: decide whether the project fits, identify the right company, find a credible contact route, and keep track of what happens next. PermitPulse is the internal tool I built around that sequence.
A record is a starting point
The PermitPulse source integration targets NYC Department of Buildings public data. Its normalization maps a record into fields the workflow can use, including a permit identifier, location, work description, filing information, applicant, and owner.
Those fields have different jobs. The location helps determine service fit. The description helps screen the work. The company information starts the research. A name in a permit record does not automatically establish who buys the service or whether a contact is appropriate.
The source and its field definitions also need care. Public datasets change, and a source adapter in a repository is not proof of a successful current scan. This article documents the implementation and workflow; it does not claim a freshly validated production ingestion run.
Make company matching reviewable
The canonical pipeline separates ingestion, company resolution, contact discovery, scoring, routing, drafting, sending, follow-ups, and outcomes. Keeping those steps separate makes it easier to understand where a record needs attention.
The operator workflow asks concrete questions before outreach: Is the company right? Is the contact route trustworthy? Is there a better manual contact? Should the record wait for an email address? Those questions belong in the product because uncertainty does not disappear when a record reaches a queue.
The system includes review and email-required states. Those states give an operator somewhere to put an unresolved lead instead of treating every imported row as ready to contact.
Connect the research to the next action
A researched contact is useful only if the follow-through is clear. PermitPulse connects the record to a draft, mailbox state, send controls, and follow-up handling. The operator checks the route, attachment, mailbox, daily cap, and trust thresholds before sending.
The workflow also records replies, bounces, opt-outs, wins, losses, and archived records. Those outcomes matter because a sent message, a reply, and a won job are different events. The tool should preserve that difference.
Imported prospect outreach uses the same broader lifecycle. That makes it possible to organize permit research and other prospecting around the same review habits without pretending their original signals are identical.
Build for the operator who uses it
PermitPulse is documented as an internal MetroGlass Pro system first. The repository includes workspace boundaries and invite-only access, while self-serve mailbox connection and billing are disabled by default. This is a build story about an internal operating tool, not a public product launch.
I am not publishing a lead count or a revenue claim here. The receipts show how the workflow is structured. Measuring its business effect would require a separate record of qualified opportunities, outreach, replies, estimates, and awarded work.
Permit-based lead research becomes useful when each record has a clear reason to pursue it, a reviewed contact route, and an honest record of the outcome.
Have a workflow that needs a clearer next step?
Tell me what you’re working on ↗