Build it with AI
Turn targeting, research, outreach, and next actions into one prospecting workflow.
Create a system that keeps account research, contact context, outreach status, and next steps attached to the same prospect.
Introduction
What this actually has to hold.
Most teams arrive at prospecting system the same way: research in browser tabs, a target list in a sheet, and outreach in a separate tool that never sees either. That is a reasonable starting point, and it holds for longer than people expect — right up until the number of participants or decisions depending on it crosses some threshold nobody noticed at the time.
The reason an account was targeted lives in the head of whoever added it, so the message that eventually goes out is generic. The failure is structural rather than a matter of effort. What is missing is a record of state, an owner attached to each step, and a rule that prevents the invalid transition — none of which the current approach can express.
This page covers prospecting system as software: what it needs to hold (target accounts, contacts, the research behind why each was chosen, outreach state, and the next step), how Launch builds the operating surface, how ARIA reads live context from LinkedIn data sources and Gmail, and — set out plainly further down — what this approach cannot fix.
The problem
Why the current approach stops scaling.
The reason prospecting system is worth building rather than configuring is that the process is specific to this business, and every generic tool models it as something adjacent. The gap between the two is where the spreadsheets, the side channels, and the tribal knowledge accumulate.
The reason an account was targeted lives in the head of whoever added it, so the message that eventually goes out is generic. The cost is not the inconvenience; it is that volume goes up, relevance goes down, and the domain reputation pays for it. That is the thing worth measuring, and it is rarely the thing anyone measures.
The second failure is disconnection. What prospecting system needs to hold is target accounts, contacts, the research behind why each was chosen, outreach state, and the next step, and the authoritative version of most of that already lives in LinkedIn data sources or Gmail. Keeping the two in agreement by hand is reconciliation performed on a schedule — and between runs, the copy is confidently wrong.
You're likely here because
- Keeping target accounts, contacts, the research behind why each was chosen, outreach state, and the next step current is somebody's recurring manual task
- The reason an account was targeted lives in the head of whoever added it, so the message that eventually goes out is generic.
- When it is wrong, volume goes up, relevance goes down, and the domain reputation pays for it
- Nobody can answer a question about it without asking a specific person
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Account workspace
- • Prospect queues
- • Research views
Operated through Grow
- • Targeting
- • Outbound sequences
- • Reply handling
Systems it reads
- • LinkedIn data sources
- • Gmail
- • HubSpot
How it runs
From description to a running operating surface.
The sequence that turns a described process into software reading live records, rather than another copy that starts drifting immediately.
Step 01
Describe what prospecting system has to do
Start from the outcome rather than the schema. On the ARIA path the requirement is resolved into which records, which states, which owners, and which permissions before anything is generated.
Step 02
Connect the systems that already hold truth
LinkedIn data sources, Gmail, HubSpot connect through governed, permission-scoped connectors, so the new surface reads live records instead of a copy that starts drifting the day it is made.
Step 03
Launch builds the operating surface
Forms, views, states, roles, and the logic between them are generated as a running application on the canonical component stack — prospecting system as software rather than as a document or a file.
Step 04
Start with the narrowest useful version
An account workspace where the research and the outreach state sit on the same record. Everything else waits until that one is genuinely used.
Step 05
Grow continues the motion
Where the workflow touches prospects, customers, or follow-up, outreach and scheduling run against the same records, with every outbound message staged for human review rather than restarting in a personal inbox.
Step 06
Measure reply rate on accounts where the message references specific research, against those where it does not
Establish the baseline before switching, compare after a full cycle, and keep an export path available so the whole decision stays reversible.
Implementation path
How to approach the build.
- 01
Write down how prospecting system is actually run today, not how it is supposed to be run. Most teams discover at this point that two different processes have been sharing one name.
- 02
Establish the baseline now — reply rate on accounts where the message references specific research, against those where it does not, plus how much manual updating happens each week. Without it you cannot tell afterwards whether anything improved.
- 03
Name the authoritative system for each field. Where LinkedIn data sources already owns a value, the new surface should read it rather than keep a second copy.
- 04
Connect LinkedIn data sources, Gmail, HubSpot read-first, and confirm the surface sees the same records your team sees before building anything on top of it.
- 05
Build the narrowest useful version in Launch: an account workspace where the research and the outreach state sit on the same record. Run it alongside the current approach for one full cycle rather than switching over.
- 06
Expand only after that first version is genuinely used, and keep an export path available so the decision stays reversible.
Controls
Controls that matter.
Control 01
Roles and permissions defined before anyone outside the core team gets access
Control 02
Connector access scoped to the records this workflow needs rather than the whole LinkedIn data sources account
Control 03
Human confirmation on any state change or outbound message an external party will see
Control 04
An export path preserved throughout, so this stays a reversible decision
Examples
What changes in practice.
Bounded situations rather than a feature list — each one verifiable against work the team already does.
The update that never happened
Today, target accounts, contacts, the research behind why each was chosen, outreach state, and the next step stays current only if somebody remembers to update it. As a workflow the state change is the event — recorded when it happens, with an owner and a timestamp attached, rather than typed in later from memory.
Reconciling against LinkedIn data sources
Keeping the two in agreement is manual work done on a schedule, and between runs the local copy is confidently wrong. Reading LinkedIn data sources directly removes the reconciliation step rather than making it faster.
Somebody outside the team needs a view
The current approach offers two options: share everything, or maintain a second copy by hand. Role-scoped views turn that into a permissions decision rather than a recurring copy-and-paste routine.
The first week after launch
An account workspace where the research and the outreach state sit on the same record — running beside the existing process, not replacing it yet. The parallel run is what turns a plausible design into a proven one.
Limitations and considerations
What this does not fix.
- Building prospecting system does not fix an undefined process. If nobody agrees what done means, the software encodes the disagreement — which is genuinely useful and also uncomfortable.
- Connector coverage varies. LinkedIn data sources, Gmail, HubSpot are representative; availability and the fields exposed depend on the system and on your workspace permissions.
- Migration effort scales with how much logic currently lives in formulas, macros, or one person's head. Re-expressing those rules explicitly needs somebody who understands what they were meant to do.
- Expect a period of running both. Retiring the current approach before the new surface has completed a full cycle is how teams end up with one more system rather than one fewer.
- Some of target accounts, contacts, the research behind why each was chosen, outreach state, and the next step may carry retention, privacy, or regulatory obligations that a general workflow layer should not assume on your behalf. Verify the requirement before automating a step that touches it.
FAQ
Build a prospecting system with AI: common questions.
Can I build a prospecting system with ai without starting from code?
Yes. Launch is designed to turn a plain-language brief into a working software artifact, then keep the project available for refinement and deployment.
Can the finished software connect to existing business systems?
Yes. The UbiGrowth operating layer is designed to connect software and workflows to the systems a company already uses, subject to workspace configuration.
What should the first version actually contain?
An account workspace where the research and the outreach state sit on the same record. Building the whole thing first is how these projects stall — the narrow version is what tells you whether the model is right before much has been invested in it.
Do we still need LinkedIn data sources?
Yes. LinkedIn data sources stays authoritative for what it owns, and the new surface reads it through a governed connector rather than keeping a second copy. That is what removes reconciliation work instead of relocating it.
How do we know whether it worked?
Measure reply rate on accounts where the message references specific research, against those where it does not against the baseline taken before anything changed. Adoption on its own is not evidence — people will use a tool they are told to use whether or not it improved the outcome.
What does this not fix?
An unclear process. If nobody agrees what done means for prospecting system, the software encodes the disagreement and makes it visible, which is useful but is not the same as solving it.
Related pages
Keep exploring
Start here
Build prospecting system around the process you actually run.
Describe it on the public ARIA path, or start from the narrowest version — an account workspace where the research and the outreach state sit on the same record — and expand once it is genuinely used.