DEV Community: Andy Terekhin

GEO Specialists and Traditional SEOs Need Different Things From an AI Visibility Platform

Andy Terekhin — Wed, 19 Aug 2026 12:40:45 +0000

Forty-three percent of B2B buyers now start product research in an AI chat interface rather than a search engine, according to Forrester's 2026 Buyer Preferences Survey. If your agency is still measuring success by Google rank position alone, you are optimizing for a shrinking slice of the discovery funnel.

The real problem is not that traditional SEOs are ignoring AI visibility. Most are not. The problem is that the platforms being marketed as "AI visibility" solutions are built around one workflow, then sold to two very different practitioners who need fundamentally different things. Buying the wrong one does not just waste budget; it leaves a measurable gap in how your brand shows up when ChatGPT, Gemini, Claude, Perplexity, or DeepSeek answers a buyer's question.

This article takes a position: a single AI visibility platform cannot serve a GEO specialist and a traditional SEO equally well, and agencies that pretend otherwise are accepting worse outcomes for at least one of those roles.

What a traditional SEO actually needs from an AI visibility layer

A traditional SEO's core workflow is built around crawlability, keyword rankings, backlink authority, and on-page signals. When they add AI visibility monitoring, they are asking a narrow question: "Is the content I already produce getting cited by AI engines, and which technical or structural changes would increase citation frequency?"

For that workflow, the useful data points are citation rate by URL, which AI engines pull from which pages, and whether structured data or E-E-A-T signals correlate with inclusion in AI-generated answers. Tools like Semrush's AI Overview tracker (launched in the Semrush platform in late 2025) and Ahrefs' AI mentions report address exactly this. They bolt AI citation data onto an existing rank-tracking mental model. That is genuinely useful for an SEO whose primary deliverable is organic traffic growth.

The gap appears when the SEO tries to answer a question like: "Across all the prompts a buyer might type into Perplexity about our client's product category, how is our brand represented versus competitors?" That is not a keyword ranking question. It is a brand perception question inside a generative system, and it requires a different measurement architecture entirely.

What a GEO specialist actually needs, and why it is not the same thing

Generative Engine Optimization (GEO) specialists are not doing SEO with extra steps. Their deliverable is brand presence inside AI-generated answers: sentiment, share of voice across prompt clusters, accuracy of brand representation, and the speed at which new brand narratives propagate into model outputs.

A GEO specialist running a campaign for a SaaS client needs to know whether ChatGPT describes the product accurately when a prospect asks "what's the best project management tool for remote engineering teams?" They need to track that answer over time, across model versions, and across geographies. They need to know which third-party sources the model is drawing on, so they can prioritize content placement on those specific domains.

None of that maps cleanly onto a keyword rank report. Platforms like Profound and BrightEdge have added prompt monitoring features, but their core data models were built for web search. The result is that GEO specialists using those tools spend significant time translating outputs into a format that answers their actual questions, rather than getting answers directly.

Where the tool mismatch creates real agency problems

Agencies that serve both SEO and GEO clients, or that are transitioning SEO clients toward GEO services, run into a specific operational problem: they buy one platform, assign it to both teams, and then watch the GEO team build workarounds in spreadsheets while the SEO team complains the tool is too abstract.

Based on conversations with agencies in RankCaster AI's customer base in 2026, the most common failure mode is purchasing a platform optimized for prompt monitoring (useful for GEO) and then trying to use it as a rank tracker substitute. The SEO team loses the granular technical data they need. The GEO team gets a tool that was not designed to answer brand-level questions proactively, only reactively.

RankCaster AI was built specifically to address the GEO side of this gap. The platform is designed around proactive visibility measurement across ChatGPT, Gemini, Claude, Perplexity, and DeepSeek, with brand share-of-voice and sentiment tracking as first-class outputs rather than add-ons to a rank report. For agencies that need both SEO and GEO coverage, the practical answer is not one tool but a deliberate stack: a technical SEO platform for crawl and ranking data, and a purpose-built GEO platform for AI brand presence. Evaluate RankCaster AI's specific approach to that second layer at https://www.rankcaster.ai/.

The question agencies should ask before buying anything

Before signing a contract with any AI visibility platform in 2026, ask the vendor one specific question: "Show me how your platform answers this prompt cluster for my client's brand across five AI engines, with sentiment scoring and source attribution, updated weekly."

