Real-estate marketing

Website and Facebook leads brought into one operating console

Forms and Lead Ads webhooks feed a shared PostgreSQL model, followed by a permissioned console and email notification workflow.

Sector: Real-estate marketing
Period: In production
Our role: System architecture, backend, administration interface, and deployment

The problem

Leads arrived through website forms and Facebook Lead Ads with different formats and timing. When email and spreadsheets carry the handoff, duplicate records, processing status, and staff access gradually become inconsistent. It also becomes difficult to trace when a record arrived, who accessed it, and what happened next.

Constraints

Public forms and Meta webhooks must accept external requests without exposing the administrative surface or lead records.
Sources may resend events, omit fields, or arrive late, so ingestion must identify duplicates and retry safely.
Lead data is sensitive operating information; public material cannot disclose its volume, content, or client identity.

What we did

Use PostgreSQL as the operational source of truth

Leads, sources, states, and operational relationships live in PostgreSQL, giving console reads, writes, and permissions one transactional model.

Why not the other path We did not use BigQuery as the day-to-day operating database because it suits analysis, not frequent state changes and relational workflows.

Separate public entry points from administration

Website forms, webhook ingestion, and authenticated management functions have explicit boundaries, limiting the effect of public traffic on internal operations.

Why not the other path We did not place every route and permission into an undifferentiated service because public and administrative surfaces have different risks and scaling patterns.

Receive webhooks immediately, with replay protection

Facebook Lead Ads events are verified and processed on arrival, while source identifiers prevent the same event from creating a second record.

Why not the other path We did not rely only on scheduled polling because it adds notification delay and obscures the original event sequence.

Put roles and audit history in the core model

Authentication, role-based access, and operation records govern the console instead of merely hiding controls in the interface.

Why not the other path We did not substitute shared accounts or frontend conditions for authorization because access to sensitive records needs a traceable backend boundary.

Outcomes

Website forms and Facebook Lead Ads now enter one operational data model.
Authorized staff can work in a role-aware console instead of relying on scattered email and spreadsheets.
Notifications, sources, and operating states remain part of a traceable system workflow.

Technology

Go
PostgreSQL
Google Cloud Run
Cloud SQL
Meta Webhooks

Looking back

If we started again, data-retention rules and a least-privilege matrix would be requirements in the first release. They are not administrative details to add after launch; they determine whether a lead system deserves trust.