I have shown Naftiko Signals to dozens of people in the last two months. Executives, advisors, would-be design partners, prospective investors. The reaction has been remarkably consistent.
The first beat is, wow, this is impressive.
The second beat is, what do I do with this?
If you only hear the first beat you will think you have a hit on your hands. If you actually listen to the second beat, you realize you have a demo. And a demo without a clear next action is what kills early-stage startup sales conversations every single time.
An advisor of mine — sharp, blunt, and someone who has spent years working with C-level CIOs and CTOs — gave me the version of this feedback I needed to hear. She said: I could see what I could see. But I did not know what my action was. Not because there was too much data. Because the bridge from “these are the signals” to “what does that mean for me” was not there.
That is the post. The bridge. Why it was missing. What we have built in the last week to start closing it. And the honest version of what is still on the build list.
What the signals actually are
Quick reset for anyone new. Naftiko Signals is an external read of a company’s tech footprint, built entirely from public sources — job postings, press releases, vendor case studies, integration directories, public APIs, open-source contributions, regulatory filings. We score 44 signal categories per company, plot every detection on a maturity radar, and roll the signals up at company, industry, role, and regional levels.
The output is rich. Possibly too rich for the first conversation. When an operator lands on a company profile, they get a coverage score, a 44-category radar, a list of detected services and tools across AI / cloud / data / integration / governance / operations, and an industry-aware contextualization of all of it.
For a competitor analyst, that view is exactly the right amount of data. For a CIO trying to figure out what to do tomorrow morning, it is too much without a clear thread to pull.
That is the bridge problem. And the bridge problem is not solved by adding more data. It is solved by attaching specific actions to specific signals for specific roles.
What was wrong with the previous version
For most of Q1 the Signals product was data-rich and action-light. The page would show you everything we knew about a company. The implicit invitation was here is the data, you decide what to do with it. That works if you are an industry analyst. It does not work if you are a buyer trying to figure out whether what you are looking at is supposed to scare you, energize you, or convince you to call procurement.
The honest answer for why it took us this long is that the bridge is the harder problem. The data layer — running the crawlers, scoring the signals, computing the maturity rollups, normalizing across sources — is engineering work. It is bounded. The action layer is role-by-role product design. It is the part where you have to know who the operator is, what their job actually looks like on Tuesday afternoon, and what a meaningful “do this” recommendation looks like for them specifically.
That is the work of the last month, and the part that is still being built.
What changed in the last week
Three things shipped in the last week that move the bridge forward.
Role-aware page composition. Every Signals page now reads a role hint from the URL — typically passed through a utm_campaign parameter, but you can land directly on a per-role view too. A Chief AI Officer landing on an enterprise profile sees a different framing than a Chief Information Officer landing on the same page. Same data underneath; different recommendation thread on top. The CIO sees governance and integration first. The CAIO sees agent-readiness and capability gaps first. The Chief Data Officer sees data-platform investment patterns first. Each one gets a “what does this mean for me” answer that matches the role they actually hold.
Agent-native consumption. Every company and industry Signals page now exposes the same data as a unified MCP server, plus dedicated launch buttons for Claude, ChatGPT, and Gemini. An operator who does not want to read a page can hand the company’s MCP server to their copilot of choice and have a conversation about the signals instead. That changes the bridge problem from “interpret the dashboard” to “ask the assistant the question.” The assistant can ground its answers in the same data the page is showing — but in the operator’s voice, in the operator’s terms.
Sandbox capabilities you can actually run. For the services that show up in a company’s signals, we are starting to ship runnable capability sandboxes — packaged Naftiko capabilities you can deploy in your own infrastructure (Cloudflare Containers, Render, Cloud Run, Railway, or Replit, with shipyard-cloudflare doing the heavy lifting on the deploy story). The capability points at a mocked-out version of the service, not the live data. But you can put it in front of your own agent today and see what an agent-reachable capability surface for that service actually looks like inside your own runtime. That is the closest thing to a “tactical next step” the bridge can offer right now.
Together, those three additions answer three different versions of the what do I do with this question. Show me what is in it for my role. Let me ask my assistant about it. Let me try running a capability against my own stack.
It is not the complete bridge. But it is a real bridge for the first time.
What is still on the build list
I will name what is still missing, because the alternative is letting it sound finished when it is not.
Per-capability cost estimates. A CIO looking at the signals for an enterprise sees that the company runs an HR platform, a CRM, a data warehouse, and a half-dozen other services in production. The implicit follow-up question is what does it cost me to make any one of those agent-reachable? We can answer that in conversation. We cannot yet show it on the page. That is the most-requested missing piece, and it is next on the build list.
Cross-company rollups for buyers selling INTO the enterprise. Right now Signals is built for the operator inside the company. The advisor on my call last week pushed me toward a parallel view for the vendor selling INTO the enterprise. A salesperson at, say, a data-pipeline company would want a view that says here are the twelve regulated-finance enterprises whose data-platform signals indicate they are likely to be evaluating a vendor like you in the next two quarters. That is a different page than the company profile, and it is a real adjacent product. Worth building.
Procurement-grade artifacts. A buyer who decides to act on Signals eventually has to bring it to their procurement team. That conversation requires a different document shape — vendor evaluation matrices, license-cost projections, risk surface descriptions — than the executive-facing page does. We have started on a few of these but they are not first-class yet.
The bridge has a few more planks to add. That is normal. The point is that the direction is now correct: every quarter forward should make the next action clearer, not the dataset deeper.
The honest version
The most useful thing I can do as a founder right now is not to defend the product I shipped. It is to listen to the second beat — the what do I do with this — and treat the answer as the actual product roadmap.
Naftiko Signals had a strong “wow” for a long time before it had a strong “next.” Closing that gap is the only work that matters between now and our first paid pilots. If you are reading this and you have looked at Signals for your own company, your industry, or a company you are selling into — and you walked away with the second beat unanswered — I would like you to tell me. The unanswered version of that second beat is exactly the input that gets us to the version of this product that does not need a long blog post to explain why the bridge is now visible.
You can email me at kinlane@naftiko.io. Bring the question your role still has. That is where the next plank gets built.
