Marketing automation across CoStar's marketplaces

The work

I joined CoStar Group in Richmond, Virginia, in July 2023 as an Associate Software Engineer and have been promoted twice since, to Software Engineer II. I work on the marketing-automation platform that reaches millions of contacts a day across CoStar's 7+ marketplaces, Homes.com among them.

The work runs from the React screens marketers use to build campaigns down to the pipelines and data stores that decide who gets enrolled. Most of what follows is the part I built myself. The platform as a whole belongs to the team.

What I built

Product features, end to end. I shipped React and TypeScript features across the platform: the campaign, audience-builder and automation UIs, multi-language support, and lead reconciliation in the revenue dashboard.

Enrollment pipelines for Homes.com. For the $1B Homes.com initiative I built event-driven enrollment pipelines on Lambda, API Gateway, SQS and Kafka. I also migrated the demo-request campaigns from Pardot to Salesforce Marketing Cloud.

Reusable workflow actions. I designed reusable workflow actions for the platform in C#, .NET, SQL Server and Snowflake. Adding a new campaign capability used to mean a multi-week custom integration. With the actions in place it takes about a day.

Field-level CoStar Sync subscriptions. I architected Kafka subscriptions to CoStar Sync that listen at the field level, with replay, backfill and idempotent consumers. The design is projected to cut downstream writes by 80 to 90 percent. That figure is a projection, not a measured result.

Cost and database cleanup. I removed unused AWS services through Terraform, retired SQL procedures that OpenSearch had replaced, and sped up a high-traffic stored procedure.

Separately, I re-architected the backend of CoStar's AI platform; that work is summarized on my résumé.

Decisions

What I'd do differently

I would write down the contract for each reusable action earlier: what it accepts, what it guarantees, and how it fails. Shared building blocks only save time if the people using them can trust them without reading the code, and that trust comes from documentation and tests as much as from the implementation.

I would also put measurement in place before a change ships rather than after. The field-level subscription work has a projected impact, and the better habit is to decide at design time how the real number will be measured, so the projection can be checked against it.