One screen. Real contacts. GDPR by design.

What the brief asked for.

Four observations from the PRD and our call that shape every decision in this proposal.

1.1   A prospecting layer, not a database dump

BDI's current workflow requires recruiters to manually export contacts and upload a CSV. This proposal replaces that entirely — a structured Wiza-powered search screen embedded directly in the campaign builder, so the prospect-to-campaign loop closes in one interface.

1.2   GDPR is a first-order architectural constraint

You were explicit: every feature must be built with data protection as a first-order concern. That shapes the enrichment pipeline (personal email requires confirmed lawful-basis acknowledgement), the data model (no personal data stored without a contact method), and the DPA documentation delivered at handover. We've built for this before — see alldayDr in Case Studies.

1.3   The API complexity is manageable — with one known gap

We read the full Wiza Prospect Search and Individual Reveals API specs before writing this proposal. Every filter in the PRD maps to a native Wiza API parameter. One exception: postcode radius search does not exist in the Wiza API — it supports city, state, and country, but not radius. We propose replacing it with city/state/country selection, which covers the same functional intent.

1.4   You've been through the deliverability problem — so have we

On our call you mentioned a 0.6–0.8% reply rate and a move toward O365/GWS accounts with proper warm-up. We've run our own outbound for years, built our own sending infrastructure, iterated on deliverability, and managed domain warm-up in production. More in Section 05.

What fits the engagement.

2.1   In scope

2.2   Out of scope (on purpose)

• ⚠Postcode radius filter — Not available in Wiza API. Replaced with city/state/country.
• ⚠Cross-campaign exclusion checkboxes — Depends on data model; defer per PRD if too complex.
• →Clean & Standardize screen — This proposal ends at "Continue to Campaign".
• →Email sending infrastructure — BDI's existing AWS/SMTP stack untouched.
• →Removing contacts after adding — Known PRD limitation for June release.

Every Wiza filter, surfaced cleanly.

We reviewed the Wiza Prospect Search API (POST /api/prospects/search) end-to-end before writing this proposal. Every filter maps to a native API parameter.

Background enrichment, real-time counter.

Enrichment is asynchronous by design. The user is never blocked while contacts resolve in the background.

4.1   The flow

1. 1
   User selects contacts + clicks "Add to Campaign"
2. 2
   BDI backend fires N × POST /api/individual_reveals
   one API call per selected contact
3. 3
   Wiza processes asynchronously
   queued → resolving → finished / failed
4. 4
   Wiza POSTs webhook to BDI callback URL on each completion
5. 5
   BDI stores enriched contact, emits WebSocket/SSE event
   Frontend counter increments: 23 / 500 → 24 / 500

4.2   Fields returned per contact

4.3   GDPR note

Contacts that fail enrichment or don't meet the minimum threshold (First Name + Job Title + at least one email) are excluded without storing any personal data. Minimum-threshold filtering is a data minimisation decision, not just a product constraint.

We don't just build outbound tools. We run one.

Before you chose a development partner, you wanted to know they understood the problem. Here's our track record — not from a client brief, but from our own campaigns.

SoluteLabs has run its own outbound for several years, targeting B2B SaaS and enterprise clients across the US, UK, and Australia. We've built and iterated on the same infrastructure stack you're working through right now. This isn't theoretical knowledge. It's hard-won from our own domains, our own deliverability incidents, and our own reply rates.

Your stack, our defaults.

You specified the technology. We're already building on it every week.

GDPR by design, not by checkbox.

You asked for this explicitly. Here's how it shows up in the code, not just the copy.

GDPR compliance in a prospecting tool is not a single feature — it's a set of architectural decisions made before the first component is written. We've built for the UK regulatory environment before. alldayDr was awarded a place on the NHS GPIT framework and achieved ISO 27001 certification under our delivery. See Section 10.

The team.

Named from day one. No swaps without prior written agreement. The team that scopes is the team that ships.

Six weeks. One fixed price.

Five milestones. Fixed at signing. Cost overruns route through a written change request — you know before we spend.

What you walk away with

• →Production-ready React + Node.js feature, integrated into your BDI codebase
• →Full test coverage — Jest + React Testing Library
• →GDPR data flow documentation, formatted for DPA attachment
• →IP fully transferred on final payment — no strings, no ongoing dependencies
• →Written Phase 2 plan for deferred items (cross-campaign exclusions, postcode radius)

We've shipped this shape of work before.

Three engagements that map directly onto the BDI build — one from the UK market with NHS integration and full GDPR compliance, one live contact enrichment pipeline we operate ourselves, and one UK client at similar project scale.

Why SoluteLabs, and what's next.

You received three quotes. We are not the cheapest. Here's why we're the right fit.