The SaaSpocalypse is upon us, and anyone who can drive an AI agent is now forced to think twice about any software they pay for monthly: "could I just build this myself?"
It is a fair question. With Cursor or Claude it is easier than ever to vibe code a website, and even fairly complex software you currently rent. But for a tool like server-side tracking, which does a lot behind the scenes that you cannot see, how close do these setups actually get you?
On first glance it looks like it does the job. An event fires when someone submits a form or clicks a button. The real problems only show up over time, and most people never find them, because they do not know which edge cases to look for.
At PixelFlow we have seen plenty of setups customers built themselves. Many owners believe they are getting exactly what a commercial platform gives them. There are a number of places where that falls down, especially without deep experience in this specific corner of adtech.
The short version: a vibe coded tracking setup will send events on day one. What it will not do is filter bots, survive an API version being retired, keep deduplication intact when checkout moves to another domain, refresh click IDs before Safari deletes them, respect consent, or leave you a log to check when your ROAS stops making sense. Every one of those fails silently.
1. Bots and fake clicks
Cloudflare now puts automated traffic at around 57% of HTML requests, and bots overtook humans in May 2026. They load your page the way a real customer does, and in some cases trigger real events like adding a product to the cart.
There are all sorts: link previews, ad review crawlers, uptime checks, junk click traffic. Cloudflare blocks a lot of unwanted bots, but it lets plenty of automated traffic through on purpose. Google, Meta's ad review, and link previews are treated as legitimate, because blocking them breaks search and breaks ad review. So you do not want them blocked, but you also do not want them firing conversions, which they will unless you account for them specifically. Knowing which bots are fine and which are not takes a lot of aggregate data.
The harder part is fraudulent clicks. They look like a normal browser on a normal connection, pass the Cloudflare check, and then fire the same page view or lead as a customer. Once that event is sent as a real conversion, Meta's own bot filter will not undo it. Your data gets muddied by fake visitors, and because bot systems keep getting more capable, this is not a one-time fix. It needs constant monitoring and adjustment.
2. API versions and payload changes
Meta turns off old versions of its API roughly two years after each one launches. Version 15 was removed on 20 November 2024. Version 16 was removed on 14 May 2025. If your code is still calling that old address, it no longer works.
Two older Meta products were switched off entirely: offline conversions in May 2025, and messaging events in September 2025. Events that used to go there had to be sent again through the Conversions API, which is a different request and a different setup. Build your own and you would most likely never know your events were being rejected.
Google changed the fields it expects too. In March 2024, for visitors in the UK and Europe, consent mode gained two extra answers: whether Google may use the person's data for ads, and whether it may personalise those ads. A setup that only answered the older consent questions leaves those blank. Enhanced conversions will ignore a customer's email unless the ads-data answer is yes, and unless the Google Ads account has accepted Google's customer data terms. An address only counts if first name, last name, postcode and country are all sent together. A partial address is skipped.
iPhone clicks often do not carry the usual Google click ID. They carry a different one, for app clicks or for web clicks. Code that only saved the original click ID has nothing to send for those visits. The old Universal Analytics address stopped accepting hits in 2024, and its replacement needs a secret key, the visitor ID the browser already created, the time in a much smaller unit, and a session ID. Without those, Google accepts the request and the report still shows nothing.
So what you build today works for a while, then goes out of date and breaks, without you ever being told.
3. Maintenance
You vibe coded your CAPI setup on Next.js. Four weeks later a critical vulnerability drops for that version and needs patching immediately.
Are you even aware of it? Do you update? Does updating break your tracking?
If a security patch does not force the update, time will. Every stack goes out of date eventually. When it does, the platform hosting it stops supporting that version, then blocks new deploys. Your code keeps running, frozen. Nobody can ship a fix, including the fix for whatever Meta or Google changed that month.
Updating is not a case of pressing update, or telling your agent "move to the latest Next.js". New major versions expect code to be written differently, so functions get rewritten and the setup gets restructured. Then every event needs retesting from scratch: deduplication, fbp and fbc, match quality. If you are technical you may be comfortable with that, but it has moved from a single prompt of "just set up my tracking" to something you maintain forever.
4. Deduplication and match quality
Sharing one ID between the browser and the server can look perfect when you build it, and still drift apart later. Deduplication only works if both copies carry exactly the same ID.
The browser creates that ID while the visitor is still on your site. The sale is often confirmed somewhere else: a hosted payment page, a booking tool, a scheduler. That other page does not have the ID unless you stored it with the checkout and read it back when the payment came through. If the original event ID is not read back, the server invents its own, and the ad platform sees two conversions for one customer.
The chain breaks without anyone meaning to. A small change to checkout reorders which request fires first, or leaves the site's own pixel running next to yours, and each one mints a new ID. A test of the happy path still looks clean, because every request succeeds. You only notice when reported sales sit above what the payment tool actually took.
The same hop, from your website to a checkout somewhere else, also drops the details used for matching. The click cookie, the IP address and the browser were captured when the visit started. Move the payment onto another domain and they are no longer there when the conversion fires, which means lower match quality and more expensive ads.
5. Click IDs
When someone clicks a Meta ad, a click ID (the long fbclid string) is added to the URL. Your setup has to capture it, convert it into an _fbc cookie in a strict format, store it, and send it with every server event so Meta can connect the purchase to the ad. That sounds simple. A vibe coded setup gets it wrong in several ways:
Most homemade setups write the cookie once and never touch it again.
The format has to be exact. The timestamp must be in milliseconds, which differs from the timestamp on the event itself, and the rules differ again on every other ad platform.
Safari deletes it. It caps script-written cookies at 7 days, and that drops to 24 hours when the visitor arrives from a known tracking domain with a click ID in the URL, which is exactly what an ad click is.
Some browsers strip it before you ever see it. Safari Private Browsing, Brave, and Firefox in strict mode remove
fbclidfrom the URL on arrival.In-app browsers keep it to themselves.
Checkout often lives on another domain, so the click ID has to be passed across deliberately, or the purchase goes out without it.
None of these failures are obvious. Events still send, Events Manager still looks healthy, and attribution quietly breaks, which makes your ROAS look wrong and wastes spend.
6. Consent and GDPR
Contrary to popular belief, server-side tracking does not exempt you from asking for consent. For visitors in the EU and the UK, advertising cookies and the data that goes with them need an explicit yes before you send anything. A business outside Europe has the same duty for those visitors if it sells to them or tracks them.
Global Privacy Control is the one most people miss. It is an automatic "do not track" signal the browser sends, already built into Brave, Firefox and DuckDuckGo. California, Colorado and Connecticut treat it as an opt-out of sharing data for advertising. A simple vibe coded setup forwards every event without ever looking at consent.
We have seen setups where the owner deliberately loads tracking without consent because it "tracks better". That is a risky attitude, and the downside is not a warning letter. GDPR allows penalties up to 20 million euro or 4% of worldwide turnover, and US state laws add their own. What a smaller advertiser usually gets first is the messy version: a complaint, a regulator or a platform asking exactly what you sent and when, legal fees, the pixel switched off while you rebuild, and ads running with no conversions in the meantime. A homemade setup has no record of who consented, so you cannot answer that request from the log you do not have.
7. More than one ad platform
Server-side tracking for one ad platform is tricky enough. Several is a different game. TikTok, Google Ads and GA4 all need genuinely different setups and cannot be bolted onto a Meta webhook. Each is a new key, a new request, a different payload shape, different event names, different cookies. One timestamp copied from one platform to the next is either rejected or stored centuries from now.
You can vibe code a basic Meta setup in an afternoon. Making it work for two or more platforms is an order of magnitude harder.
What usually happens is that the other platforms wait. TikTok stays on a browser pixel, so iPhones and ad blockers remove product views and add-to-carts with no server copy. Google gets a tag on the site and no server-side sale. Meta is the only channel where you can even try to check that a purchase arrived.
That surfaces as an argument about the ads. Meta looks measured, TikTok looks weak, someone blames the creative or the attribution window. The simpler explanation is that TikTok never received the sale. Proving it needs a log you do not have for Meta, and now there are two sends to compare and only one of them exists.
8. Logs, queues and outages
Want to see what was actually sent to Meta last week? That is a database, not a log file. Most vibe coded setups run on serverless hosting where log files vanish and built-in logs last hours or days. Keeping 30 days means storing every payload and Meta's response, deleting it automatically to stay GDPR-compliant, and making sure a slow database never blocks an event from reaching Meta. That is a second system to build and maintain, and most homemade setups skip it, so when attribution drops there is nothing to check.
And once you are storing that data you own the obligations that come with it. Hashed emails and phone numbers are still personal data, so customer deletion requests are now yours to handle.
Ad platforms also have outages. Meta publishes its own Marketing API status history. If a platform is down, slow, or rate-limiting you, your events are simply lost, because you have no queue and no record that anything was missed. A queue holds the event until the platform accepts it. Without one, every minute of downtime is a hole in your data, and nothing in your reports shows you the hole.
So when is it cheaper to just pay for it?
Building the first version is the easy part. Everything after it is the cost: bot filtering that keeps up with new bots, API versions Meta retires every couple of years, framework updates, deduplication across checkouts on other domains, click IDs that browsers delete or strip, consent rules, logs, deletion requests, outages. None of it is a one-off prompt. It is ongoing maintenance, and most of it fails silently, so you find out when your ROAS stops making sense.
What you are actually paying for
That is what a commercial tool is for. Not the code that sends an event, but everything around it. Each of the eight problems above has an answer that somebody else maintains:
Bot blocking that is on by default. Crawlers, link previewers, uptime monitors and scrapers are recognised and dropped before anything reaches Meta, with nothing to configure, and every blocked request is recorded with the reason so you can see what was filtered. Add your own blocking rules on top: once per session, only with a click ID present, not again inside 30 minutes.
Platform changes handled for you. When Meta or TikTok changes an API version, a payload field or a timestamp format, we update it. Your setup does not change.
No stack to maintain. No framework version to patch, no hosting runtime to migrate, no rewrite when a dependency goes out of date.
Deduplication and match quality that hold up, including when the sale happens on Stripe, Calendly or another domain.
Click IDs captured, refreshed and formatted correctly, set in a way that survives Safari's cookie limits, and carried across a checkout you do not own with cross domain cookies.
Consent built in. Consent mode, Global Privacy Control and Do Not Track are respected by default, so you are not choosing between accurate tracking and compliance.
Both platforms from one setup. Tag an action once and send it to Facebook and TikTok without writing the second integration.
Event logs you can actually check. Every payload sent to Meta is kept for 30 days and event records for 6 months, filterable by event, source or campaign, with queued delivery so an outage or a slow response does not leave a gap in your data.
And the parts that have nothing to do with failure modes, which are simply the job:
Tagging without code. The visual tagger turns any button, link or form into a tracked event by clicking it. URL triggers fire an event on a page load with nothing to tag at all. Automatic ecommerce events handle AddToCart, InitiateCheckout and Purchase for you on supported platforms.
Seeing what the events bought you. Attribution shows which ads and sources actually drove results, and customer journeys follow the whole path from first ad click to sale.
No meters. Unlimited events, unlimited pixels on a site, and unlimited subdomains under one site. Outgrown your plan's sites? Add extra sites one at a time instead of jumping a tier.
For teams and agencies. Teams covers invites, shared dashboards and who is allowed to change what, and done for you setup means someone configures the whole thing with you if you would rather not.
The full feature list has the rest.
PixelFlow sends to Facebook and TikTok today, with more platforms being added. Standard sends to one of them, Growth and Agency send to both. Google Ads and GA4 are not destinations you can switch on today, so if your answer above has to include those channels, that part is still a project.
If you are a developer who enjoys this work and has time to maintain it, building your own is a reasonable choice. If you would rather spend that time running your business and your ads, it is a lot cheaper to let someone else handle the edge cases.
You can try PixelFlow free and have server-side tracking running on Webflow, Framer, Squarespace or WordPress in minutes, with no code.