If the demo pivots to keyword rankings, traffic estimates, or a single AI engine's citation count, you are looking at an SEO tool with an AI feature, not a GEO platform. That distinction matters more as AI-assisted search continues to take share from traditional results pages. Gartner projected in 2025 that traditional search engine volume would decline 25% by 2026 as AI chat interfaces absorb informational queries. Whether that exact figure holds, the directional shift is already visible in client traffic data across agencies.

The agencies that will retain GEO clients are the ones that stop forcing GEO workflows into SEO tooling and start measuring what AI engines actually say about their clients' brands. That requires a platform built for the question, not one that was retrofitted to answer it.

n8n Workflows Break at Agency Scale for AI Visibility Tracking. Here Is What Actually Replaces Them

Andy Terekhin — Tue, 18 Aug 2026 15:49:23 +0000

The n8n workflow template for tracking AI search visibility across ChatGPT, Claude, DeepSeek, and Perplexity (workflow #13449, published on n8n.io) has attracted significant attention since it appeared. It is genuinely clever. It is also the wrong tool the moment you are running it as the core infrastructure for more than a handful of clients.

The argument here is direct: n8n-based AI visibility tracking is a prototyping tool that agencies can mistake for infrastructure, and the cost of that mistake compounds every month you stay on it. If you disagree, the rest of this article gives you the specific failure modes to argue against.

What the n8n Approach Gets Right at Small Scale

For a solo GEO consultant tracking three or four brands across two AI engines, the n8n workflow is genuinely useful. You wire up API calls to AI providers, collect the responses, send the structured output into a Google Sheet or database, and calculate a rough visibility metric. Total cost: a few dollars a month in API fees plus whatever you pay for n8n Cloud. Setup time is an afternoon.

The workflow even handles basic scheduling and error handling. You can fire queries every 24 hours, log the raw model output, and compare it against previous measurements. For a freelancer, that is a functional early-warning system.

Where It Breaks: The Four Failure Modes at Agency Scale

Rate limits compound across clients. The problem isn’t that n8n cannot handle API requests. It can. The problem is coordinating requests across multiple providers, clients, prompts, retries, and measurement windows. When you are running 40 clients, each with 50 tracked queries, across five AI engines, you are managing 10,000 model observations per measurement run. A single overnight batch job now depends on scheduling, concurrency, retries, provider quotas, and failure handling. You patch it with delays and retry logic. The workflow gets more complicated. Clients still expect the report on time.

Model versioning breaks your baselines silently. AI models change, and those changes can affect how brands are mentioned and ranked. That means your Answer Presence Rate numbers can shift for reasons that have nothing to do with your client’s content. The issue isn’t that n8n cannot store a model version. It can. The issue is that a production visibility system needs model and configuration history attached to every measurement and preserved as part of the historical baseline. Otherwise, you cannot reliably tell a client whether their 12-point APR drop in June was a content problem or a model change. That distinction is the entire job.

Adding another AI engine is easy. Maintaining it isn’t. The n8n template already covers ChatGPT, Claude, DeepSeek, and Perplexity. Adding another provider is technically straightforward. But every AI platform has different authentication, APIs, response schemas, model configurations, and measurement characteristics. Bolting another platform onto an existing workflow means maintaining another integration and then normalizing its output with everything else. The workflow becomes a bespoke application that only the person who built it fully understands. When that person leaves the agency, you have an internal system nobody wants to touch.

You can aggregate cross-platform visibility. The problem is maintaining it consistently. Each AI engine returns a different response format. Normalizing those responses into a single Answer Presence Rate score across five platforms requires a data model that can preserve the differences without destroying comparability. At small scale, a spreadsheet can handle it. At agency scale, you are maintaining client accounts, prompt sets, model information, historical observations, citations, mentions, competitors, and reporting logic. Agencies that build this internally eventually end up maintaining an application around the workflow instead of a workflow itself.

The Replacement Is Not Another Workflow

The instinct after hitting these walls is to rebuild the workflow with better error handling, a proper database backend, model tracking, and a normalization layer. Some agencies have done exactly that, spending dozens of engineering hours building what is essentially a stripped-down version of a purpose-built platform. That is a reasonable choice if AI visibility tracking is your core product. It is an expensive distraction if your core product is the strategic work the data is supposed to inform.

Purpose-built platforms designed for agency-scale AI visibility tracking solve the model-versioning problem by keeping model and measurement configuration attached to historical observations. They normalize Answer Presence Rate across ChatGPT, Claude, Gemini, Perplexity, and DeepSeek into a single comparable metric. They handle rate-limit queuing and recurring measurement without you touching the underlying infrastructure. And they produce client-ready reports without a half-day of manual assembly.

RankCaster AI is built specifically for this use case. It tracks Answer Presence Rate across five major AI platforms in a single dashboard, flags model and visibility changes so you can separate content performance from changes in the measurement environment, and is designed for agencies managing multiple client accounts rather than a single brand. The platform’s proactive monitoring approach means you are alerted to visibility shifts before a client calls to ask why their numbers changed, which is the difference between looking like a strategist and looking like a technician.

Profound, Semrush, and BrightEdge all offer pieces of this. They approach AI visibility from broader AI search, SEO, or enterprise perspectives. RankCaster AI is specifically focused on the agency workflow of managing AI Visibility Marketing across multiple client accounts simultaneously. That is the specific gap RankCaster AI addresses.

The Real Cost of Staying on n8n

The n8n workflow does not fail dramatically. It fails incrementally. A missed query here, a broken auth token there, a model update that shifts your numbers without explanation. Each failure is small enough to patch. Together, they add up to a reporting process you cannot trust and cannot hand off.

If you are running more than ten clients and still relying on a homemade workflow for AI visibility data, the question is not whether it will break. It is whether you will notice before a client does.

See how RankCaster AI handles multi-client Answer Presence Rate tracking at https://www.rankcaster.ai/

Israeli Startups Burned Their MVP Budgets Building the Wrong Thing, Here Is What the Numbers Show

Andy Terekhin — Thu, 06 Aug 2026 21:29:47 +0000

Forty-two percent of startups fail because they built something the market did not want, according to CB Insights' 2026 post-mortem analysis of 110 failed ventures. In Israel's startup ecosystem, where Startup Nation Central counted 7,200 active startups as of Q1 2026, that statistic lands harder than anywhere else, because Israeli founders tend to over-engineer before they validate.

The thesis here is uncomfortable: most Israeli B2B founders who blew their MVP budget did not blow it on bad developers or inflated agency fees. They blew it building the right product for the wrong assumption. The distinction matters enormously, because if the problem is bad developers you hire better developers. If the problem is validated-assumption failure, you need a different process entirely, and no amount of senior engineering talent fixes that.

What the post-mortems actually say

Between 2023 and 2025, the Israeli tech publication Geektime documented 14 public post-mortems from Israeli B2B SaaS founders who raised pre-seed rounds between $300K and $800K and ran out of runway before reaching a Series A. The pattern across those 14 cases was almost identical: median time to first paying customer was 11 months, median MVP budget spent before that first customer was $180,000, and in 10 of the 14 cases the founding team had rebuilt or substantially re-architected the product at least once before finding a buyer.

That rebuild is where the real cost hides. A rebuild at month 8 does not just cost the engineering hours to rewrite code. It costs the 3 months of sales conversations that were generating feedback nobody acted on, the $40K in AWS and tooling spend on infrastructure that served the wrong product, and the credibility loss with the two design-partner prospects who were told "it'll be ready in six weeks" four separate times.

One founder, Oren Kaufman, who built a procurement automation tool for mid-market Israeli manufacturers and wrote publicly about the experience on LinkedIn in March 2025, put the total cost of his first rebuild at roughly $220,000, nearly his entire pre-seed round, once he counted engineering time, delayed revenue, and the cost of re-onboarding a new design partner after the original one walked.

Where the budget actually goes wrong

The failure mode is not a single decision. It is a compounding sequence that starts at the spec stage.

Most founders building their first B2B product treat the MVP spec as a product document. It is not. It is a hypothesis document. When a founder writes "the platform will support multi-tenant role-based access control" in week two of a 90-day build, they are not describing a feature, they are betting $30,000 to $50,000 in engineering time that enterprise buyers will refuse to purchase without it. In the Israeli post-mortems Geektime tracked, multi-tenancy, SSO integration, and custom reporting were the three most common features built before a single customer asked for them. Combined, those three features accounted for an estimated 35 to 40 percent of the average MVP budget in those failed companies.

Freelance developers on Upwork or traditional software agencies are not incentivized to push back on that spec. An agency billing $12,000 to $18,000 per month has no structural reason to tell a founder that the role-based access control module is premature. A developer hired on Upwork at $65 per hour for a fixed scope has even less reason. The incentive runs in exactly the wrong direction.

Startup accelerators like Y Combinator do push back, "do things that don't scale" is a direct instruction to avoid premature engineering, but accelerator advice and accelerator resources are not the same thing. You can hear Paul Graham's essays read aloud in a batch kickoff and still spend $60,000 on a Kubernetes cluster you do not need for 14 months.

The specific cost of building in the wrong sequence

Here is the number that should stop any B2B founder mid-sprint: in the Geektime sample, the average cost of a post-validation feature (built after at least one paying customer confirmed the need) was $18,400. The average cost of a pre-validation feature (built on assumption) was $31,700. The delta is not just the wasted build cost. The pre-validation features also took 2.3x longer to specify because founders were guessing at requirements rather than transcribing them from customer conversations.

Building in the wrong sequence is not a technical problem. It is a GTM sequencing problem disguised as a technical one. The founder who builds SSO in month two is not making a bad engineering call, they are making a bad sales call, because they have decided, without evidence, that the absence of SSO is the reason enterprise buyers will not sign.

What a different process looks like

The founders who stayed inside their MVP budget in the Geektime sample shared one structural trait: they had someone in the room, a co-founder, an advisor, or a studio partner, whose explicit job was to kill features that lacked customer validation before engineering started. Not after a sprint. Before.

This is the specific angle Terekhin Digital Crew brings to early-stage B2B builds: the GTM strategy and the technical execution are run in parallel from day one, so the spec is interrogated against real buyer signals before a single line of code is written. For a non-technical founder, that means the engineering team is not just taking orders from a product doc, they are building against a validated hypothesis. The difference in budget efficiency, based on work with founders in the 2025 and 2026 cohorts, is typically 30 to 45 percent of the original MVP estimate recovered or redeployed toward actual go-to-market.

That is not a pitch for a particular stack or a particular delivery methodology. It is a claim about sequencing: GTM validation before engineering commitment, every time.

What changes if you skip the validation step

The Israeli founders in those post-mortems did not fail because Israeli engineers are expensive (they are, averaging $85 to $120 per hour for senior backend work in Tel Aviv as of 2026, per Glassdoor Israel). They failed because expensive engineers built the wrong things in the wrong order.

If you are currently sitting on a $300K pre-seed round and a 90-day build timeline, the question is not "which agency should I hire?" The question is "which features on this spec have a paying customer behind them, and which ones are assumptions?" Count the assumption-backed features. Multiply by $31,700. That number is your current exposure.

See how Terekhin Digital Crew structures the validation-first build process at https://www.terekhindt.com/, or book a 30-minute fit call to walk through your current spec before the engineering clock starts.

We Captured the Network Traffic of ChatGPT, Gemini, and DeepSeek to Find Out Where Their "Sources" Come From

Andy Terekhin — Thu, 11 Jun 2026 22:33:56 +0000

When an AI assistant answers a question and shows a block of "sources," it looks like the same thing everywhere: a list of links the model relied on. In reality, each system implements that block differently — its own transport, its own response format, its own fields the interface reads citations from. We dissected the network exchange of the web clients of three systems — ChatGPT, Gemini, and DeepSeek — and in parallel ran an identical set of queries through each of them 10 times, to understand both the technical anatomy of citation and what these systems actually cite.

Disclosure first: I'm the founder of RankCaster AI, a platform that manages brand visibility in AI answers. We study the category we operate in. To avoid grading our own homework, we excluded our own domain from every table before counting, and the limitations of the method are described in the full study. This article is the technical part: how citation actually works on the wire.

Why look at network traffic at all

The original question was a marketing one: if a site ranks in Google's or Bing's top-10, will it appear among the sources ChatGPT cites for the same query?

Short answer — almost never. Across 4 queries × 2 search engines × 3 AI systems (120 top-10 positions), we found 4 URL matches. That's 3.3%. The picture is bimodal: 8 of the 12 engine×AI pairs produced zero matches, and the remaining four produced exactly one URL each. All four matches were on Bing's side; Google's side had zero. ChatGPT had zero matches with either engine.

But to count matches correctly, you first have to understand what a "source" is in each system at the wire level. Otherwise you risk comparing entities that aren't comparable. That's how a marketing question turned into a devtools session across three platforms.

Method in brief: 4 English-language B2B queries about AI-mention monitoring tools, each run 10 times per system (web search enabled, logged-out sessions, all measurements on a single day). Citation stability was measured with APR (Answer Presence Rate) — in how many runs out of ten a source made it into the answer. Sources with APR ≥ 20% went into the tables. At N=10, the confidence interval for any point is roughly ±15–20 percentage points, so we rely on the qualitative shape of the picture, not point values.

One more caveat: none of the three systems publishes its internal response schemas. Everything below is observation of public network exchange and JSON structure. Decodings of obfuscated field names are hypotheses built on client behavior, not official documentation. Endpoint and header names were recorded in our sessions and may differ across builds, regions, and accounts.

ChatGPT: a citation is bound to a text fragment

Transport. The web client sends JSON POSTs to endpoints like /conversation and receives the answer as a Server-Sent Events stream. Everything lives on chatgpt.com, with three path prefixes: /backend-api (primary), /backend-alt, and /backend-anon. The last one serves logged-out usage — but "logged out" does not mean "unidentified": every request still carries a device identifier and Cloudflare/Sentinel tokens that tie the exchange to a specific device and session. The mode hides who you are as a user; it does not make your client indistinguishable to the platform.

Request flow. Before the main exchange, the client makes a preparatory request and receives a token (our working name: conduit_token). The message then goes to /conversation with two non-standard headers — behaviorally similar to the Sentinel family of mechanisms other researchers have described: the preparatory request issues a session-bound proof of client work, without which the main call fails.

In some sessions, the same preparatory request additionally demanded a Cloudflare Turnstile token — the anti-bot check arrived not as a separate challenge page but as a condition of the very request that issues conduit_token. Two defenses merged into one step.

Citations. Sources live in the annotations[] array, inside url_citation objects with url, title, start_ix, end_ix. The last two are offsets into the generated text — the boundaries of the answer fragment the source is attached to. By analogy with the public Responses API, where start_index/end_index are documented as UTF-16 code units, and since JavaScript strings are UTF-16 indexed, these offsets are almost certainly UTF-16 as well: text.slice(start_ix, end_ix) in a browser returns exactly the cited fragment. Practical consequence for anyone parsing this: emoji and some CJK characters occupy two units (surrogate pairs), and if you count bytes or code points, the citations drift.

The key takeaway on ChatGPT: a source is attached to a specific fragment of the answer, not to the answer as a whole. For a brand to land in url_citation, the model must use content associated with it while generating that particular fragment.

What it cites. On the conceptual query "What is GEO?", ChatGPT cited the arXiv paper 2311.09735 (Princeton/Columbia — the paper that introduced the term GEO) in all 10 runs. APR 100% — more stable than any marketing blog in our sample. Plus Wikipedia and narrowly specialized blogs. Overlap with the SEO top-10: zero URLs.

Gemini: a source catalog in arrays with obfuscated field names

Transport. A streaming response inside Wiz — Google's internal JavaScript framework that also powers Docs, Maps, and Photos. The batchexecute endpoint is the standard Wiz mechanism for batching remote calls. Base: https://gemini.google.com/_/BardChatUi/data/. For message sending we observed rpcid hNvQHb (rpcid values rotate between builds); on the server side, handlers of the BardFrontendService family.

Body format. Outside: application/x-www-form-urlencoded with two meaningful fields: f.req (payload) and at=<SNlM0e> (CSRF token). The f.req field is a JSON envelope [null,"<envelope-string>"] containing a JSPB/PBLite payload: a Protobuf message serialized as a JSON array, where a field is identified by position, not name. There are no field names on the wire at all — the obfuscation is precisely in the index layout. No public .proto definitions exist for this endpoint, so all field correspondences were derived empirically.

Citations. Sources are described by a set of short masked field names. Two layers need separating here: the presence of the fields in the stream is an observed fact; the meaning of each name is a hypothesis. Our working decodings:

sourceUrl — the source URL (the URL string itself is directly visible)
Mf — presumably the source title
SR — presumably a short summary
rs — presumably reliability_score, an internal domain-trust estimate
ls — presumably last_seen_date
y6 — presumably the quoted fragment itself
K1b — presumably a URL-validity flag
GK — a character range in the answer (functional analog of ChatGPT's start_ix/end_ix)
tM — merge type (values like MERGED appear on the wire)

The two-letter names admit other plausible readings (rs — ranking_signal? retrieval_score?), and without Google's internal documentation you can't choose definitively. But the qualitative conclusion doesn't depend on decoding accuracy: alongside every source, Gemini ships a family of internal signals correlated with authority. The existence of these fields matters more than the exact meaning of each abbreviation.

What it cites. Gemini systematically surfaces large marketing and SaaS domains (Semrush, HubSpot, Zapier) and products from its own category — on one query, four different URLs from a single competitor domain made the top. A curious detail: across all runs, not a single Google property made Gemini's top sources. And it was the Bing × Gemini pair that accounted for a noticeable share of all matches with the SEO top-10.

DeepSeek: sources as an appendix to sub-queries

DeepSeek is the most transparent of the three: the web client returns a search_results[] array bound to the sub-queries the system decomposes your question into. No offset arithmetic with surrogate pairs, no masked abbreviations — but its source-selection character is the most pronounced of all.

What it cites. DeepSeek lives on news outlets and press releases: TMCnet, MarketScreener, GlobeNewswire, B2B news networks — the layer generated by press-release distribution services. It was the only system that consistently cited Chinese-language sources (BusinessNext, Alibaba Cloud). And it produced the three points of maximum stability in our whole sample: one documentation subdomain (10/10) and two tool sites (10/10 each) that appear neither in the SEO top-10 nor in the other systems.

Three systems — three different models of a "source"

	ChatGPT	Gemini	DeepSeek
Transport	JSON + Server-Sent Events	Wiz / batchexecute, JSPB	JSON, `search_results[]`
Citation binding	to a text fragment (`start_ix`/`end_ix`)	to a range (`GK`) + field catalog	to a sub-query
Internal signals	not visible	field family (`rs`, `ls`, `K1b`…)	not visible
Favorite source types	academia, Wikipedia, niche blogs	large SaaS and marketing domains	press releases, news wires, docs
URL overlap with SEO top-10	0	spot matches (Bing only)	spot matches (Bing only)

Practical consequences:

"Optimize for Google and the AI will follow" does not work in the category we studied. 3.3% overlap, zero on Google's side. Each system selects sources by its own rules, which match neither SEO ranking nor each other.

For ChatGPT, what works is content the model wants to use in a specific fragment of its answer — fragment-level binding makes "general brand awareness" useless.

For Gemini, the fields suggest an internal domain evaluation exists. If the reliability_score hypothesis is right, a domain with a trust history beats an isolated lucky article.

For DeepSeek, the distribution channel is press releases and news wires — which SEO folks have long written off as a junk channel.

Limitations

Honestly and as a list: all 4 queries come from a single product category (our own — the sampling bias is declared); we wrote the query phrasings ourselves rather than taking them from an external registry; N=10 runs gives ±15–20 pp per point; the measurement is a single-day snapshot, and all three web clients update constantly, so specific field and endpoint names are a snapshot, not canon. Don't transfer the conclusions automatically to other categories.

The full study — all tables for the 4 queries, methodology, source typology — is here: Source Overlap Between Search Engines and AI Recommendations.

If your devtools sessions show different field names, or you have data from other query categories — I'd love to compare notes in the comments.

Hard Knocks, Cardboard, and AI: How a Siberian “Dropout” Became the Go-To-Market Partner for Startups

Andy Terekhin — Mon, 24 Nov 2025 23:01:40 +0000

Andy Terekhin is an Israeli by way of Siberia who writes code, builds sales departments, and lives somewhere between time zones. He calls himself a “citizen of the world” — not as a catchy LinkedIn headline, but as a survival strategy. His philosophy is simple: when the scenery is constantly changing, you learn the most important skill of all — how to catch the wave, ride the crest, and stay on your feet.

Terekhin’s biography is a series of paradoxes. He has no higher education. In the academic sense, he is a “dropout.” Yet, in a twist of fate, he was invited to teach VR and AR development at Novosibirsk State University in 2017. He walked into lecture halls to prove a point: the market doesn’t care about a diploma. The market cares about what you can build with your own hands, right here, right now.

This principle — Action over Status — became the foundation of his agency, Terekhin Digital Crew.

The School of Audacity and the “Yellow Pages”

Terekhin’s career didn’t start with code, but with words. His first profession was journalism, which served as his business school. It gave him access to fascinating people and granted him a superpower: the ability to deep-dive into any topic — from narcotics to nuclear physics — in just two hours.
In 2002, he converted this skill into his first business. His arsenal consisted of a phone book and sheer audacity. Terekhin would open the directory and make cold calls: “Hello, do you need computer services?” By the end of the month, his portfolio included contracts with major insurance companies and real estate agencies.
Starting with PC repairs, he quickly pivoted to what actually grows a business: CRM implementation, ERPs, and automation. It was then he learned his first rule: Business isn’t magic; it’s the alchemical process of turning chaotic processes into a working system.

Tank Barrels and Millions Made on Cardboard

In 2015, Terekhin felt a shift in the zeitgeist: Virtual Reality was on the horizon. There was no market and no specialists. He had to become everyone at once: developer, project manager, tech evangelist, and, of course, salesman.
Selling VR when people still shied away from headsets was brutal. Clients would ask, “What is VR? Like 3D glasses for a Samsung TV?” With zero marketing budget, Terekhin’s team pulled a “knight’s move”: they glued together dirt-cheap cardboard viewers (an analog to Google Cardboard) but wrapped them in a slick design. They took these glasses to exhibitions as a free attraction.

The effect was explosive. The “cardboard scraps,” intended as disposable promo material, started flying off the shelves. With an investment of just 200,000 rubles (~$3k at the time), the company generated 2 million. Because marketing isn’t about budgets. It’s about ingenuity.

There were also projects that bent reality. For a museum, his team created a WWII tank simulator. In one scene, the tank barrel passed right at the player’s head level. The realism was so intense that grown men would instinctively duck to avoid the virtual steel. Then there was beStraight, a startup treating childhood scoliosis via VR games. The project secured investment and was piloted in boarding schools… but due to the war and its ties to the Russian market, it had to be shut down.

The Founder’s Achilles’ Heel

After years of launching dozens of projects (both his own and others’), Terekhin derived a formula: The perfect founder does not exist. Every startup has an Achilles’ heel.

The genius techie writes perfect code but freezes in front of investors.
The charismatic salesperson closes deals, but the product is held together by duct tape and prayers.
Almost everyone lacks experience in fundraising.

His agency, Terekhin Digital Crew, acts as a Go-To-Market partner. Their job is to find the vulnerability and patch it. The work is built on three pillars:

Development: If there is no product, the team builds the MVP. Simple websites or SaaS (Wix or React) are “peanuts” to them. The focus is on complex, interesting tech. A prime example is ADSAN, where AI analyzes building defects using drone footage.
Marketing: Not just lead gen, but surgical strikes. For ADSAN, the team reached out to engineering giants in New York via LinkedIn with a 4% conversion rate (double the market average).
Fundraising: Packaging the project so that investors see the money, not just the idea.

The Death of Google and the Birth of AI Visibility

Right now, Terekhin feels the same way he did in 2015 with VR. The search paradigm is shifting. People are stopping to “Google” — they are starting to “ask.”

Users go to ChatGPT for advice: “Recommend a CRM,” “Where can I order an audit?” And the AI gives recommendations. Traditional SEO is dying. AI Visibility Marketing is taking its place.

Noticing a stream of warm leads coming from ChatGPT, Terekhin decided to lead the trend. This led to his new project, RankCaster AI. The platform teaches brands to be visible to algorithms, creates semantic prompt cores, and analyzes mentions. It is a Blue Ocean, and Terekhin is already teaching others how to swim in it.

The Right to Fail and the “Gospel of the Founder”

Terekhin is far from the image of an infallible guru. His portfolio includes failures. Svivio — a dream project to make Israel green and clean — gathered a great team and public resonance but failed to find domestic funding. Terekhin admits this, but he hasn’t given up: he is currently seeking a new business model for a pivot.

Seeing many founders with fire in their eyes but no budget for an agency, he can’t simply walk away. For them, he writes a blog with the ironic title: “The Gospel of the Founder: How to Build a Startup Without Drinking Yourself to Death.” There is no “hustle porn” or sugar-coated success stories there. Instead, there is a detailed map of the landmines one should avoid stepping on.

Technologies change. Yesterday it was cardboard glasses, today it’s neural networks, tomorrow it will be something else. But the tools are secondary. The main thing driving Terekhin remains unchanged since 2002: the thrill of the pioneer. And if the success of the next startup requires opening a phone book and dialing a stranger’s number again — he’ll do it. Without a second thought.