caiden

the biggest issue with sales navigator scrapers is that they require your linkedin account you put yourself at risk, it’s your cookies ours fully runs on the cloud

I've made by far the cheapest sales nav and google maps scraper also the highest quality on the market looking for beta testers - drop a comment here or dm

blows my mind that more local service businesses aren't using public data to find customers... you can detect events that CREATE demand for your service and find potential customers BEFORE they even start looking. hailstorms = roofers, window installers renovation permits = electricians, contractors new business licenses = cleaners, signage property sales = movers, landscapers here's how i'd build it: 1. Python + weather .gov/NWS to monitor storms and severe weather reports 2. ArcGIS/Socrata APIs + county records to pull permits, licenses and property sales 3. Regrid API + PostGIS to match events to properties and identify owners 4. BatchData to skip trace homeowners and enrich business contacts separately 5. Postgres + cron to detect new events, deduplicate and score leads 6. Python + an LLM to classify records and generate relevant outreach angles might be worth building this instead of dumping thousands into the same recycled leads every other contractor is buying lol

i've burned through 3 BILLION tokens on uncensored deepseek v4.1 flash in the past 24 hours for $87 if you're still defaulting to claude and chatgpt for everything you're ngmi PLEASE spend a weekend going down the chinese open-weight model rabbit hole. deepseek, qwen, kimi, glm, uncensored fine-tunes, abliterated models, local inference, all of it the price/performance on some of this shit is genuinely ridiculous and 99% of people have no clue it even exists you can run smaller models locally with Ollama, LM Studio or MLX. larger models through Venice AI or other inference providers. plug them into OpenCode and suddenly you have a coding agent with terminal access, browser tools, filesystem access, whatever you configure YOU DO NOT NEED TO BE LOCKED INTO ONE MODEL OR PROVIDER here's a prompt. literally paste this into your coding agent: "research the current chinese open-weight model ecosystem. deepseek, qwen, kimi, glm, plus uncensored and abliterated variants. inspect my hardware and figure out what i can run locally with Ollama, MLX or llama .cpp. for anything too large, compare hosted providers including Venice AI. compare actual output tokens/sec, TTFT, context limits, input/output pricing, cache pricing, coding ability and tool-calling reliability. find the best options for my actual workloads, not benchmark leaderboards. set up OpenCode with the best local and hosted models for my budget. configure the providers, test tool calling, optimize context usage and benchmark identical tasks across endpoints. show me the fastest, cheapest reliable setup you can actually get working. verify everything before changing my existing configuration." ALSO PLEASE understand that the model and the inference provider are two different things you can have the EXACT same weights running at wildly different speeds depending on who's serving them. check real decode speed, not advertised throughput prefix caching, context compaction, quantization, model routing. look into this shit. your agent could be spending more money rereading old tool outputs than actually solving anything and stop using expensive reasoning models for tasks a tiny local model or 20 lines of python could handle there's so much money being wasted on AI subscriptions by people who haven't even tried running a model outside a chat window it's actually insane

deepseek v4.1 flash REALLY likes creep by radiohead for some reason i'm building a local music app because spotify and soundcloud suck, and every time deepseek tests a feature it plays creep every. single. time.

people will burn $300 in tokens vibecoding a worse version of a tool another company spent years perfecting sometimes speed matters more than owning the stack if it already works, use it and move

you met me at a very Chinese time in my life

anyone who's turbo autistic and riddled with ADHD has to actively resist starting a new company every time something interesting catches their attention AI can now clone a competitor's frontend and core backend in a day dangerous amount of freedom to give us LOL

if you're using claude to build web scrapers, feed it this context before letting it write another 800 lines of Playwright some interesting rabbit holes worth going down: HAR diffing capture two network sessions, change ONE variable between them and have claude compare the request bodies, parameters, response structures and dependency order. repeat across searches, filters, pagination etc. you can start piecing together the underlying query model without having to automate every interaction through the browser. AST analysis rather than manually digging through 40,000 lines of compiled javascript, have claude parse the relevant bundles into an abstract syntax tree using Babel or Acorn. trace request constructors, shared API clients, pagination handlers and response transformations. have claude correlate what it finds against your HAR captures. source maps check for exposed `.js.map` files containing `sourcesContent`. depending on the build configuration, these can reconstruct portions of the original readable frontend source. feed claude the recovered modules alongside your network captures and have it map the API clients, field transformations and application state. minification ≠ encryption. hydration payloads inspect the initial HTML for `__NEXT_DATA__`, Nuxt payloads and React Server Component flight data. some frameworks serialize application state into the initial document, meaning the records you're looking for might already be present before client-side hydration even begins. have claude compare these against subsequent network responses. schema inference capture 20–30 DIFFERENT JSON responses. different searches, record types, filters, etc. have claude generate a union schema, identify optional fields, nested attributes, inconsistent types and null behaviour. last thing you want is an extractor that works beautifully on your first 100 records and silently drops useful attributes across the next million. response transformations compare raw server responses against the actual records displayed in the UI. frontend code can merge objects, rename attributes, calculate additional values or discard fields entirely before rendering. have claude reconstruct those transformations and map the original response fields. occasionally the interface is showing you substantially less information than the server actually returned. incremental acquisition look into ETags, Last-Modified, update timestamps, stable identifiers and content hashing. where supported, these can help identify which records actually changed instead of collecting and processing the same dataset every single run. especially interesting once you're dealing with millions of records and recurring refreshes. data reconciliation take samples from multiple sources and have claude construct a canonical schema. normalize company domains and identifiers, compare timestamps, preserve field-level provenance and assign confidence scores where information conflicts. also please stop deduplicating companies by name alone. you are going to merge 14 unrelated businesses called Apex Solutions into one entity. extraction observability have claude build checks for schema drift, unusual null rates, unexpected pagination behaviour, duplicate inflation and sudden changes in record counts. a scraper crashing is whatever. a scraper running successfully for 3 weeks while quietly producing incomplete datasets is a much more expensive problem. also worth having it generate a small validation report after every acquisition rather than trusting a successful exit code. there's a LOT more to scraping than making a browser click buttons. understand the data pipeline before you automate it.