Dossier · limitations
Everything the application does not do, separated into three kinds: decisions taken on purpose, costs of running on free tiers, and things that are genuinely not working.
Most of what follows is the first kind — deliberate, and listed first. The dependency at the end is the one worth reading closely: anyone can list features they did not build, but the useful question is what the thing leans on that it cannot guarantee.
These are not oversights. Each was cut to keep the build focused on the problem statement, and each has a clear reason.
One password gates the whole application, exchanged for a signed HttpOnly session cookie. There are no user accounts, no roles, no per-user data separation, and no password reset. Everyone who logs in sees the same leads.
For a single-operator tool that is adequate. For anything shared it is the first thing that has to change, and it was left out because real auth is a project of its own, not because it is unimportant.
Sending uses one Gmail address and app password held in the environment. Every message goes out from that mailbox regardless of who is logged in, because there is only one of them. A team would need each rep sending from their own address, which means OAuth per user and tokens in the database.
No shared inbox, no assignment, no seeing who already contacted a prospect, no duplicate protection across colleagues. Two reps running this would each research the same person and each email them.
There is no sequencer, no cadence, no scheduler and no batch send. Every message is one deliberate click. That is a deliberate safety property — a sent email cannot be unsent — but it also means the tool does not do the follow-up that most replies actually come from.
Send is one-way. No reply tracking, no open or click tracking, no bounce handling, and no idea whether anything worked. The app can tell you what it sent and why, and nothing about what happened next.
A message goes out when you click. Nothing knows the recipient's timezone, working hours, or whether Tuesday morning beats Friday evening.
There is no job queue and no background worker. A run happens during the HTTP request that starts it, and progress reaches the browser by polling the stage rows it writes. That was the right shape on serverless and it still works, but it caps how much can be in flight and means a very large batch is a long series of requests rather than one queued job.
CSV export is the bridge. Nothing writes back to Salesforce or HubSpot, nothing reads an existing account list, and nothing knows what your CRM already says about a prospect.
The ICP settings score prospects you already have, or people found at a named company's competitors. There is no “find me everyone matching this profile” across the market.
That threshold is the point — one edit is a mood, not a rule — but it does mean the first few drafts teach it nothing, and a user who edits differently every time never accumulates a rule at all. Only one persona is active at a time, so a rep selling two products switches between them by hand, and what one learns does not help the other.
Where this goes next Several personas live at once and chosen per lead, a shorter cold start seeded from messages already written, and a threshold weighted by how decisive an edit is rather than a flat count of three. See what comes next, item three.
Which fact becomes the opening line is scored on buying intent and on a preference for person-level signal over company news. Those weights are a starting point, not a verdict — the agent watches which hooks you actually pick and shifts its ranking towards them.
So on a fresh install it can open on a company fact where you would have opened on something the person said themselves. You overrule it, and it learns from that. The cost is that the first few leads carry defaults rather than your judgement, exactly like the persona does.
Query generation, extraction, judging and drafting all assume English sources and English output. A prospect whose public writing is in another language is effectively invisible to it.
Fact-level feedback is tied to the run it came from, so clearing old runs also clears the record of which facts were kept or dropped and why. The persona's written rules survive; the evidence behind them does not.
Every external service is on a free plan. Nothing here is a design decision; it is what the budget allows, and each one has a number attached.
A full research run spends roughly 12 to 25 searches, so the month is about 40 to 80 prospects in total. A reserve is held back so the budget cannot hit zero mid-batch, which is why deep research starts being skipped before the credits are actually gone.
Small enough that resolved profiles are cached for 30 days, and re-running the same person costs nothing. That cache is doing real work rather than being an optimisation.
In an outbound campaign every contact is meant to go through the full research pipeline, at roughly 12 searches each. A reserve is held back so a batch cannot drain the month to zero, so as the budget approaches that floor the research step is skipped and the draft falls back to a competitor-angle message.
The run says so — “0 researched in full, 1 from the competitor angle” — but it is one line among several, and the same screen can show a fully-researched contact or a generic one with little to separate them. On a paid plan this simply would not trigger.
Roughly $1 of credit a month at 0.5 GB — hours of always-on uptime rather than a month of it. The database is Supabase's free tier, with a small connection budget that caps how many instances can run at once.
LinkedIn and X are where this tool gets the signal that makes it different from a web scraper. Neither can be reached directly, which puts a third party in the middle of the most important thing the product does.
Neither platform offers public API access. Getting it means registering as a company and going through an approval process, which is not available to somebody building this on their own. So the profile and post data comes through a provider that has already done that work.
That is the right call — the alternative is driving your own logged-in session with a scraper, which risks the account doing it and breaks the moment either platform changes its markup. But it does mean the most distinctive part of the research path runs on somebody else's uptime and somebody else's allowance.
In practice that shows: on one day a profile that resolved correctly returned “profile text not available yet”, and a lookup by name and company took eleven seconds and found nobody. Every run degrades to web search when this happens, so nothing fails outright — the LinkedIn and X half just quietly thins out.
What it would take to remove Official platform access, which means a registered company and an approved application. Until then the mitigation is what is already there: cache aggressively, always resolve by profile URL rather than by name, and treat the provider as an enhancement the run can finish without.