Bullseye: From Audience Tool to Visitor Identification Platform
Last updated on February 10, 2026
Ryan Tabb ran a B2B podcasting agency. Google Analytics told him 50 people visited his pricing page last week. It couldn’t tell him who any of them were.
A single qualified visitor – a VP of Marketing at a mid-market SaaS company – could represent tens of thousands in annual contract value. That visitor browsed, evaluated, and left. Ryan never knew they existed.
Ryan decided to build a tool that would solve this for himself – and for every B2B company losing pipeline to anonymous traffic. That tool became Bullseye.
A tracking pixel captures visitor data, an identity graph matches that data to real people, and sales teams get named leads instead of anonymous session counts. Not company-level identification like most tools in this space – person-level. Not “someone from Microsoft visited” but “the VP of Engineering at Microsoft visited your pricing page twice this week.”
Softcery built Bullseye from scratch with Ryan in 2023. The first version was an audience building tool – surfacing targeted contacts and resolving them into custom audiences for ad platforms. We designed the architecture, built the full stack, and shipped to market. Then the product pivoted. Ryan recognized more value in identifying who was already visiting a customer’s website than building cold audiences, and Bullseye became the real-time visitor identification platform it is today.
Then ownership changed. Dan and Chris at Acme Studio acquired Bullseye in early 2025 and kept Softcery on. The product delivered real value – but the next phase demanded more. Multi-tenant authentication for agencies. Self-service billing instead of manual operations. An enrichment pipeline built for higher volumes. The platform needed to evolve for enterprise customers, agency resellers, and significantly higher traffic.
“We’ve built our entire B2B SaaS platform together, and I genuinely can’t imagine working with anyone else.” – Ryan Tabb, Founder, Bullseye
The Challenge: Five Problems to Solve Before Scaling
Bullseye’s original architecture followed clean architecture principles – business logic decoupled from external services, each integration behind an abstraction – so the team could swap providers without rewriting pipelines. But the product outgrew its initial scale. What worked for dozens of customers needed to work for hundreds – with agencies, sub-accounts, and significantly higher traffic volumes. Five areas needed to evolve.
Authentication needed to support multi-tenancy. AWS Cognito handled authentication from launch and worked for the early product. As the agency model emerged – one organization managing multiple client accounts – Cognito’s single-tenant design became a bottleneck. Multi-organization access, role-based permissions, and member invitations required capabilities the system wasn’t built for. The platform needed an auth layer designed for the product Bullseye was becoming, not the one it started as.
Infrastructure needed to scale with demand, not burn budget statically. The AWS stack served the product well during development and early growth. But the setup ran on fixed-size infrastructure – paying the same regardless of traffic volume. As the product scaled, costs grew linearly while utilization didn’t. The platform needed a simpler stack that costs less by default, scales compute resources as volume grows, and puts the savings toward better instances instead of idle capacity.
Agencies couldn’t onboard. Agencies wanted to resell Bullseye to their clients – a significant revenue channel. But the platform had no concept of parent-child organizations or role-based access. An agency managing five clients needed five separate logins – log out, check data, log out, log in again.
Billing ran on manual operations. Only partially automated – an intentional tradeoff to reach market faster. The founder topped up credits for individual customers through Slack and an internal admin tool, week after week. If a customer hit their credit limit on a Friday evening, they were blocked from capturing leads until Monday morning when someone could manually update their quota. This worked at early scale. It wouldn’t work with dozens of agency sub-accounts needing automated credit management, overage tracking, and consolidated invoicing.
Lead enrichment needed a better architecture for scale. The original enrichment service operated synchronously – each lookup blocked until it returned a result. At early volumes, this worked fine. As visitor traffic grew, synchronous processing became a bottleneck. The platform also needed better handling of catch-all email domains, where standard verification methods fail entirely.
The Solution: Rebuilding for Enterprise Scale
Five areas, each blocking the next phase of growth. We addressed them in sequence – evolving existing systems, then building new capabilities – while keeping the core visitor identification running for existing customers.
Login that works out of the box. A managed authentication service replaced Cognito entirely. The service comes with its own dashboard and backoffice – agency support, user account creation, 2FA, social logins, organization management, role assignment, and member invitations all work out of the box without custom code. All this previously required engineering effort to build and maintain.
The migration required solving a vendor lock-in problem: Cognito doesn’t export password hashes, so existing credentials couldn’t transfer. The team generated temporary credentials, enabled verification-link login as a bridge, and migrated users without service interruption.
Simpler, cheaper, more observable infrastructure. We simplified the hosting stack – fewer moving parts, managed Postgres, Cloudflare for edge delivery and DNS. The goal: reduce operational complexity so a small team can run the platform without deep infrastructure expertise. The migration completed in two weeks with zero downtime. The result: ~40% reduction in hosting costs, better observability across the system, and infrastructure simple enough for the in-house CTO to manage day-to-day.
One dashboard for every client. We designed a flexible organization hierarchy: agency organizations, sub-organizations, and standard accounts. Agencies create and manage client accounts from a unified dashboard – no more logging in and out. Sub-account users see their own data without agency-level billing details. The system supports per-seat pricing with discounts or shared credit pools across sub-accounts.
Billing that runs itself. Self-service subscription management replaced the manual workflows. Users select plans, enter payment details, and start using credits immediately – no sales call, no manual provisioning. The system tracks usage, handles overages with user-defined limits, and processes automatic renewals. Agencies receive consolidated invoices covering all sub-accounts. A customer hitting their credit limit on Friday evening now gets automatic renewal – not a blocked weekend.
Lead enrichment that keeps up. We rebuilt the enrichment pipeline as an asynchronous service with automatic retry logic for failed lookups. Valid email recovery improved by over 30%.
Tracking scripts served from the edge. We moved pixel delivery to Cloudflare Workers, serving scripts from edge locations worldwide. Cache hit rates above 90%, no origin server dependency, and automatic scaling for traffic spikes.
“Softcery combines deep product strategy with technical execution – they don’t just follow instructions, they challenge your approach and find better solutions.” – Ryan Tabb, Founder, Bullseye
The Product: How Visitor Identification Works
One script tag to start. Customers add a single line of code to their website. The tracking pixel loads from Cloudflare’s edge network – fast globally, resilient to origin issues. No SDK, no complex integration. Deploy the script and start identifying visitors.
Person-level identification. When visitors browse, the pixel captures session data and sends it to an identity graph for matching. The graph links digital identifiers – cookies, IP addresses, browser fingerprints – to real people. Deterministic matching, not probabilistic guessing. For US traffic, identification rates reach 20–30% of individual visitors. Each match arrives with a name, job title, company, LinkedIn profile, and contact details.
From visitor to pipeline. Identified visitors flow automatically to major CRM platforms, sales engagement tools, and team communication apps. The system checks if a contact already exists and appends visit activity rather than creating duplicates. Users set up flows with filters – only send leads matching specific criteria to specific destinations.
Dashboard and analytics. Visitor counts, industry distribution, job title breakdown, and trends over time. Filtering by company size, job title, and visit frequency helps teams focus on high-value prospects.
Privacy by design. Strict geo-fencing at the Cloudflare edge means identification logic never executes for visitors in GDPR jurisdictions. Scripts are served from the customer’s own subdomain context, surviving ad blockers and browser privacy restrictions. The architecture separates what can be collected from what should be collected.
Hundreds of customer websites generating sessions simultaneously, each expecting real-time identification. Here’s how it works under the hood.
The Engineering Behind Identification
Session processing pipeline. When a visitor hits a customer’s website, the tracking pixel sends session data to the identity graph. The graph resolves digital identifiers to a person and fires a webhook back to Bullseye. A message queue absorbs incoming webhooks – hundreds per second during peak traffic – and workers drain it at a rate the database can sustain. From there, sessions enter a processing pipeline: deduplication, concurrent batch processing, and enrichment. Roughly 2,000 sessions clear every two-minute cycle under normal operation. Load-tested to 20,000 requests in two minutes.
Enrichment that doesn’t drop data. After identification, sessions pass through an asynchronous email enrichment service. When a lookup fails or times out, fallback logic queues it for automatic retry rather than dropping it. Credits deduct on request and refund if no result returns – simpler than tracking deferred outcomes.
Script delivery independent of the backend. No origin server contact on script load. When a customer updates their pixel configuration, targeted cache invalidation fires automatically. Visitor tracking continues independent of backend availability.
Before and After
The rebuild cut operational overhead, stabilized the platform, and unblocked the agency channel.
| Area | Before | After |
|---|---|---|
| Script load time | ~800ms | ~200ms |
| System uptime | ~95% | 99.9% |
| Hosting costs | Fixed AWS infrastructure | ~40% reduction |
| Billing operations | Manual, hours per week | Fully automated self-service |
| Email enrichment validity | Standard | +30% more valid emails recovered |
| Agency support | None | Full multi-tenant hierarchy |
| Authentication | AWS Cognito (requires custom code) | Managed authentication service |
How We Worked Together
Most engineering relationships don’t survive an acquisition. Softcery built Bullseye with one owner and rebuilt it with another – two years, two codebases, one team.
Retained through acquisition. Softcery built the original Bullseye platform with Ryan Tabb in 2023, shipping from concept to launched product. When Dan and Chris at Acme Studio acquired Bullseye in 2025, they evaluated the codebase, assessed the team, and chose to keep Softcery on – then expanded the scope. Institutional knowledge from building v1 made the v2 rebuild faster and more informed. We knew where the architectural seams were because we’d built them.
Partners, not vendors. The new owners arrived with a product vision – more integrations, more data sources, agency channel growth. Softcery assessed the platform and shared our perspective on what should come first. Self-service billing and account management before new features – agencies can’t onboard if they can’t manage their own subscriptions. Infrastructure and auth migration before new integrations. The final roadmap reflected both their vision and our engineering context.
Solving challenges along the way. Rebuilding a live product means dealing with unexpected issues while keeping everything running. Throughout the migration to v2, the team identified and resolved problems as they surfaced – infrastructure edge cases during the transition, data processing gaps, configuration changes that cascaded in unexpected ways. Each one got diagnosed, fixed, and documented so it wouldn’t repeat.
Documentation for the next phase. Bullseye was moving toward a sales-driven growth phase where active development would slow down. We documented everything with that transition in mind: development workflows, deployment processes, API specifications, integration guides. The new owners’ in-house CTO now manages the platform day-to-day – onboarding, maintenance, operations – and comes back to Softcery when more active development is needed.
“Softcery was fantastic throughout our re-build of a recently acquired B2B SaaS. Highly recommend if you are in need of high quality AI and SaaS engineering.” – Chris Riley, Acme Studio
