You can build this. The question is what it costs to keep.
Kafka, Flink and Redis will get you a live attribute. The expensive part is the year after launch: windowing edge cases, hot keys, late events, schema drift, and the on-call rota that comes with all of it.
The same capability, two cost structures.
| Dimension | Signals | Build it in-house |
|---|---|---|
| Time to first attribute in production | Days. SDK in, definition written, read from your app. | One to two quarters, once ingestion, state and serving are real. |
| What the team owns | Definitions, and the code that reads them. | Collectors, schema registry, stream jobs, state store, serving API. All of it. |
| Hard parts you inherit | Handled in the engine: windowing, late events, hot keys, backfills. | Each one a sprint, usually discovered in production. |
| Training and serving parity | One definition serves live and builds the labelled training set over history. | Two implementations that drift. A standing source of silent model error. |
| On-call | Ours, with a status page. | Yours, at peak, on a Friday. |
| Ongoing cost | Usage-based. Scales with events and reads. | Two to four engineers, indefinitely, plus cloud spend. |
| What you keep if you leave | Your events and your definitions. Both are portable. | Everything, including the maintenance. |
Build estimates are illustrative, drawn from comparable in-house streaming projects · replace with your own planning figures before any external use
The roadmap has product work on it that this project would displace.
Nobody on the team wants to own a stateful streaming service at peak.
You need training and serving definitions to agree, permanently.
The value is in the attributes, not in the pipeline that computes them.
Real-time attribute serving is itself your differentiator.
You already run the streaming stack, staffed, with capacity to spare.
Requirements are unusual enough that no vendor model fits.
Regulatory constraints rule out the deployment options on offer.
Three phases of work that are not the feature you wanted.
Ingestion and trust
Collector, schema registry, validation, failed-event handling. Without it every attribute downstream is suspect.
Stateful computation
Windowing, watermarks, late arrivals, hot-key skew, checkpointing, and the rebuilds after a bad deploy.
Serving and lifecycle
A low-latency API, TTLs, versioning, staleness signalling, and a second batch implementation for history.
Typical steady-state team for a build, after launch
Illustrative time to a production-grade build
Streaming and batch logic to keep in agreement
To the same first attribute on Signals
The questions your architect will ask.
Are we locked in?
Events are yours and land in your warehouse. Definitions are declarative and portable. Leaving costs you the engine, not the data.
Can we run it in our own cloud?
Deployment options vary by plan. Raise it early in the evaluation so the answer is concrete.
What if our attribute logic is unusual?
Custom functions are supported and versioned like the rest. Counts, recency and ordering cover the common cases.
How do we justify this internally?
Compare against a staffing plan, not a licence fee. The build cost is mostly people, and it does not end at launch.
Test the claim on your own events.
Define one attribute, read it from your product, and compare the latency to whatever you run today. 14 days, no card, no sales call.
Also in Evaluate: Signals vs a feature store, Signals vs a CDP, and pricing →