--- title: "Build it or buy it | Snowplow Signals" description: "Before you staff a real-time profile service, run the alternative on your own traffic. Free tier, no card, an attribute updating in your first session." source: https://signals.snowplow.io/lp/build-vs-buy --- Build vs buy # You can build it. Then you own it forever. Signals computes live attributes from what your customer is doing and serves them to your app in 6ms. Run it on your own traffic this afternoon, before anyone writes the staffing plan. * **6ms** p50 read, in-region * **0** streaming jobs you run * **Free** tier, no card ## Start free 5M events a month · unlimited attributes · no card Work email Continue A work address, please. We cannot provision on a personal domain. Or [talk to an engineer](https://signals.snowplow.io/start?intent=engineer&lp=build-vs-buy). [ Try it on yourself ↓ ](#live-panel) Below is your own visit to this page, computed by Signals as you read. ### Signals, about you connecting See live events firing as you browse this page on the left; what Signals computed about you on the right, refreshed every few seconds. Implement this this page · events 0 writes Product Solutions Developers Pricing Start free Start free Engineer this panel the rest of the page nothing sent yet write attribute store · your session no read yet reading\_now pages\_last\_5\_min seconds\_since\_last\_action sections\_read seconds\_engaged pricing\_views menus\_explored features\_wanted cta\_clicks arrived\_from waiting for the first computed value… Your first events are in flight through a real Snowplow pipeline. Attributes appear as the stream computes them, usually within a few seconds. hand it to your agent one prompt Add the Signals MCP server to Claude Code, Cursor or any MCP client, then run this. The agent adds the SDK, defines the attribute and wires the read into your own app. $ npx plugins add snowplow/skills > Use the Snowplow MCP server and Signals skill, then help me plan and implement a use case. Make sure everything is tested and works as intended. Copy the prompt[How to connect the MCP server](https://docs.snowplow.io/docs/llms-support/snowplow-mcp/) or write it yourself three steps 01 Track the event once, in your app trackPageView(); // browser tracker, already on this page 02 Define the attribute once, in Signals Attribute(name="pages_last_5_min", events=["page_view"], aggregation="category_count", property="page_urlpath", period=timedelta(minutes=5)) 03 Read it back every request await signals.getServiceAttributes({ name: "signals_site_session_service", attribute_key: "domain_sessionid", identifier: "…", // your session id, once set }); What the build actually contains ## Almost none of the work is the attribute logic. Before ### Ingestion, state, serving Collector, schema registry, failed events, windowing, watermarks, late arrivals, hot keys, checkpointing, a low-latency API, auth, TTLs, versioning. Most of them discovered in production. `still upstream of the feature` With Signals ### You own the definitions The engine handles windowing, late events, hot keys and backfills. What your team writes is what you want to know about a customer, and the code that reads it. `define it, then read it` Result ### The roadmap gets its engineers back The people who would have maintained a profile API go back to the ranking, the experience and the product a customer actually notices. `on-call, ours` Why the second year is the cost ## The build has a launch date. It does not have an end date. A build plan is a staffing plan. Price it that way and the comparison stops being a license fee against a sprint estimate. ### Two implementations that drift The streaming logic and the batch logic have to agree forever. When they stop agreeing the model degrades quietly, and nothing pages anyone. ### On-call for plumbing no customer sees Hot keys at peak, a bad deploy, the state rebuild after it. The rota is permanent and the work is invisible to everyone reading the roadmap. `pages per quarter · engineer retention` ### Every new attribute is a ticket When a PM has to queue behind data engineering for each new definition, personalization stays next quarter for three quarters running. `attributes shipped per quarter` ### Your agent writes it, your team runs it A coding agent can produce the first streaming job in an afternoon. It cannot hold the state model, rebuild after a bad deploy or take the page at peak. Point it at Signals instead and the afternoon ends with nothing new to own. How it works ## The parts you would have built, already running. Managed SaaS or a private deployment in your own AWS or GCP account, on identical architecture, so what you evaluate is what you run. 1. 01 **Collect.** Add a Snowplow SDK to your application and behavioral events start flowing in, schema-validated on the way. 2. 02 **Define.** Say what you want to know about the customer, in the console or in code, versioned through CI/CD like the rest of your stack. 3. 03 **Serve.** Your app reads it at 6ms p50, on every request, and the on-call rota is ours. Signals → your app 6ms p50 sessions\_last\_7d 4 categories\_viewed\_10m 3 seconds\_on\_product\_page 47 basket\_value 184.00 high\_value\_basket\_idle true Trigger basket\_idle\_10m delivered to your app Questions ## The questions your architect will ask ### How do we justify this internally? Compare it against a staffing plan, not against a license fee. The build cost is mostly people, it does not end at launch, and the engineers it needs are the ones already assigned to product work. ### Are we locked in? Events are yours and land in your warehouse. Definitions are portable. Leaving costs you the engine, not the data. ### Can we run it in our own cloud? Managed SaaS, or a private deployment in your own AWS or GCP account. Identical architecture either way, so what you evaluate is what you run. ### What if our attribute logic is unusual? Custom functions are supported and versioned like the rest. Counts, recency and ordering cover most of what teams build by hand. ### Do I need an event stream already? No. Collection is part of Signals, which is the half of the build that usually takes the longest. Add a Snowplow SDK and events start flowing in, validated against your schemas on the way. ### What does the free tier include? The full product against your own traffic, up to 5 million events a month, with no card and no sales call. You should see an attribute updating against your own traffic in the first session. ## Try the alternative before you staff the build. Add the SDK, define one attribute, then click around your own product and watch it change. That is the whole thing, on your own traffic, this afternoon. [Start free](https://signals.snowplow.io/start?lp=build-vs-buy) [Talk to an engineer](https://signals.snowplow.io/start?intent=engineer&lp=build-vs-buy) The real engine · no card · no sales call Or hand it to your coding agent $ `npx plugins add snowplow/skills` Copy Copied Then: Let's add Snowplow Signals to this app. Understand the app first, then define an attribute for basket hesitation and read it back before the ranking runs.