DEV Community: TrackStack

Hotjar vs Microsoft Clarity vs LogRocket

TrackStack — Wed, 01 Jul 2026 18:18:08 +0000

Heatmaps and session recordings all look similar in a demo, which makes Hotjar vs Microsoft Clarity vs LogRocket a deceptively hard choice. The truth is these three are not really competitors — they are built for three different jobs. One is free and aimed at marketers, one is a qualitative research suite, and one is a developer debugging tool that happens to record sessions. Picking by price alone is how teams end up with the wrong fit.

This comparison is for SMB marketers, product owners, and developers deciding where to invest in behavior analytics in 2026 — what each tool is actually for, real pricing (including a major change to Hotjar), retention and privacy trade-offs, and a clear framework so you choose by use case rather than by a feature list.

Quick answer: which one to use

Microsoft Clarity is the default for most teams: it is genuinely free with unlimited sessions, strong heatmaps, and AI summaries — start here unless you have a specific reason not to. Hotjar earns its price when you need the qualitative layer Clarity lacks: surveys, feedback widgets, funnels, and 365-day retention. LogRocket is for engineering teams that need to debug — it captures console logs, network requests, and JavaScript errors alongside the replay. Pick Clarity for free behavior data, Hotjar to understand the "why," and LogRocket to fix the "what broke."

What each tool is built for

Microsoft Clarity — free behavior analytics

Clarity is a 100% free session-recording and heatmap tool with no paid tier and no session caps. Beyond standard click and scroll maps, it includes two diagnostics competitors charge for: dead-click heatmaps (clicks on things that are not interactive) and error-click heatmaps (clicks that trigger JavaScript errors), which are gold for spotting broken UI. In 2026 it also bakes in Copilot AI to summarise sessions, plus a native GA4 integration. It pairs naturally with your basic GA4 setup as the qualitative half of the picture.

Hotjar — the qualitative UX suite

Hotjar pairs heatmaps and recordings with the tools that explain behaviour: on-page surveys, feedback widgets, user interviews, and conversion funnels. It also adds move maps (tracking mouse hover, which correlates with attention) and automatic frustration and engagement scoring so you can skip to the recordings that matter. One important 2026 change: Hotjar officially merged into Contentsquare on July 1, 2025, so its pricing page now redirects there and the product is being folded into Contentsquare's modules.

LogRocket — developer debugging

LogRocket records sessions, but its real job is engineering. It captures console logs, network requests, JavaScript errors, and application state, so a developer can replay exactly what happened before a bug and connect a UX issue straight to a stack trace. It is the tool of choice when your engineers own support escalations and debugging time is the bottleneck — and it tends to overlap with performance work like Core Web Vitals rather than marketing CRO.

2026 pricing

The pricing gap here is the widest in the category — from completely free to enterprise quotes. Because of the Contentsquare transition and LogRocket's tiering, verify current numbers before committing; the figures below reflect mid-2026.

Microsoft Clarity

Free: $0 — unlimited sessions, recordings, and heatmaps, no caps, no credit card
Paid tiers: none — there is no "Clarity Pro"

That genuinely-free model is unusual in a category where "free" normally means a few hundred sessions before a paywall. Clarity's only real ceiling is retention and feature depth, not volume — you will never get an overage bill.

Hotjar (now Contentsquare)

Free: $0 — the new Contentsquare free plan offers around 5,000 monthly sessions with no sampling (a big upgrade from the old 35-sessions-per-day cap)
Paid: from roughly $32–$49/month depending on plan and session volume, with 365-day data retention on all plans
Higher tiers: scale to unlimited sessions with sampling, into the ~$171/month range

LogRocket

Free: $0 — around 1,000 sessions per month
Team / Developer: roughly $69–$99/month for about 10,000 sessions
Higher tiers: around $349/month for 50,000 sessions; AI error context (Galileo) sits on the upper plans

One pricing nuance that bites: LogRocket and most paid tools are "always-on," so every visit counts against quota. On a high-traffic site a 10,000-session plan can be exhausted in days, while Clarity simply never charges. Count cost per thousand sessions against your real traffic, not the monthly headline.

Feature comparison

Criterion	Clarity	Hotjar	LogRocket
Price	Free	Free + from ~$32/mo	Free + from ~$69/mo
Session limit	Unlimited	~5,000/mo free	~1,000/mo free
Data retention	~30 days	365 days	Plan-dependent
Surveys / feedback	No	Yes	No
Dev tooling (errors, network)	Basic JS errors	No	Full (console, network, state)
AI	Copilot summaries	In Contentsquare	Galileo (higher tiers)
Best for	Free behaviour data	UX research, the "why"	Engineering debugging

Real-world scenarios

Fixing a leaking checkout. If customers abandon at checkout, Clarity's free recordings and dead-click maps will show you where they get stuck — for nothing. Watch ten sessions of the checkout flow and the friction is usually obvious. Dead-click maps in particular reveal when users tap something that looks clickable but is not — a common hidden cause of checkout drop-off that standard analytics never surfaces.

Understanding why a landing page underperforms. When a page gets traffic but no conversions, heatmaps tell you what people do, not why. Hotjar's on-page survey ("What stopped you signing up today?") plus its move maps close that gap. This is where paying for Hotjar earns its keep.

Reproducing a customer-reported bug. When support says "a user couldn't submit the form and saw an error," marketing tools cannot help. LogRocket lets a developer replay that exact session with the console errors and failed network calls visible inline, turning a vague report into a reproducible bug. The rule of thumb: if the person who will watch the replay is a developer, LogRocket pays off; if it is a marketer or designer, Clarity or Hotjar will tell them what they need without the price tag.

The honest limitations

Where Clarity falls short. Recordings are typically retained only about 30 days, so long-term trend analysis is out. It has no surveys, feedback widgets, or funnels, and you cannot look up a session by a customer's email or name — only non-identifying custom tags. The biggest catch behind "free": Microsoft reserves the right to use your aggregated, anonymised data to improve its own products and AI, which can be a non-starter for healthcare, finance, or government teams.

Where Hotjar falls short. Cost climbs as traffic grows, and the Contentsquare merger has made the product and pricing feel less simple than the old "install a script and see heatmaps by the afternoon" Hotjar. It is web-only with no native mobile SDK, and it offers no developer tooling — no console, network, or error capture.

Where LogRocket falls short. It is the most expensive and the most complex, and marketers will find it overkill. Its always-on model burns through session quotas fast on high-traffic sites, and the best AI error context sits behind upper tiers. If nobody on your team is going to use the console logs and network traces, you are paying for power you will never touch.

How to choose

Choose Microsoft Clarity if you want free, unlimited behaviour data and can accept 30-day retention and the data-ownership trade-off.
Choose Hotjar if you need surveys, feedback, funnels, and long retention to understand the "why" behind behaviour.
Choose LogRocket if your engineers own debugging and you need console, network, and error data with each replay.
Run Clarity plus Hotjar if budget allows — many teams use Clarity for unlimited volume and Hotjar for qualitative depth.
Avoid LogRocket if you are a marketing-only team; the depth is wasted and the cost is high.
Avoid Clarity if your compliance rules forbid sharing behavioural data with a third party.

Conclusion

Hotjar, Microsoft Clarity, and LogRocket are not three versions of the same product — they are a marketing tool, a research suite, and an engineering tool. For most SMBs the smartest starting move is free: install Clarity, watch real sessions, and only add Hotjar when you need to ask users why, or LogRocket when your developers need to debug what broke. Match the tool to the job and you avoid paying for power you will not use. When you are ready to act on what you find, pair these insights with proper GA4 ecommerce events so the qualitative story and the quantitative numbers finally line up.

FAQ

Is Microsoft Clarity really free?
Yes, completely — no paid tier, no session caps, no credit card. The trade-off is data ownership: Microsoft uses aggregated, anonymised Clarity data to improve its own products and AI, and recordings are retained only about 30 days. For most businesses that is acceptable; for strict-governance industries it may not be.

Is Hotjar still available after the Contentsquare merger?
Yes. Hotjar merged into Contentsquare on July 1, 2025, and its pricing page now redirects there, but the product still works. The free plan actually improved to around 5,000 monthly sessions, though the tooling is gradually being folded into Contentsquare's broader modules.

Can I use Clarity and Hotjar together?
Yes, and many optimisation teams do. There is no technical conflict running both. A common setup is Clarity on every page for unlimited volume and frustration signals, with Hotjar for surveys, feedback, and deeper qualitative research where it adds the most value.

Which tool is best for developers?
LogRocket, clearly. It captures console logs, network requests, JavaScript errors, and application state alongside the session replay, so developers can reproduce bugs from a customer report. Clarity surfaces basic JS errors and error-clicks, but it lacks the deep debugging tooling LogRocket provides.

Do Clarity or Hotjar slow down my site?
Both add a tracking script, so there is a small performance cost, as with any analytics tool. The impact is usually minor, but always-on session recording on heavy pages can add weight — worth checking against your performance budget if page speed is a priority.

What is the catch with Microsoft Clarity being free?
The catch is data and retention, not money. Microsoft funds Clarity as a loss-leader and uses anonymised behavioural data to improve Bing, Edge, and its AI systems, and recordings expire after roughly 30 days. If those terms fit your privacy posture, it is the best free behaviour tool available.

These three are not really competitors. Clarity is genuinely free (unlimited sessions, heatmaps, dead-click/error-click maps, Copilot summaries) — the default starting point, with ~30-day retention and a data-ownership trade-off. Hotjar (now part of Contentsquare since July 2025) adds the qualitative layer — surveys, feedback, funnels, 365-day retention — from ~$32/mo. LogRocket is a developer tool: console, network, errors, and state alongside the replay, from ~$69/mo and always-on. Start with Clarity, add Hotjar to learn why, add LogRocket to debug what broke.

How to Track Form Submissions in GA4 Without Coding (2026)

TrackStack — Mon, 29 Jun 2026 17:32:36 +0000

Your contact form is probably the most valuable interaction on your site — and the one most likely to be tracked badly or not at all. The good news: you can track form submissions in GA4 without writing a single line of code. The catch is that the easiest method is also the least reliable, so picking the right approach for your specific form matters more than the setup itself.

This guide is for marketers and developers who already have basic GA4 setup running and want accurate lead data without shipping custom code — four no-code methods, when each works and when it quietly fails, how to turn a tracked submission into a key event, and the pitfalls (double counting, inflated numbers, embedded forms) that wreck most setups.

Quick answer: which no-code method to use

If your form redirects to a thank-you page, track visits to that page — it is the most reliable no-code method. If it does not redirect, use Google Tag Manager: the built-in Form Submission trigger for standard HTML forms, or an Element Visibility trigger on the success message for AJAX forms. GA4's built-in Enhanced Measurement can track forms with zero setup, but it is notoriously unreliable and often inflates numbers, so treat it as a quick test rather than a final solution. Whatever you pick, verify it in DebugView and mark it as a key event.

The 4 no-code methods

Method 1 — Enhanced Measurement (zero setup, big catch)

GA4 can track forms automatically with no tools at all. Go to Admin → Data Streams → your web stream → Enhanced Measurement, open the settings, and toggle on "Form interactions." GA4 then attempts to fire form_start and form_submit events on its own.

The honest reality: this is widely regarded as one of GA4's least reliable features. It only catches standard HTML <form> elements with native submit behaviour, so it misses most modern AJAX and JavaScript forms — and when it does fire, it frequently over-counts, with some sites reporting thousands of phantom submissions a day. It also fires form_submit on interactions that are not real submissions, so a single visitor can generate several. Use it for a five-minute sanity check, not as your reporting source.

Method 2 — thank-you page (the most reliable)

If submitting your form sends users to a dedicated confirmation page, that redirect is the cleanest signal you have. In GTM, create a trigger of type Page View with the condition Page Path equals /thank-you/, then attach a GA4 Event tag named something like generate_lead. When the thank-you page loads, the event fires.

This method needs no understanding of how the form submits, works across every form type, and is the most trustworthy of the four. Its one weakness: anyone reaching that URL directly — via a bookmark, email link, or internal link — counts as a conversion. Make the thank-you page unreachable except by submitting, and the data stays clean. It is the ideal pairing for a lead magnet funnel where the confirmation page already exists. To verify, open GTM Preview, submit the form, confirm the tag fires on the thank-you URL, then check GA4 Realtime.

Method 3 — GTM Form Submission trigger

For standard forms that do not redirect, GTM has a built-in listener. First enable the Form built-in variables (Variables → Configure → tick the Form group). Then create a trigger of type Form Submission, leave "Check Validation" on so it only fires on successful submits, and target a specific form by Form ID if you have several. Attach your GA4 Event tag and you are done — no code.

The limitation is real: this listener was designed for old-school forms that POST and reload, so it does not reliably detect AJAX submissions where the page never navigates. If Preview mode shows no gtm.formSubmit event when you submit, your form is almost certainly AJAX — move to Method 4. When it does work, it is genuinely set-and-forget and captures useful context like the form ID and page automatically.

Method 4 — Element Visibility for AJAX forms

Most modern forms submit in the background and show an inline "Thanks, we got your message" without reloading. The no-code trick is to track when that success message appears. In GTM, create an Element Visibility trigger, point it at the confirmation element with a CSS selector (for example .form-success), enable "Observe DOM changes," and fire your GA4 Event tag on it. The message only appears on a genuine submission, so it is a clean signal — just pick a stable selector and test it in Preview first.

Many form plugins make this even easier by pushing their own dataLayer event on submit, which a GTM Custom Event trigger can catch directly. If your plugin offers a native GA4 or dataLayer integration, that is usually the most robust no-code route of all — let the plugin do the listening for you.

The four methods compared

Method	Needs GTM?	Works on AJAX forms?	Reliability
Enhanced Measurement	No	Rarely	Low (often inflated)
Thank-you page	Yes	Yes (if it redirects)	Highest
Form Submission trigger	Yes	No	Good (standard forms)
Element Visibility	Yes	Yes	Good (needs a CSS selector)

Turn the event into a key event

Tracking the event is only half the job — to use it as a conversion, you must promote it. In GA4 go to Admin → Events, find your form event (e.g. generate_lead), and toggle "Mark as key event." Note the terminology: Google renamed "conversions" to "key events" in March 2024, though they still appear as conversions when imported into Google Ads — the function is identical, only the label changed. (If a colleague asks where conversions went, that is the answer.)

For sharper reporting, add a value parameter to the tag so a quote request can be worth more than a newsletter signup — say 100 versus 10 — which feeds straight into ROI calculations.

Common pitfalls that wreck your data

Form tracking fails quietly more often than loudly. These are the issues that make your numbers wrong while everything looks fine.

Double counting: running Enhanced Measurement form tracking and a custom GTM setup at once fires two events per submission. If you build custom tracking, turn off the Form interactions toggle.
Inflated thank-you pages: direct visits, bookmarks, and email links to the confirmation URL all count as conversions. Block direct access to that page.
Embedded third-party forms: HubSpot and Typeform sit in cross-origin iframes that standard triggers cannot read. HubSpot fires a global JavaScript event GTM can catch; Typeform can redirect to a thank-you page on your domain.
Bots and spam: automated submissions inflate counts — filter aggressively and sanity-check against reality.
Consent gaps: if your cookie banner blocks GA4 before consent, submissions go untracked.

The single best habit is to cross-check monthly. Compare GA4's form event count against the records in your inbox or CRM — if GA4 shows double, you have a duplication problem; if it shows far fewer, tracking is missing submissions. Tracking that worked last month can break silently after a theme, plugin, or layout change.

Which method should you use?

Thank-you page if your form redirects — the most reliable and least fragile.
GTM Form Submission trigger for standard HTML forms that POST and reload.
Element Visibility for AJAX forms with an inline success message.
Your form plugin's native integration if it offers one — often the most robust no-code option.
Enhanced Measurement only as a quick test, never as your final reported source of truth.

For most teams the practical answer is a thank-you page where possible and Element Visibility everywhere else. You do not need one method for the whole site — a contact form can use the thank-you page while a pop-up lead magnet uses Element Visibility, as long as event names stay consistent. Once leads are tracked accurately, the natural next step is routing them onward — for example to send leads to your CRM the moment a form is submitted.

Conclusion

You do not need a developer to track form submissions in GA4 — you need the right method for how your form behaves. Thank-you page tracking is the most reliable, Element Visibility covers AJAX forms, the GTM Form Submission trigger handles standard ones, and Enhanced Measurement is a quick test at best. Whichever you choose, verify it in DebugView, mark it as a key event, watch for double counting, and cross-check against your CRM every month.

FAQ

Can I track form submissions in GA4 without Google Tag Manager?
Yes, using Enhanced Measurement's Form interactions toggle, which needs no GTM. The trade-off is reliability — it only catches standard HTML forms and often over-counts. For accurate data without GTM, the alternative is a form plugin with a native GA4 integration.

Why is GA4 not tracking my form submissions?
The most common reason is an AJAX form that does not trigger a standard browser submit, so Enhanced Measurement and the GTM Form Submission trigger both miss it. Use an Element Visibility trigger on the success message instead, and confirm in GTM Preview that an event actually fires on submit.

Why does GA4 show more form submissions than I received?
Usually double counting — Enhanced Measurement form tracking running alongside a custom GTM setup, both firing on one submission. Disable the Form interactions toggle if you built your own tracking. Inflated thank-you pages from direct visits and bot spam are the other common causes.

How do I mark a form submission as a conversion?
In GA4, go to Admin → Events, find your form event, and toggle "Mark as key event." Google renamed conversions to key events in 2024, but they still import into Google Ads as conversions. The event must have fired at least once before it appears in the list.

Can I track HubSpot or Typeform forms in GA4?
Yes, but not with standard triggers, because they load in cross-origin iframes. HubSpot fires a global JavaScript event that GTM can listen for with a Custom Event trigger. Typeform can redirect to a thank-you page on your own domain, which GA4 then tracks as a page view.

Is Enhanced Measurement form tracking accurate?
Not reliably. It works for basic HTML forms on simple sites but misses AJAX and JavaScript forms and frequently inflates submission counts. For trustworthy data, use a thank-you page or a GTM trigger instead, and disable Enhanced Measurement form tracking to avoid duplicates.

You can track GA4 form submissions with no code. Four methods: thank-you page (most reliable — fire a GA4 event on the confirmation pageview), GTM Form Submission trigger (standard HTML forms only), Element Visibility (AJAX forms — fire when the success message appears), and Enhanced Measurement (zero setup but unreliable, a quick test at best). Verify in DebugView, mark the event as a key event, don't run Enhanced Measurement alongside custom tracking (double counting), and cross-check GA4 against your CRM monthly.

GA4 Custom Dimensions: A Setup Guide with Real Examples (2026)

TrackStack — Sat, 27 Jun 2026 15:51:32 +0000

GA4 ships with dozens of built-in dimensions, but the moment you want to report on something specific to your business — which blog category drives signups, which membership tier converts, which product colour sells — you hit the wall. That is where GA4 custom dimensions come in: they let you attach your own data to events and users and make it visible in reports.

This guide is for marketers and developers who already have basic GA4 setup running and want to extend it without breaking anything — what custom dimensions really are, the three scopes, the exact 2026 limits, a step-by-step setup with GTM, real examples for each scope, and the mistakes that quietly ruin your data.

Quick answer: how custom dimensions work

A custom dimension is two things working together: an event parameter (or user property) you send from your site, and a registration in GA4 Admin that maps that parameter to a readable name and a scope. Both halves are required — sending without registering means the data sits invisible in raw collection; registering without sending means an empty dimension. Crucially, registration is not retroactive: data only appears from the moment you register it forward, so set it up before you need the history.

What GA4 custom dimensions actually are

Event parameter vs registered dimension. An event parameter is the key-value pair sent with an event at collection time — for example, file_name: "pricing.pdf" sent with a file_download event. The parameter is where the data lives. A custom dimension is the registration in GA4 Admin that connects that parameter name to a display label and makes it visible in standard reports, Explorations, and audiences. Without registration, the parameter still exists in raw collection and in the BigQuery export, but it is invisible in the GA4 interface. This split trips people up constantly: they see the parameter in DebugView, assume the job is done, then wonder why it never shows in a report. The two steps are separate by design, and you need both.

The three scopes: event, user, item. Scope decides how the value attaches to your data, and choosing wrong is the single most common cause of broken reports.

Event-scoped dimensions attach to one event only — the next event from the same user will not inherit the value.
User-scoped dimensions attach to the user profile and persist across every future event until overwritten — right for stable attributes like subscription tier.
Item-scoped dimensions live inside the items array of ecommerce events and describe individual products.

Note that session scope is not available for custom dimensions in GA4. If you genuinely need a value to apply to every event in a session, you have to send it with each event yourself. Getting scope right at the design stage saves hours of debugging, since a mis-scoped dimension fails quietly rather than throwing an error.

The limits you must plan around

These limits are per property — not per account or per stream — and easy to hit on a complex setup. One important nuance: deleting an event-scoped dimension frees the slot after a 48-hour wait, but archiving a user-scoped dimension does not free its slot, so the 25 user-scoped definitions are effectively fixed.

Type	Standard property	Analytics 360	Notes
Event-scoped	50	125	Slot frees 48h after deletion
User-scoped	25	100	Archiving does NOT free a slot
Item-scoped	10	25	Explorations only, not standard reports
Custom metrics	50	125	Numeric values only
Calculated metrics	5	5	Built from numeric metrics

How to set up a custom dimension, step by step

The order of sending and registering does not strictly matter, but do both at roughly the same time — a gap means missing data for that window.

Step 1 — send the parameter

Push the value into the data layer, then read it into your GA4 event tag in GTM. For a blog where you want to know which category drives engagement:

dataLayer.push({
  event: 'article_view',
  article_category: 'analytics',
  author_name: 'editorial'
});

In GTM, create Data Layer Variables for article_category and author_name, then add them as parameters on your GA4 event tag. The parameter name you send must match the name you register exactly — article_category is not the same as articleCategory.

Step 2 — register it in GA4 Admin

Go to Admin → Custom definitions → Custom dimensions → Create custom dimension. Enter a Dimension name (the readable label in reports, e.g. "Article Category"), pick the Scope (Event), and type the Event parameter name exactly as it arrives (article_category). Save. That registration tells GA4 — and connected tools like Looker Studio — to expect the parameter and surface it as a dimension.

Step 3 — verify in DebugView, then wait

Before trusting anything, open DebugView and confirm the parameter is arriving with the right value on the right event. A common agency mistake is registering a dimension before confirming the event actually fires. Once verified, data takes 24–48 hours to populate in standard reports — DebugView is immediate, reports are not.

Real examples by scope

Event-scoped: content category and form name

Event-scoped is right for data that describes a single action. Sending article_category on an article_view lets you see which topics drive engagement. Sending form_name on a form_submit lets you compare your newsletter form against your contact form. Both describe that one interaction and should not persist — which is exactly what event scope does.

User-scoped: membership tier

For stable attributes that should follow the user everywhere, use a user property. Set it on the first event after login, when you have the identity context:

gtag('set', 'user_properties', {
  membership_tier: 'premium'
});

Now every subsequent event — page views, purchases, conversions — carries membership_tier, so you can segment any report by plan. The classic mistake is sending this as an event parameter on the login event only, which leaves every later event blank.

Item-scoped: product attributes

Item scope answers product-level questions like revenue per colour or margin tier. The custom parameters go inside each object in the items array of an ecommerce event:

dataLayer.push({
  event: 'add_to_cart',
  ecommerce: {
    items: [{
      item_id: 'SKU_12345',
      item_name: 'Running Shoes',
      item_color: 'blue',
      margin_tier: 'high'
    }]
  }
});

Remember that item-scoped dimensions only appear in Explorations, not standard reports. If you are wiring up ecommerce tracking from scratch, the GA4 ecommerce events guide covers the full items array first.

Common mistakes that silently break your data

The most dangerous mistakes produce no error — your dimension just stays empty or wrong while you assume it works.

Wrong scope: event scope for something stable like membership tier (data only on one event), or user scope for something transient like a search term (every future event inherits the wrong value).
Name mismatch: the registered name and the sent parameter must be identical, character for character.
Passing PII: never send emails, phone numbers, or names as dimension values — it violates Google's Terms and can get your property permanently deleted.
High cardinality: dimensions with thousands of unique values (full URLs, user IDs, timestamps) overflow into an aggregated (other) row and become useless — keep values to a bounded set of categories.
Hoarding slots: registering every parameter you ever send. Audit quarterly and retire anything not queried in 90 days.

Also remember the 100-character value limit (with a few exceptions like page_location at 1,000), and that raw exports keep everything regardless — so if you need full history or unregistered fields, lean on BigQuery or server-side tracking.

Which scope should you use?

Work backwards from the question you want to answer rather than from the data you happen to have. If the answer is "per action," reach for event scope; "per person," user scope; "per product," item scope.

Event scope — the value describes a single action: content category, button label, form name, video title.
User scope — the value is a stable trait of the person: subscription tier, customer type, company size, signup source.
Item scope — the value describes a product inside an ecommerce event: colour, size, brand, margin tier.
Custom metric instead — the value is numeric and you want to sum or average it: loyalty points, scores, credits.
Nothing — if GA4 already captures it; check the built-in dimensions before spending a slot.

Conclusion

Custom dimensions are what turn GA4 from a generic report into a tool that answers your specific questions — but only if you get the fundamentals right. Send the parameter and register it together, pick the scope deliberately, respect the per-property limits, verify in DebugView, and never pass PII. Start with two or three high-value dimensions rather than registering everything, keep a small register of what each one is for, and audit quarterly.

FAQ

Are GA4 custom dimensions retroactive?
No. Data only appears from the moment you register the dimension forward — there is no backfill. If you send a parameter for a week before registering it, reports will miss that week. Raw data streamed to BigQuery keeps the parameter regardless.

What is the difference between an event parameter and a custom dimension?
The parameter is the key-value data sent with an event at collection time. The custom dimension is the GA4 Admin registration that maps that parameter to a readable name and scope, making it visible in reports. Without registration the parameter exists in raw data but not in the GA4 interface.

How many custom dimensions can I create?
On a standard property: 50 event-scoped, 25 user-scoped, 10 item-scoped, plus 50 custom metrics, all per property. Analytics 360 raises these to 125, 100, and 25. Deleting an event-scoped dimension frees its slot after 48 hours; archiving a user-scoped one does not.

Why is my custom dimension showing no data?
Usually one of three reasons: the parameter name does not match the registered name exactly, the event is not actually firing (check DebugView), or you registered it less than 24–48 hours ago. Item-scoped dimensions also only show in Explorations, not standard reports.

Should membership tier be event-scoped or user-scoped?
User-scoped. It is a stable attribute that should follow the user across every event, so set it as a user property after login. As an event parameter on the login event only, it will be blank on all later events.

Can I send personal data as a custom dimension?
No. Passing emails, phone numbers, full names, or other PII violates Google's Terms of Service and can result in your property being permanently deleted. Use non-identifying values like tiers, categories, or hashed identifiers.

A GA4 custom dimension = an event parameter (or user property) you send + a registration in GA4 Admin that maps it to a name and scope. Both are required, and registration is not retroactive (no backfill). Pick scope by the question: per action → event, per person → user, per product → item. Limits per property: 50 event / 25 user / 10 item / 50 metrics — and archiving a user-scoped one never frees the slot. Match parameter names exactly, verify in DebugView, wait 24–48h, and never send PII.

Coda vs Notion: Which Is Better for Your Workspace? (2026)

TrackStack — Wed, 24 Jun 2026 04:42:42 +0000

Both Coda and Notion promise the same thing — one workspace to replace your wiki, project tracker, and lightweight database — but they get there from opposite directions. Notion is document-first: everything is a block on a page, and you build outward. Coda is app-first: every doc can behave like a small application, with spreadsheet-grade formulas and automations baked in. The label "all-in-one workspace" hides a real fork in the road.

This Coda vs Notion comparison is for SMB teams and operators deciding where to centralise their work in 2026 — the genuine difference in philosophy, the pricing models that can swing your annual bill by thousands, where each wins and frustrates, and a clear framework for choosing (including the team-structure question most comparisons skip).

Quick answer: Coda or Notion?

Notion is the better default for most teams: easier to learn, document-first, stronger AI agents, native offline support, and a vast template ecosystem. Coda wins when you need spreadsheet-grade formulas, app-like automation, and — crucially — when you have many content consumers but few creators, because its maker billing only charges the people who build docs. Pick Notion for clarity, writing, and fast adoption; pick Coda for logic, automation, and real cost savings on consumer-heavy teams.

The core difference: documents vs applications

Before pricing or features, understand the philosophy, because it shapes everything else. Notion wants documents that are easy and forgiving; Coda wants documents that behave like software. It comes down to a simple question: do you need a document you read and edit, or a document that calculates and does things for you? Confusing those two needs is the main reason teams pick the wrong tool and migrate six months later.

What Notion is built for. Notion treats the page as the unit. You drag text, headings, databases, and embeds into any layout, and most people are productive within 15 minutes. It is strongest as a knowledge hub — wikis, notes, and lightweight databases — and shines when documentation and tasks live together; if your main goal is a searchable internal knowledge base, it is the natural fit. Its permission system is granular (five levels from full access to comment-only), so you can protect a table's structure while still letting people add rows. Founded in 2013, it has had years to polish the editing experience.

What Coda is built for. Coda treats the doc as a programmable surface. Its tables are full spreadsheets with a formula engine that rivals Excel (IF, VLOOKUP, SUMIF), plus buttons that trigger automations and Packs that sync two-way with tools like Slack, Jira, and Google Calendar. It also includes native time tracking, which Notion lacks. The payoff is power; the price is a steeper learning curve of 30–60 minutes. Coda also offers unlimited guest access by email on paid tiers, where Notion caps guests at 100 on Plus and 250 on Business — useful for agencies juggling many clients.

2026 pricing: the maker-billing story

Pricing is the single biggest practical difference, and it is not about the sticker price — it is about who pays. Notion charges per seat: every user costs the same whether they write or only read. Coda uses maker billing: only Doc Makers (people who create docs) pay, while editors and viewers are free. That structural gap can swing a large team's annual bill by a five-figure number.

Notion

Free: unlimited pages for individuals; block limits for 2+ member workspaces; 5MB file uploads
Plus: $10/user/month annual ($12 monthly)
Business: $20/user/month annual ($24 monthly) — includes full Notion AI
Enterprise: custom — SAML SSO, SCIM, advanced controls

Notion AI is now bundled into paid plans rather than a separate add-on, with a credit pool per plan. The catch: full AI sits on the Business tier, so unlocking it means upgrading every seat.

Coda

Free: unlimited docs, tables, and automations, but with object/row caps per doc
Pro: $10/Doc Maker/month annual — unlimited free editors, 2,000 AI credits per maker
Team: $30/Doc Maker/month annual — advanced admin, 6,000 AI credits
Enterprise: custom

Which is actually cheaper. Count your builders versus consumers. If everyone creates docs, Notion is usually cheaper — Business at $20 beats Coda Team at $30 per maker. But if a few build and many only read, Coda wins big: a 100-person company with 15 Doc Makers pays roughly $450/month on Coda Team versus about $2,000/month for Notion Business at the same headcount. Coda reports teams saving up to 78% when only a fraction create docs. Watch for "maker creep," though — depending on setup, someone who just wants to add a table row may need maker status.

Feature comparison

Criterion	Notion	Coda
Approach	Document-first	App-like / formula-driven
Billing model	Per user (all pay)	Per Doc Maker (editors free)
Entry paid price	$10/user/mo	$10/maker/mo
Formulas / automation	Basic	Spreadsheet-grade, strong
Ease of adoption	~15 min	30–60 min learning curve
AI	Agents, bundled in plans	Included for makers (credits)
Offline support	Yes (desktop)	Limited (web-first)

When to choose each

Choose Notion for knowledge and writing. A team maintaining handbooks, onboarding guides, meeting notes, and a wiki is better served by Notion. Its editor is more pleasant for long-form writing, adoption is fast, and the template ecosystem covers nearly every workflow — it is also the easier base for running Notion as a lightweight CRM without much setup.

Choose Coda for interactive, data-rich systems. If your documentation needs to calculate, automate, or behave like an app — live dashboards, OKR systems, approval flows, or API docs with automated changelogs — Coda does things Notion cannot. A practical test: if the same content would work as a static page, Notion is enough; if it needs to react to data (recalculating a metric, flipping a status, notifying Slack when a field changes), that is where Coda earns its complexity.

Choose by team structure and budget. This is the deciding factor many people miss. A large team with a handful of builders and a wide circle of viewers should lean Coda for the maker-billing savings. A team where everyone creates content should lean Notion, where flat per-seat pricing is simpler and often cheaper.

The honest limitations

Where Notion frustrates. Its flexibility invites over-engineering — teams build sprawling, messy workspaces. Its formulas are basic next to Coda's, deeper automation leans on third-party tools like Zapier, and performance degrades past roughly 10 concurrent editors on one page. Full AI also requires the Business tier across every seat. Search gets harder as the workspace grows into hundreds of pages, and without discipline the wiki becomes a place where everything exists but nothing is findable.

Where Coda frustrates. Its power comes with complexity; non-technical teammates often need tutorials before they are productive. Offline support is limited because the app is web-first, and the free plan's per-doc object caps bite quickly. There is also a strategic question: Coda is now owned by Superhuman (formerly Grammarly), and its AI roadmap has folded into that suite — a different priority list than picking Coda standalone, which makes betting on a specific future feature riskier than with Notion's single roadmap.

How to choose: a simple framework

Choose Notion for a polished knowledge hub, easy adoption, strong AI agents, and offline access.
Choose Coda for spreadsheet-grade formulas, app-like automation, native time tracking, or cross-doc logic.
Choose Coda if you have many viewers and few creators — maker billing saves significantly at scale.
Choose Notion if everyone on the team creates content, since flat per-seat pricing is simpler and often cheaper.
Avoid Coda if your team is non-technical and needs fast, frictionless adoption.
Avoid Notion if your core need is interactive, calculation-heavy documents rather than writing.

Conclusion

Coda versus Notion is not a contest with one winner — it is a choice between two philosophies. Notion is better for clarity, writing, and rapid adoption, and it is the safer default for most teams. Coda is better for automation, structure, and system-building, and its maker billing makes it dramatically cheaper for teams with many consumers and few creators. The smartest move is the oldest one: build a real workflow in each on the free plan, count your builders versus consumers, and pick the tool that fits how your team actually works. (If AI is central to that decision, it is worth weighing Notion AI vs ChatGPT separately too.)

FAQ

Is Coda cheaper than Notion?
It depends on team structure. Coda only charges Doc Makers, so if you have many viewers and few creators, it is much cheaper — sometimes 50–80% less. But if everyone creates documents, Notion's flat per-seat pricing usually wins, with Business at $20 undercutting Coda Team at $30 per maker.

Is Notion or Coda easier to learn?
Notion, clearly. Its block-based editor and huge template library get most users productive within 15 minutes. Coda is more powerful but demands a 30–60 minute investment in tables, Packs, and formulas before it feels comfortable.

Does Coda have better automation than Notion?
Yes. Coda has spreadsheet-grade formulas, in-doc buttons, and Packs with real two-way sync, so documents can act like applications. Notion's formulas are more basic and deeper automation usually relies on third-party tools like Zapier.

Which has better AI in 2026?
Notion has the more coherent AI story: AI is bundled across paid plans and now includes agents that run multi-step actions across connected tools. Coda AI inside the doc is excellent for formula and data work, but its broader AI roadmap has shifted into the Superhuman suite after the acquisition.

Can I use either tool for personal productivity?
Both work, but Notion is the better personal pick for notes, task tracking, and a "second brain," thanks to its simplicity and template ecosystem. Coda can work personally for advanced databases or mini-apps, but it is often overkill for simple personal workflows.

Does Notion or Coda work offline?
Notion has a desktop app with offline support, so you can view and edit cached pages without internet. Coda is web-first with limited offline capability, which makes Notion the better choice for people who travel or work with unreliable connectivity.

Notion is document-first and billed per seat; Coda is app-first (spreadsheet-grade formulas, automations, Packs) and billed per Doc Maker, with editors and viewers free. Notion wins on ease, AI agents, offline, and templates — the safer default. Coda wins on formulas, automation, and cost when you have many consumers and few creators (up to ~78% cheaper at scale). Count builders vs consumers, trial both free, and pick by team structure — not by which logo you know.

Loom vs Zoom: When to Use Asynchronous Video (2026)

TrackStack — Wed, 17 Jun 2026 13:29:01 +0000

Half the meetings on a calendar could have been a recorded video, and half the recorded videos teams send could have been a paragraph of text. The trick is knowing which is which. Loom and Zoom get compared as if they were rivals, but they solve opposite problems: Loom is asynchronous — record once, watched whenever — while Zoom is synchronous, everyone present at the same time. The real question is not which tool is better; it is when each mode of communication is the right one.

This is for SMB owners, team leads, and remote-first managers trying to cut meeting bloat without losing the conversations that genuinely need to be live. Below: real 2026 pricing for both, the scenarios where each shines, the honest downsides of each, and a simple framework for choosing between a message, a recording, and a meeting.

Quick answer: Loom or Zoom?

Use Loom when information flows one way and timing does not matter — status updates, walkthroughs, onboarding, code or design reviews, client explainers. The viewer watches on their own schedule, at their own speed, and nobody hunts for a slot on three calendars. Use Zoom when real-time back-and-forth is required: brainstorming, negotiation, sensitive conversations, interviews, or any decision that needs live debate.

In short: Loom replaces the meeting that should not exist; Zoom protects the meeting that should. Most teams need both, and the money question is smaller than it looks because Loom charges per recorder while Zoom charges per host.

Async vs sync: the distinction that actually matters

Before comparing features, get the mental model right. Synchronous communication is expensive because it costs everyone the same hour at the same time. Asynchronous communication is cheap because each person spends their own time when it suits them. The skill is matching the channel to the message, not defaulting to a meeting out of habit.

A practical rule: if someone needs to decide something together, right now, that is sync. If they can react in an hour or tomorrow, that is async — and a recording or text will beat a call.

What Loom is built for

Loom is a video messaging tool acquired by Atlassian in 2023. You record your screen and camera, it generates a shareable link instantly, and the recipient watches without an account. It is ideal for "let me show you" moments — clumsy in text, but not worth a live call. Recordings become a searchable library, which quietly turns Loom into part of an internal knowledge base rather than a one-off.

What Zoom is built for

Zoom is the default for live video — meetings, webinars, interviews, real-time collaboration. Its strength is presence: reading reactions, interrupting, deciding together in one sitting. If you are weighing it against other live tools, trackstack.tech has a deeper Zoom vs Google Meet vs Teams breakdown. For anything that needs genuine dialogue, async video is a poor substitute and Zoom is the right call.

2026 pricing, plan by plan

The pricing models are structurally different, and that difference often decides the budget more than the per-seat number. Loom charges per Creator — the people who record — and viewers are free forever. Zoom charges per host license. A team where one person records explainers for forty viewers pays very differently across the two.

Loom pricing in 2026

Starter (Free): $0 — up to 25 videos per creator, 5-minute cap per video, 720p
Business: $15/creator/month annual (or $18 monthly) — unlimited videos and length, up to 4K, remove Loom branding, viewer analytics
Business + AI: $20/creator/month annual (or $24 monthly) — AI titles, summaries, chapters, filler-word and silence removal, edit by transcript
Enterprise: custom — SSO (SAML), SCIM, advanced retention, Salesforce integration, 99.95% SLA

The key cost lever: only recorders need a seat. If two of five teammates record regularly, you pay for two creators (about $360/year on Business annual) while the rest watch free. That viewer-free model is what makes Loom cheap for outbound explainers and expensive only when everyone records.

Zoom pricing in 2026

Basic (Free): $0 — unlimited 1:1 meetings, group meetings capped at 40 minutes, up to 100 participants, no cloud recording
Pro: $13.33/user/month annual (or $16.99 monthly) — 30-hour meetings, 100 participants, 10GB cloud storage, AI Companion
Business: $18.33/user/month annual (or $21.99 monthly) — 300 participants, SSO, managed domains, recording transcripts, 10-seat minimum
Business Plus: $29/user/month — bundles Zoom Phone
Enterprise: custom pricing

The famous gate is the 40-minute cap on free group meetings — the single most common reason teams upgrade to Pro. Watch the cloud-storage trap too: recordings pile up, and once you exceed the included allowance Zoom charges roughly $10/month per extra 30GB, billed every month the files stay there.

Feature comparison

Criterion	Loom (async)	Zoom (sync)
Communication mode	One-way, watch anytime	Real-time, everyone present
Billing model	Per creator (viewers free)	Per host license
Entry paid price	$15/creator/mo	$13.33/user/mo
Free tier limit	25 videos, 5-min cap	40-min group meetings
Scheduling needed	None	Yes (calendars align)
Timezone-friendly	Excellent	Poor across wide gaps
Best for	Walkthroughs, updates, reviews	Debate, decisions, sensitive talks

When async video wins (reach for Loom)

Onboarding and repeatable training. Record the setup walkthrough once and every new hire watches it on day one — no repeated live sessions. Pair recordings with written docs and a task management system so onboarding has both the "how" on video and the checklist to follow.

Code, design, and document review. Talking through a pull request or a mockup while pointing at the screen carries nuance that inline comments lose, and the author watches when they reach that task rather than dropping everything for a call. This fits how dev teams run their workflow, where context matters but interrupt-driven meetings kill focus.

Async standups across timezones. For a team split across five hours of timezone gap, a daily live standup is a tax on someone. A 90-second recorded update each morning keeps everyone informed without forcing anyone awake at an awkward hour — a core habit for remote teams that run distributed by design.

Client explainers and sales follow-ups. A personalised two-minute walkthrough sent to a prospect lands better than another email and needs no booked call. Because viewers do not need a Loom account, this is genuinely frictionless for outbound — one of the clearest wins of per-creator pricing.

When a live call wins (reach for Zoom)

Decisions that need real debate. When a topic has competing opinions and trade-offs to resolve, the back-and-forth of a live call reaches a conclusion in twenty minutes that a thread of recordings would drag out over two days. Branching discussions need interruption, and async cannot interrupt.

Sensitive or high-stakes conversations. Feedback, conflict, negotiation, and anything emotionally loaded belongs live. A recording cannot read the room or adjust mid-sentence when someone reacts. Sending a difficult message as a one-way video usually makes it worse, not faster.

Interviews, kickoffs, and relationship-building. First meetings, hiring interviews, and project kickoffs benefit from rapport that only happens live. These are the moments where presence is the point, and trimming them to async saves time nobody wanted to save.

The honest limitations

Where Loom frustrates. Async has no immediacy — if you need an answer now, a recording is the wrong tool. Loom also tempts overuse: people record three-minute videos for things a two-line message would settle, which just moves the bloat from meetings to playback. And the per-creator cost climbs once the whole team records regularly, so it is not automatically the cheap option.

Where Zoom frustrates. Meeting fatigue is real, scheduling across timezones is constant friction, and the 40-minute free cap nudges you to pay quickly. Cloud-recording storage costs creep up if you record often, and a calendar packed with calls that should have been recordings is the exact problem async video exists to fix.

How to choose: the escalation ladder

Default to the lightest channel that does the job, and only escalate when it genuinely needs more:

Text first — if it fits in a few lines and needs no visuals, send a message, not a video.
Loom (async video) next — when you need to show something, explain a process, or add tone, but no live reply is required.
Zoom (live) last — when the topic needs real-time debate, is sensitive, or involves a decision with trade-offs.
Choose Loom if your team is distributed, your messages are mostly one-way, and only a few people record.
Choose Zoom if your work is collaborative and decision-heavy, or you run interviews and client calls regularly.
Avoid recording anything urgent, emotional, or genuinely two-way — that is a call.

Conclusion

Loom versus Zoom is not a contest with a winner — it is a choice between two modes of communication, and the mature answer is to use both deliberately. Loom kills the meeting that should never have been scheduled; Zoom protects the conversation that genuinely needs everyone in the room. Get the async-versus-sync instinct right and you reclaim hours a week without losing the dialogue that matters. Audit your calendar for a fortnight, move the one-way meetings to recordings, and keep the rest live.

FAQ

Is Loom a replacement for Zoom?
No — they cover different needs. Loom handles one-way, watch-anytime communication; Zoom handles real-time meetings. Many teams use both: Loom to cut unnecessary meetings, Zoom for discussions that truly need to be live.

Is Loom free for viewers?
Yes. Loom charges per creator — the people who record — and viewers watch shared links for free without an account. That makes it cost-effective when only a few teammates record but many people watch.

Why does Zoom cut my meeting off at 40 minutes?
The 40-minute limit applies to group meetings on the free Basic plan. One-on-one meetings are unlimited. Upgrading to Pro at $13.33 per user per month (annual) removes the cap and extends meetings to 30 hours.

Can I record meetings in Zoom instead of using Loom?
You can, but a Zoom recording is a captured live meeting, not a purpose-built async message. Loom is faster for quick screen walkthroughs, generates instant shareable links, and keeps a searchable library, whereas Zoom recordings are heavier and consume cloud storage.

Which is cheaper for a small team?
It depends on who records or hosts. Loom only bills the people who record, so a team where two people make videos for everyone is cheap. Zoom bills per host, so the cost tracks how many people run meetings, not how many attend.

Does asynchronous video actually save time?
It does when it replaces a meeting that did not need everyone live, because viewers watch on their own schedule and often at faster speed. It saves nothing if it replaces a message that should have stayed text, so match the channel to the task.

Loom is asynchronous (record once, watched anytime, billed per recorder); Zoom is synchronous (live, billed per host). Use Loom for one-way work — walkthroughs, onboarding, reviews, async standups, client explainers — and Zoom for real-time work: debate, sensitive talks, interviews, decisions. Escalate deliberately: text → Loom → Zoom. Most teams need both; getting the async-vs-sync call right is what reclaims hours.

Build a CRM Backend on Notion's API in 2026: $5/Month Stack with Node.js

TrackStack — Sat, 06 Jun 2026 16:02:01 +0000

The full version of this article teaches non-developers how to configure Notion's UI into a working CRM. This is the developer take: don't configure the UI — automate around the API. I run a small-business CRM stack on Notion for ~$5/month total infrastructure (Notion Free + a $6 VPS for cron jobs and webhooks). Below is the actual code, the rate-limit math, and where this breaks down.

If you're a non-dev founder, read the full version for the UI-first setup. If you're a developer who wants to skip the SaaS subscription and own your stack, this is for you.

The architecture

[Website form]
    ↓ webhook
[Node.js receiver on VPS]
    ↓ Notion API
[Notion databases: Contacts, Deals, Activities]
    ↓ Notion webhooks
[Slack notifier on stage change]

[Cron @ 9am daily]
    ↓ Notion API
[Stale lead detector → Slack DM]

Four small services, all talking to Notion as the data layer. No CRM subscription. No Zapier monthly fee. ~80 lines of Node.js total. The actual CRM "logic" lives in your code, not in someone else's billing engine.

Step 1: Website form → Notion contact

Create a Notion integration at notion.so/profile/integrations, copy the secret, and share your Contacts database with it. Database ID comes from the URL (the 32-char hex after the workspace name).

import { Client } from '@notionhq/client';
import express from 'express';
import crypto from 'crypto';

const notion = new Client({ auth: process.env.NOTION_TOKEN });
const CONTACTS_DB = process.env.NOTION_CONTACTS_DB_ID;

const app = express();
app.use(express.json());

app.post('/lead', async (req, res) => {
  // Verify the source — your form should sign the payload
  const sig = req.headers['x-form-signature'];
  const computed = crypto
    .createHmac('sha256', process.env.FORM_SECRET)
    .update(JSON.stringify(req.body))
    .digest('hex');
  if (sig !== computed) return res.status(401).end();

  const { email, name, company, message, utm_source } = req.body;
  if (!email) return res.status(400).json({ error: 'email required' });

  // Dedupe by email — query existing first
  const existing = await notion.databases.query({
    database_id: CONTACTS_DB,
    filter: { property: 'Email', email: { equals: email } },
    page_size: 1,
  });

  if (existing.results.length) {
    // Update last-contacted on the existing contact
    await notion.pages.update({
      page_id: existing.results[0].id,
      properties: {
        'Last Contacted': { date: { start: new Date().toISOString() } },
      },
    });
    return res.json({ status: 'updated', id: existing.results[0].id });
  }

  // Create new contact
  const page = await notion.pages.create({
    parent: { database_id: CONTACTS_DB },
    properties: {
      Name: { title: [{ text: { content: name || email } }] },
      Email: { email },
      Company: { rich_text: [{ text: { content: company || '' } }] },
      Status: { select: { name: 'new lead' } },
      Source: { select: { name: utm_source || 'website' } },
      'Last Contacted': { date: { start: new Date().toISOString() } },
      Notes: { rich_text: [{ text: { content: message || '' } }] },
    },
  });

  res.json({ status: 'created', id: page.id });
});

app.listen(3000);

Drop this on a Hetzner/DO/Linode $5-6/month VPS, point your form's webhook at https://crm.yourdomain.com/lead, slap Caddy in front for TLS. Your website form now creates Notion contacts with deduplication.

The dedupe-by-email pattern is the single most useful thing here — without it, retries and double-submissions clutter your database with duplicates within a week. Always upsert.

Step 2: Notion webhook → Slack on stage change

Notion shipped first-party webhooks in late 2024 — finally usable for reactive automations. Subscribe via the API to events on your Deals database:

// One-time setup: register a webhook for the Deals database
await fetch('https://api.notion.com/v1/webhooks', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.NOTION_TOKEN}`,
    'Content-Type': 'application/json',
    'Notion-Version': '2022-06-28',
  },
  body: JSON.stringify({
    url: 'https://crm.yourdomain.com/notion-webhook',
    event_types: ['page.properties_updated'],
    filter: { database_id: process.env.NOTION_DEALS_DB_ID },
  }),
});

Then handle the events:

app.post('/notion-webhook', express.raw({ type: 'application/json' }), async (req, res) => {
  // Verify Notion's signature
  const signature = req.headers['x-notion-signature'];
  const computed = crypto
    .createHmac('sha256', process.env.NOTION_WEBHOOK_SECRET)
    .update(req.body)
    .digest('hex');
  if (signature !== `sha256=${computed}`) return res.status(401).end();

  const event = JSON.parse(req.body.toString('utf8'));

  if (event.type === 'page.properties_updated') {
    const pageId = event.entity.id;
    const page = await notion.pages.retrieve({ page_id: pageId });

    const stage = page.properties.Stage?.select?.name;
    const dealName = page.properties['Deal Name']?.title?.[0]?.plain_text;
    const value = page.properties.Value?.number;

    if (stage === 'won') {
      await fetch(process.env.SLACK_WEBHOOK_URL, {
        method: 'POST',
        body: JSON.stringify({
          text: `🎉 Deal won: *${dealName}* — $${value?.toLocaleString() || '?'}`,
        }),
      });
    }
  }

  res.status(200).end();
});

Now when anyone on your team drags a deal card to "won" in Notion, your sales channel gets a celebration message. Same pattern for "lost" with a different emoji, or "negotiation" to ping the deal owner.

The catch: Notion's webhooks fire on every property change, including bulk imports. If you update 50 deals in a script, you'll get 50 webhook calls. Add idempotency (track recently-seen event IDs in Redis or a sqlite file) and rate-limit your Slack notifications client-side.

Step 3: Stale lead detector (the cron that actually saves leads)

The single most valuable automation: a daily check for leads who haven't been contacted in 30+ days. This is what a real CRM does automatically; we'll build it in 30 lines:

// stale-leads.js — run via cron @ 9am daily
import { Client } from '@notionhq/client';

const notion = new Client({ auth: process.env.NOTION_TOKEN });
const THIRTY_DAYS_AGO = new Date(Date.now() - 30 * 86_400_000).toISOString();

async function findStaleLeads() {
  const stale = [];
  let cursor = undefined;

  do {
    const res = await notion.databases.query({
      database_id: process.env.NOTION_CONTACTS_DB_ID,
      filter: {
        and: [
          { property: 'Status', select: { equals: 'new lead' } },
          { property: 'Last Contacted', date: { before: THIRTY_DAYS_AGO } },
        ],
      },
      start_cursor: cursor,
      page_size: 100,
    });
    stale.push(...res.results);
    cursor = res.has_more ? res.next_cursor : undefined;
  } while (cursor);

  return stale;
}

const stale = await findStaleLeads();

if (stale.length) {
  const lines = stale
    .slice(0, 10)
    .map((p) => {
      const name = p.properties.Name?.title?.[0]?.plain_text || 'Unnamed';
      const email = p.properties.Email?.email || '';
      const lastContacted = p.properties['Last Contacted']?.date?.start;
      return `• *${name}* (${email}) — last touched ${lastContacted}`;
    })
    .join('\n');

  await fetch(process.env.SLACK_WEBHOOK_URL, {
    method: 'POST',
    body: JSON.stringify({
      text: `☕ Morning. ${stale.length} stale leads (${stale.length > 10 ? 'top 10' : 'all'}):\n${lines}`,
    }),
  });
}

crontab -e and add 0 9 * * * /usr/bin/node /home/crm/stale-leads.js. Every morning at 9, your Slack gets a digest of leads who need a nudge.

This is genuinely transformative for a 1-3 person sales motion. The cost of forgetting a warm lead for 60 days is way bigger than the cost of running this cron.

Rate limits and pagination math

Notion's API is rate-limited to ~3 requests per second average per integration. Burst above that and you'll get rate_limited errors. Database queries return max 100 results per page; full-database scans need pagination.

For a CRM with ~500 contacts and ~100 active deals, every operation is well within limits. The numbers that matter:

Form submission: 2 API calls (query for dedupe + create/update). At 100 leads/day = 200 calls = 6,000/month.
Webhook handler: 1 API call per event (retrieve page). At 50 stage changes/day = 1,500 calls/month.
Daily stale-lead cron: ~5-10 paginated queries. ~300 calls/month.

Total: ~8,000 API calls/month. The Notion API has no hard monthly cap on free tier — just the per-second rate limit. You're effectively unlimited at this scale.

Where you'd hit limits: bulk imports (CSV migration of 10,000 contacts), aggressive polling instead of webhooks, or running this for 10+ teams off one integration. Use multiple integration tokens if you scale that far.

Where this stack breaks down

Honest list — when it's time to graduate to a real CRM:

Email integration. Notion's API doesn't have native email send/track. You can wire Postmark or SES for sending, but you're building a mini email-CRM yourself. Past ~10 sequences and >1k subscribers, use a real ESP.
Multi-step sequences. A "3 emails over 7 days" drip campaign is doable but you're maintaining state in Notion which is awkward. Tools like Customer.io exist for this.
Team scaling. Notion permissions are page-level. "Sales rep X sees only their leads" requires hacks (separate workspaces, complex view filters). Real CRMs do this in 30 seconds.
Reporting trust. Your CFO wants a forecast. You can build pipeline-value sums in Notion, but win-rate trends, MEDDIC scoring, rep performance — those are weeks of formula-and-rollup hell. Buy a CRM.

For graduation paths, our Pipedrive vs HubSpot for B2B comparison and best CRM for small business roundup are the natural reads.

The full stack: Notion (Free) + $5-6/month VPS + Caddy + ~80 lines of Node.js. Total infra: ~$5-10/month.
What you get: dedup-on-submit, webhook-driven Slack notifications, stale-lead detection. The 90% of a real CRM that actually matters.
What you don't get: native email, sequences, sales-team reporting, deliverability tracking. Build these and you're rewriting HubSpot.
When it breaks: past 500 contacts + email-heavy workflows + 5+ team members. Graduate at that point — don't fight it.

The pattern generalises beyond CRM. Notion API + small Node.js services replaces a lot of $30-100/month SaaS subscriptions for early-stage businesses. The trade is: you own the stack, you maintain it, and one bug at 2 AM is yours to fix. For dev-founders who like that trade, it's a great deal.

Originally published on trackstack.tech with the UI-first setup walkthrough and FAQ.

Build Your Own 'Notion AI' for $1/month: Notion API + OpenAI in 50 Lines

TrackStack — Fri, 05 Jun 2026 05:37:50 +0000

I was paying $20/month for ChatGPT Plus and considering Notion AI Business ($20/user/month) to get the workspace-aware AI features. Then I did the math: Notion's API is free, OpenAI's gpt-4o-mini is $0.15 per million input tokens, and my actual usage is ~5,000 input tokens per query. That's $0.00075 per "ask your notes" call. Even at 100 queries a month, I'd spend less than a dollar in API costs.

This is the build-vs-buy take the SaaS comparison sites won't write. Below is the 50-line implementation, the real token math, where the DIY approach breaks down, and when to just pay the $20.

For the SMB-perspective comparison (no code, full pricing breakdown, the 2025-2026 Notion AI restructuring), the full version of this article covers the non-developer angle.

The build-it-yourself stack

Three pieces:

Notion API for the data layer — read your pages and their content. Free, well-documented, rate-limited at ~3 req/sec.
OpenAI API (or Anthropic) for the AI layer — send your notes as context, get answers. Cheap per token if you stay on gpt-4o-mini or claude-3-5-haiku.
A glue function that combines them. ~50 lines, no framework needed.

You replace "what Notion AI does" (workspace Q&A, summarisation, autofill) with code you own. You lose: the polished UI, inline rendering inside Notion pages, Custom Agents. You gain: ~95% lower cost, full prompt control, choice of model, and your data stops going through Notion's AI pipeline.

Step 1: Pull notes from Notion

Create a Notion integration at notion.so/profile/integrations, share the pages you want to query with it, set the token as NOTION_TOKEN:

import { Client } from '@notionhq/client';

const notion = new Client({ auth: process.env.NOTION_TOKEN });

async function fetchRecentPages(limit = 20) {
  const res = await notion.search({
    filter: { value: 'page', property: 'object' },
    sort: { direction: 'descending', timestamp: 'last_edited_time' },
    page_size: limit,
  });

  return Promise.all(
    res.results.map(async (page) => {
      const blocks = await notion.blocks.children.list({ block_id: page.id });
      const content = blocks.results.map(extractText).filter(Boolean).join('\n');
      return { id: page.id, title: getTitle(page), content };
    })
  );
}

function extractText(block) {
  const type = block.type;
  const rich = block[type]?.rich_text;
  if (rich) return rich.map((r) => r.plain_text).join('');
  return '';
}

function getTitle(page) {
  const titleProp = Object.values(page.properties).find((p) => p.type === 'title');
  return titleProp?.title?.[0]?.plain_text || 'Untitled';
}

Real caveats: the API returns blocks one level deep by default — nested blocks (toggles, callouts) need recursive fetching. Long pages with many blocks hit rate limits if you parallelise too aggressively. For 50+ pages, throttle to ~3 parallel requests.

Step 2: Send notes as context to an LLM

import OpenAI from 'openai';

const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

async function askYourNotes(question, pages) {
  // Naive truncation — fine for ~50 pages, use embeddings beyond that
  const context = pages
    .map((p) => `# ${p.title}\n${p.content.slice(0, 2000)}`)
    .join('\n\n---\n\n');

  const completion = await openai.chat.completions.create({
    model: 'gpt-4o-mini',
    messages: [
      {
        role: 'system',
        content:
          'Answer using ONLY the user notes provided. Cite page titles when relevant. If the answer is not in the notes, say so.',
      },
      {
        role: 'user',
        content: `My notes:\n\n${context}\n\nQuestion: ${question}`,
      },
    ],
  });

  return completion.choices[0].message.content;
}

// Use it
const pages = await fetchRecentPages(30);
const answer = await askYourNotes('What did I decide about the Q4 roadmap?', pages);
console.log(answer);

That's the entire workspace-Q&A loop. Drop it in a CLI tool, a Slack bot, or an internal web app. Now you have what Notion AI does, minus the inline rendering.

Anthropic version if you prefer Claude:

import Anthropic from '@anthropic-ai/sdk';

const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });

const message = await anthropic.messages.create({
  model: 'claude-3-5-haiku-latest',
  max_tokens: 1024,
  messages: [
    { role: 'user', content: `Notes:\n\n${context}\n\nQuestion: ${question}` },
  ],
});
console.log(message.content[0].text);

Both work. OpenAI's gpt-4o-mini is the cheaper option per token; Claude's Haiku is slightly more expensive but I find its summaries more concise.

Step 3: The token math that justifies this

Per query:

Input: ~5,000 tokens of notes context + ~50 tokens of question + system prompt
Output: ~500 tokens of answer
gpt-4o-mini: 5,000 × $0.15/1M + 500 × $0.60/1M = $0.001 per query
claude-3-5-haiku: 5,000 × $0.80/1M + 500 × $4/1M = $0.006 per query

At realistic usage:

100 queries/month: $0.10 (OpenAI) or $0.60 (Anthropic)
1,000 queries/month: $1 (OpenAI) or $6 (Anthropic)

Compared to:

Notion AI Business: $20/user/month
ChatGPT Plus: $20/month

The gap is 95-99% cheaper for OpenAI, 70-95% for Anthropic. Even at 5,000 queries/month (which is a lot) you're under $5 on OpenAI.

The catch: these numbers assume you're stuffing ~5,000 tokens of context per query. If you scale to a 500-page workspace and want full coverage, you need embeddings — embed each page once with text-embedding-3-small ($0.02/1M tokens, basically free), store in pgvector or sqlite-vss, retrieve the top-N relevant pages per query. Adds maybe an hour of setup; cost stays under $5/month for personal use.

Where the SaaS subscriptions still win

Honest list — when paying for Notion AI Business or ChatGPT Plus is worth it:

Inline rendering inside Notion. "AI block" that lives in the page, autofill in databases, summarise-on-the-page. You can't replicate this experience with an external script.
Polished UI for non-developers. If you're recommending a tool to colleagues who don't write code, the SaaS UX wins.
ChatGPT Pro's deep research, voice, image, web search. None of these are workspace-aware AI features — they're separate value. ChatGPT Plus at $20 buys you the model + all those general-purpose AI features, not just note-taking.
Custom Agents (Notion's 2026 feature). If your workflow depends on agents that act on Notion data over time, the official integration is more reliable than DIY orchestration.
No infra to maintain. A $20/month SaaS bill is one line of book-keeping. Your DIY script needs a host, API keys to rotate, and occasional debugging.

The honest framing: the SaaS pricing is mostly product, not raw AI compute. You pay for the UI, the integration, and someone else maintaining it.

ChatGPT's Notion connector — when to just use it

If you don't want to write code but also don't want to pay for Notion AI Business, ChatGPT Plus ($20/month) added a Notion connector in 2025 that lets it read your workspace. From inside ChatGPT, you can ask questions about your notes and it pulls relevant context.

Pros: zero setup beyond OAuth, works with all of ChatGPT's other features (web search, file analysis, image), uses GPT-5/4o quality.

Cons: sends your notes to OpenAI for processing (data residency concern for some), works one-way (ChatGPT reads Notion, doesn't write back), the retrieval can miss pages you'd expect it to find.

For a single user who already has ChatGPT Plus, the connector is the cheapest "good enough" option. For a team needing workspace-aware AI without paying Notion AI Business per seat, the DIY approach above scales better.

Notion AI Business ($20/user/mo) and ChatGPT Plus ($20/mo) both solve workspace-aware AI, at the same price point, very differently.
You can wire Notion API + OpenAI gpt-4o-mini for ~$1/month of actual API costs. ~50 lines of code, no framework.
Pay for the SaaS when inline rendering, polished UI, or Custom Agents matter more than the 95% cost saving.
ChatGPT's Notion connector is the middle ground if you have Plus already and don't want to code.
For teams of 5+ doing real note-taking AI work, DIY is genuinely $20–95/month cheaper than Notion AI Business at scale. Build it once, share across the team.

The pattern generalises beyond Notion — Linear API + OpenAI, Asana API + OpenAI, Slack API + OpenAI. Most "AI for $tool" SaaS features can be assembled from $tool's API plus a few cents of tokens per query. Worth knowing before you sign a recurring SaaS contract for a feature you could own.

Originally published on trackstack.tech with the full SMB comparison including pricing reality and use cases.

Asana vs Monday for Developers: GraphQL, REST, and the Pricing Trap

TrackStack — Wed, 03 Jun 2026 05:41:28 +0000

Most "Asana vs Monday" comparisons fight over pricing tiers and UI polish. For developers integrating with either, the more interesting question is: what does the API actually look like, and what's it like to maintain code against it?

Short answer: Monday has GraphQL, Asana has REST, and that single architectural choice changes how you'll build on each. Below is the developer-facing comparison the SaaS review sites skip — with code samples, webhook patterns, and the per-seat math you only feel once your integration is in production.

The API: GraphQL vs REST, and why it matters

Monday: one of the few PM tools with a real GraphQL API

Monday's v2 API is GraphQL. Single endpoint, you write the query, you get back exactly the shape you asked for. Creating an item with column values:

const query = `
  mutation CreateItem(
    $boardId: ID!,
    $itemName: String!,
    $columnValues: JSON
  ) {
    create_item(
      board_id: $boardId,
      item_name: $itemName,
      column_values: $columnValues
    ) {
      id
      name
      column_values { id text }
    }
  }
`;

const res = await fetch('https://api.monday.com/v2', {
  method: 'POST',
  headers: {
    Authorization: process.env.MONDAY_API_TOKEN,
    'Content-Type': 'application/json',
    'API-Version': '2024-10',
  },
  body: JSON.stringify({
    query,
    variables: {
      boardId: 1234567890,
      itemName: 'Review Q4 reports',
      columnValues: JSON.stringify({
        status: { label: 'In Progress' },
        person: { personsAndTeams: [{ id: 12345, kind: 'person' }] },
        date: { date: '2026-12-15' },
      }),
    },
  }),
});

What you get for free with GraphQL:

Introspection. Hit the endpoint with an IntrospectionQuery and you discover the entire schema — every board type, column type, every relationship. No "guess the field name" guessing.
Single-request fetches. Need an item plus its board plus its column values plus its updates? One query. Asana would be 3-4 sequential REST calls.
Typed responses. With a code generator (graphql-codegen), you get TypeScript types matching your queries.

What's painful:

column_values requires JSON-in-JSON-string. That JSON.stringify inside JSON.stringify is a real quirk — Monday wants each column's config as a stringified JSON inside the main GraphQL payload. Easy to forget the inner stringification and silently send broken data.
Mutations don't always echo back the latest state. You'll often need a follow-up query to confirm the write took.
Rate limit: 5,000,000 complexity points per minute sounds generous, but each query has a "complexity cost" that scales with depth. A nested boards { items { column_values } } query on 50 items can chew through 10,000+ points per call.

Asana: well-organised REST, but it's REST

Asana's API is REST, follows reasonable conventions, returns predictable JSON. Same task creation:

const res = await fetch('https://app.asana.com/api/1.0/tasks', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.ASANA_TOKEN}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    data: {
      projects: ['1234567890'],
      name: 'Review Q4 reports',
      due_on: '2026-12-15',
      assignee: 'me',
      custom_fields: {
        '9876543210': '1', // field ID + enum value, pre-known
      },
    },
  }),
});

Cleaner-looking on first glance. The catches show up over time:

Custom fields require pre-fetched IDs. You hit /projects/{id}/custom_field_settings once to discover field IDs, then cache them, then reference by ID. There's no equivalent to GraphQL introspection — the schema is documented but not queryable.
Over-fetching. REST gives you whole objects. Need a task's name plus its assignee? You get the whole task object plus a partial assignee object. Three separate calls if you want the assignee's full profile.
Pagination via offset cursor. Standard, max 100 per page. Listing 5,000 tasks is 50 sequential calls.
Rate limit: 1,500 reads/minute, 150 writes/minute per token. Reasonable for normal apps; you'll throttle on bulk operations.

Which API wins for your case

If you're building heavy custom integrations — dashboards that aggregate across projects, sync engines that mirror PM data into your own DB, multi-source reports — Monday's GraphQL is genuinely nicer to work with. The introspection alone saves hours, and the single-call multi-resource fetch saves rate-limit budget.

If you're building simple "create a task when X happens" automations, Asana's REST is fine and the docs are slightly more beginner-friendly. GraphQL has a learning curve; REST is universal.

Webhooks: both work, both have quirks

Both platforms support outbound webhooks. Both sign payloads. Both require a handshake on subscription (Asana sends an X-Hook-Secret you echo back; Monday sends a challenge you respond to).

// Asana webhook handler with signature verification
import express from 'express';
import crypto from 'crypto';

const app = express();

app.post('/asana-webhook', express.raw({ type: 'application/json' }), (req, res) => {
  // Handshake on first call
  const handshakeSecret = req.headers['x-hook-secret'];
  if (handshakeSecret) {
    res.setHeader('X-Hook-Secret', handshakeSecret);
    return res.status(200).end();
  }

  // Normal event — verify signature
  const sig = req.headers['x-hook-signature'];
  const computed = crypto
    .createHmac('sha256', process.env.ASANA_WEBHOOK_SECRET)
    .update(req.body)
    .digest('hex');

  if (sig !== computed) return res.status(401).end();

  const events = JSON.parse(req.body.toString('utf8')).events;
  for (const event of events) {
    // event.resource.gid is the task/project ID
    // event.action is 'added', 'changed', 'removed'
    handleEvent(event);
  }

  res.status(200).end();
});

Differences worth knowing:

Asana groups events. One webhook call can contain multiple events for the same resource. Process all of them.
Monday sends one event per call. Simpler but more webhook calls.
Neither replays failed webhooks reliably. Build idempotency keys into your handler — store recent event IDs and skip duplicates.
Monday's webhook subscription is via API only, not UI. Asana lets you create via UI or API.

The custom apps story

If you want to build a UI extension that lives inside the PM tool — not just an external app calling the API — the platforms diverge sharply.

Monday Apps Framework is a real platform. You can build:

Board views (custom React components that render inside a board tab)
Item views (custom panels in the side modal)
Dashboard widgets
Integrations (with their integration recipe DSL)
AI Assistants (Monday's recent push)

Apps are written in React, deployed to Monday's marketplace, and can earn revenue. The framework is opinionated but powerful.

Asana app integrations are simpler: OAuth-based external apps that show up in the integration directory. You don't render inside Asana; you call its API and integrate through standard hooks. Easier to build, less native-feeling.

If your product idea is "a feature that lives inside a PM tool," Monday is the more developer-friendly platform. If it's "a tool that talks to a PM tool," Asana is fine.

The hidden cost: AI integration math

This is the part the WordPress version covers in detail, but it bleeds into integration design.

Asana bundles AI Studio (50,000 credits/month) with Starter. If you're building a workflow that includes AI summarisation or smart fields, those credits cover your usage without separate billing.
Monday charges per AI credit (~$0.01 each on annual plans). If your integration triggers AI-powered automations frequently, the AI bill scales linearly with usage on top of seats.

For automation-heavy integrations, this matters: a Monday workflow that runs 10,000 AI-powered events per month adds ~$100/month at scale. Asana's bundled credits absorb the same usage at no marginal cost. If your customers will be running AI-heavy workflows through your integration, Asana's pricing model is friendlier.

Self-host alternatives, briefly

If you're API-shopping because you're tired of per-seat pricing, two open-source options worth knowing:

Plane — JIRA-like, modern stack, REST API. We covered the Docker compose setup in the ClickUp developer review.
Vikunja — kanban/list focused, simpler setup. Docker compose in our PM tools for remote dev teams post.

Trade-off: neither has GraphQL. Both have REST APIs that are competent but not exceptional. The win is you own your data and don't pay per seat.

TL;DR for developers

Monday wins on API quality. GraphQL, introspection, single-request fetches, real apps framework. The 5M complexity-points-per-minute rate limit is generous if you query carefully.
Asana wins on simplicity and beginner DX. REST, clean docs, fewer pricing-model variables (no AI per-credit math).
Both have decent webhooks. Build idempotent handlers regardless.
Hidden cost driver: Monday's AI per-credit pricing adds variable cost to AI-heavy integrations. Asana's bundled AI absorbs the same load.
For building UI extensions: Monday's apps framework is the more developer-first platform. Asana's app ecosystem is external-only.
If you have 1-2 paid users, Asana wins on cost regardless (Monday's 3-seat minimum hurts here). If you have 5+, the choice is more about API philosophy than dollars.

For the SMB-perspective comparison (without the API lens — seat-minimum math, AI credit pricing, visual customization vs task management), see the WordPress version of this article.

Originally published on trackstack.tech with the full SMB pricing breakdown and FAQ.

PM Tools for Remote Dev Teams 2026: APIs, GitHub Integration, and Self-Host

TrackStack — Mon, 01 Jun 2026 06:12:08 +0000

I've run remote engineering teams on four different PM tools across the last five years — Jira, Linear, ClickUp, and GitHub Projects. This is the opinionated take I'd give a CTO friend asking "which one in 2026?" The WordPress version of this piece covers all 10 tools for general SMB; this is the dev-team subset and the API math that actually matters when you're going to script around it.

The dev-team criteria that override "feature count"

Keyboard speed. Devs leave PM tools that take 3 seconds to load a board. Linear, GitHub, and Plane fit. ClickUp, Notion, Jira don't, even after their 2024-2025 speed improvements.
API quality. If you can't script standups, auto-create issues from CI failures, and sync tickets to a Slack bot, the tool will be abandoned in 6 months.
GitHub/GitLab integration. Real bidirectional — branch names linked to issues, PR status visible on the issue card, merge → close the ticket. Not "we have a Zapier zap."
Markdown everywhere. Tickets, comments, descriptions. If the tool has its own document format (looking at you, Atlassian Document Format), the friction compounds daily.
Self-host option. Not required, but it's a tiebreaker for teams paranoid about data lock-in or just budget-conscious at scale.

That's the rubric. Now the contenders.

Linear — the dev favourite, and it earns it

$10/user/month. The fastest tool in the category — sub-100ms navigation, every action keyboard-accessible, beautifully designed. The GraphQL API is first-class with a typed SDK:

import { LinearClient } from "@linear/sdk";

const linear = new LinearClient({ apiKey: process.env.LINEAR_API_KEY });

// Create an issue from a CI failure
async function reportCIFailure(workflow: string, runUrl: string, error: string) {
  const team = await linear.team("ENG");

  return linear.createIssue({
    teamId: team.id,
    title: `CI failed: ${workflow}`,
    description: `Run: ${runUrl}\n\n\`\`\`\n${error.slice(0, 1000)}\n\`\`\``,
    priority: 2, // High
    labelIds: [(await linear.issueLabels({ filter: { name: { eq: "ci" } } })).nodes[0].id],
  });
}

15 lines and you have CI-to-Linear in any language with a GraphQL client. The SDK is well-typed; the docs are good; the rate limits are generous (1,500 req/hour authenticated).

Where Linear loses: it's engineering-only by design. Marketing and ops will feel cramped, and you can't bolt them on. If your dev team works closely with non-dev colleagues, Linear's purity becomes a wall. Also: $10/user × 50 people × 12 months = $6,000/year. Not bad, but not free.

Jira — only if you're forced into it

$7.75/user/month (Standard). The enterprise software default. It does sprints, backlogs, reporting, and compliance dashboards at a depth Linear can't match. The pain is everything else.

// Same "create issue from CI failure" in Jira REST
async function reportCIFailureJira(workflow: string, runUrl: string, error: string) {
  const res = await fetch(`${JIRA_HOST}/rest/api/3/issue`, {
    method: "POST",
    headers: {
      Authorization: `Basic ${Buffer.from(`${EMAIL}:${API_TOKEN}`).toString("base64")}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      fields: {
        project: { key: "ENG" },
        summary: `CI failed: ${workflow}`,
        // ADF, not markdown. This is one paragraph.
        description: {
          type: "doc",
          version: 1,
          content: [
            { type: "paragraph", content: [{ type: "text", text: `Run: ${runUrl}` }] },
            {
              type: "codeBlock",
              attrs: { language: "text" },
              content: [{ type: "text", text: error.slice(0, 1000) }],
            },
          ],
        },
        issuetype: { name: "Task" },
        priority: { name: "High" },
      },
    }),
  });
  // ...
}

Atlassian Document Format (ADF) is the API equivalent of a tax return. Every formatting decision becomes a tree of typed nodes. Markdown converters exist but they're approximate. Add OAuth refresh logic, multi-step issue type configuration, custom fields with cryptic IDs, and a rate limit you have to look up per endpoint, and integration time triples vs Linear.

Pick Jira when: you're on a team where it was picked for you, or you genuinely need its compliance/audit features. Otherwise, the speed and DX gap with Linear is unbridgeable.

GitHub Projects — the underrated pick

Free with any GitHub account. GitHub Projects v2 (the new one, GraphQL-based) is a real PM tool — tables, boards, roadmap, custom fields, automations — built into the place your code already lives. The mutation to add an issue to a project:

mutation AddIssueToProject($projectId: ID!, $contentId: ID!) {
  addProjectV2ItemById(input: { projectId: $projectId, contentId: $contentId }) {
    item { id }
  }
}

The integration is unbeatable because there's no integration — your PRs, issues, commits, and project board are one system. Closing an issue via PR is one line in the commit message; sprint velocity is calculated from real merge timestamps; the project board updates as you push code.

Where it loses: docs are sparse (use the GraphQL Explorer to discover the schema), the UI is less mature than Linear or ClickUp, and it has no built-in standup or time-tracking. For pure engineering work with a small team (≤15), it's surprisingly enough. For larger teams or anything beyond engineering, you'll outgrow it.

ClickUp — the cheap all-in-one for mixed teams

$7/user/month (Unlimited), +$9/user for AI. Worth considering when your team is not engineering-only — when one platform has to serve devs, designers, marketing, and ops. The REST API is decent; webhooks have quirks (we covered them in the ClickUp developer review). For a dev-only team, Linear wins. For a 30-person remote SMB where dev is 8 people and the rest are ops/marketing, ClickUp at $7 beats running Linear for engineering plus something else for everyone else.

Notion — the docs-plus-tasks hybrid

$10/user/month. Notion isn't a PM tool, it's a documents tool that grew a database feature. For dev teams that live in design docs, RFCs, ADRs, and runbooks, Notion's "context next to task" beats a dedicated PM tool. The API is RESTful, the schema-via-property-types approach is workable but verbose, and the rate limits will hit you on bulk operations. Best as the docs layer next to Linear or GitHub, not as the primary task tool.

Self-hosted: when SaaS prices stop making sense

For 50+ user teams, the math shifts. Linear at $500/month becomes uncomfortable; Jira's per-user fees keep growing. Two self-hosted alternatives worth knowing in 2026:

Plane — modern, JIRA-like, the strongest open-source option. We covered the Docker compose setup in the ClickUp developer post.

Vikunja — simpler, kanban/list-focused, two-service setup:

# docker-compose.yml — Vikunja self-hosted
services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: ${PG_PASSWORD}
      POSTGRES_USER: vikunja
      POSTGRES_DB: vikunja
    volumes:
      - vikunja-db:/var/lib/postgresql/data

  vikunja:
    image: vikunja/vikunja:latest
    restart: unless-stopped
    ports:
      - "3456:3456"
    environment:
      VIKUNJA_DATABASE_TYPE: postgres
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_PASSWORD: ${PG_PASSWORD}
      VIKUNJA_DATABASE_DATABASE: vikunja
      VIKUNJA_SERVICE_PUBLICURL: https://vikunja.yourdomain.com
      VIKUNJA_SERVICE_JWTSECRET: ${JWT_SECRET}
    volumes:
      - vikunja-files:/app/vikunja/files
    depends_on:
      - db

volumes:
  vikunja-db:
  vikunja-files:

Drop it on a $6 VPS, point a subdomain, slap Caddy in front for TLS, and you have a no-monthly-fee PM tool with a real REST API, native sharing, and Kanban/list/Gantt views. Trade-offs: no native GitHub integration (you write webhooks yourself), no advanced sprint reporting, and the community is smaller than Plane's. Worth it for small engineering teams who like owning their stack.

The honest reality of self-hosting: budget 2-4 hours/month for backups, updates, and the occasional firefight. That's ~$50-100/month in your time at consultant rates. The self-host wins when team size × SaaS per-seat cost crosses ~$200/month, not before.

Mistakes devs make picking PM tools

Optimising for features instead of adoption. The best tool is the one your team will actually update. Linear is loved because devs find updating it pleasant; Jira is hated because every interaction feels like paperwork. If your team won't update the tool, you don't have a PM tool — you have a graveyard.

Falling for "all-in-one" pitches. ClickUp's "replace 10 tools!" is genuine value for non-dev SMBs. For dev teams, you'll spend 6 months configuring it to feel like Linear, then switch to Linear. Specialised wins for technical workflows.

Ignoring the AI add-on math. ClickUp Brain is $9/user/mo extra; Notion AI is bundled but capped; Jira AI is enterprise-tier only. If "AI features" are in the pitch, calculate the real cost — your team's existing ChatGPT/Claude Pro subs may already cover 80% of what the in-tool AI does.

Underestimating webhook reliability cost. Every integration ("PR opened → create issue") needs retry logic, signature verification, and idempotency. Linear's webhooks are clean; Jira's are powerful but quirky; GitHub's are battle-tested; ClickUp's are workspace-scope-only. Build resilient handlers regardless.

TL;DR

Engineering-only, 2-50 people, latency matters more than budget: Linear.
Engineering-only, on a shoestring, already using GitHub heavily: GitHub Projects.
Forced to use Jira by org/regulation: at least lobby for Linear sync via API.
Mixed team (dev + non-dev) at SMB: ClickUp Unlimited, accept the speed hit.
Docs-first team where work emerges from RFCs: Notion + GitHub Projects.
50+ people, want to own the stack: Plane (JIRA-like) or Vikunja (simpler).

For the broader 10-tool comparison covering Asana, Monday, Trello, Basecamp, Wrike, and Height (the tools more relevant to non-dev SMBs), see the WordPress version of this piece.

Originally published on trackstack.tech with the full 10-tool comparison and FAQ.

ClickUp from a Developer's Perspective in 2026: API, Webhooks, and the Self-Host Question

TrackStack — Wed, 27 May 2026 08:49:48 +0000

I built a custom team dashboard on top of ClickUp's API for 6 months in 2025–2026. Three things I wish someone had told me before starting, then a tour of the API, webhooks, the Brain AI gap, and the self-hosted alternative I keep recommending to people who ask.

The three-bullet honest take

ClickUp the product is genuinely useful if your team needs tasks + docs + dashboards in one place. At $7/user/month on Unlimited, it's cheaper than Linear, Asana, or Monday.
ClickUp the API is OK. REST endpoints, predictable shapes for tasks/lists/spaces, but the docs have gaps and the webhook subsystem is quirky. You'll write more glue code than you'd expect.
ClickUp the AI ("Brain") is a $9/user/month add-on with limited API surface. If you want to extend AI workflows programmatically, you're mostly better off calling OpenAI/Anthropic directly with ClickUp as the data source.

If you came here looking for "ClickUp vs Notion vs Linear" for your team, the WordPress version of this piece has the full SMB comparison. This post is for engineers building on the platform or weighing its API against alternatives.

The API: better than Jira, worse than Linear

ClickUp's REST API uses a personal token or OAuth, returns JSON, and follows reasonable conventions. Creating a task takes one POST:

import fetch from "node-fetch";

const CLICKUP_TOKEN = process.env.CLICKUP_TOKEN;
const LIST_ID = "901234567"; // from the URL or /list endpoint

async function createTask(name, description, customFields = {}) {
  const res = await fetch(
    `https://api.clickup.com/api/v2/list/${LIST_ID}/task`,
    {
      method: "POST",
      headers: {
        Authorization: CLICKUP_TOKEN,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        name,
        description,
        status: "open",
        priority: 2, // 1=urgent, 2=high, 3=normal, 4=low
        custom_fields: Object.entries(customFields).map(([id, value]) => ({
          id,
          value,
        })),
      }),
    }
  );

  if (!res.ok) {
    throw new Error(`ClickUp API ${res.status}: ${await res.text()}`);
  }
  return res.json();
}

Works. Custom fields use a separate sub-resource — you fetch the field IDs from the list endpoint once, store them, and reference them when creating/updating tasks. The schema discovery dance feels old-school but it's not slow.

What's painful:

Pagination uses page parameter, max 100 items per page, no cursor. Listing 5,000 tasks is 50 sequential calls with rate limits.
Rate limits are 100 req/minute per token. Fine for normal apps; you'll throttle on bulk imports.
API v2 vs internal API. The official v2 covers most operations. Some features (specific automation actions, certain Brain operations, advanced reporting) only exist in the un-documented internal API, which the official docs don't acknowledge. Don't build on it — it changes without notice.
Time tracking endpoints are split awkwardly between /team/{id}/time_entries and /task/{id}/time and don't always return matching shapes.

Webhooks: powerful but quirky

ClickUp webhooks fire on events at the workspace ("team") level. You subscribe via API, not the UI, and you point them at your HTTPS endpoint. A minimal handler:

import express from "express";
import crypto from "crypto";

const app = express();

// IMPORTANT: raw body for signature verification
app.post(
  "/clickup-webhook",
  express.raw({ type: "application/json" }),
  (req, res) => {
    const signature = req.headers["x-signature"];
    const secret = process.env.CLICKUP_WEBHOOK_SECRET;

    const computed = crypto
      .createHmac("sha256", secret)
      .update(req.body)
      .digest("hex");

    if (signature !== computed) {
      return res.status(401).end();
    }

    const event = JSON.parse(req.body.toString("utf8"));

    switch (event.event) {
      case "taskCreated":
        handleNewTask(event.task_id);
        break;
      case "taskUpdated":
        handleTaskChange(event.task_id, event.history_items);
        break;
      // ...many more event types
    }

    res.status(200).end();
  }
);

The quirks:

Webhook payloads are minimal — usually just task_id and history_items. To get the full task, you make a separate API call. Why this is the design, I don't know. It does halve the average payload size, but it doubles your API calls.
No payload replay in the UI. If your endpoint was down, you find out from logs, not from a "resend failed webhooks" button.
Workspace ("Team") scope only. You can't subscribe to events on a specific space or list — you get all events in the workspace and filter client-side. Noisy if you only care about one project.
Signature verification is HMAC-SHA256 of the raw body. Standard but the docs example uses string concatenation that breaks if you've JSON-parsed already. Always use express.raw middleware.

The Brain AI gap

ClickUp Brain is the $9/user/month AI add-on. Inside the UI it's genuinely useful — task summaries, standup generation, AI fields that fill themselves based on rules. From the API perspective, the surface is thin. You can:

Trigger some AI actions via webhook responses to certain events.
Read AI-generated content from custom fields that have AI sources.

You cannot easily:

Run arbitrary prompts against your ClickUp data programmatically.
Use Brain credits from external systems.
Replace it with your own LLM provider while keeping the in-app AI features.

For developers extending ClickUp, the more honest pattern is: skip Brain, build your own AI layer with OpenAI/Anthropic on top of the regular ClickUp API. You pay per-call instead of per-user, you control the prompts, and you don't get billed twice for the same model providers.

// Pattern: pull task context from ClickUp, send to OpenAI, write summary back
async function summariseTasksForStandup(listId) {
  const tasks = await fetchTasksUpdatedToday(listId);
  const prompt = buildStandupPrompt(tasks);

  const summary = await openai.chat.completions.create({
    model: "gpt-4o-mini",
    messages: [{ role: "user", content: prompt }],
  });

  await postToClickUpComment(listId, summary.choices[0].message.content);
}

15 lines of glue gets you 80% of what Brain offers, at a fraction of the cost for teams of 10+.

When self-hosting beats ClickUp: Plane

If the lock-in math doesn't work for you (a 50-person team on Business + Brain is ~$1,050/month, ~$12,600/year), the strongest self-hosted alternative right now is Plane — open-source, modern stack, JIRA-like feature surface but cleaner.

# docker-compose.yml — Plane self-hosted, minimal
services:
  plane-db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=plane
      - POSTGRES_PASSWORD=${PG_PASSWORD}
      - POSTGRES_DB=plane
    volumes:
      - plane-db:/var/lib/postgresql/data

  plane-redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - plane-redis:/data

  plane-web:
    image: makeplane/plane-frontend:latest
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - NEXT_PUBLIC_API_BASE_URL=https://api.yourdomain.com
    depends_on:
      - plane-api

  plane-api:
    image: makeplane/plane-backend:latest
    restart: unless-stopped
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgres://plane:${PG_PASSWORD}@plane-db:5432/plane
      - REDIS_URL=redis://plane-redis:6379
      - SECRET_KEY=${PLANE_SECRET}
    depends_on:
      - plane-db
      - plane-redis

volumes:
  plane-db:
  plane-redis:

The reality check: Plane doesn't have docs, whiteboards, chat, time tracking, or built-in AI like ClickUp. It does sprints, projects, cycles, pages (basic), and views. For engineering-only teams, that's enough. For agencies juggling clients + content + ops, ClickUp's breadth still wins.

Other self-hosted alternatives worth knowing:

Vikunja — simpler, Trello-like
Focalboard — Mattermost's offering, decent kanban
OpenProject — older, more enterprise-flavored

When ClickUp wins for developers specifically

Despite all the above, ClickUp does some things genuinely well for technical teams:

Custom fields are a real data model. Type-safe-ish (number, dropdown, formula, relationship). You can model real domain data on top of tasks, not just "todo with notes."
The API supports almost everything the UI does. Unlike Notion, where database property edits are easier in UI than API.
OAuth flow works. You can build apps that other teams install. The Marketplace is small but the mechanism is there.
Embedded views in iframes. You can drop a ClickUp dashboard into your internal tool with one URL. Niche but useful.

If you're building internal tooling on top of a project management platform, ClickUp is a defensible choice — not the obvious winner, but workable. Linear has a cleaner GraphQL API; Notion has cleaner database semantics; ClickUp has more features per dollar and accepts more domain modelling than either.

ClickUp API: REST, works, pagination is annoying, rate-limited at 100/min, watch out for un-documented internal endpoints that aren't stable.
Webhooks: Workspace-scope only, minimal payloads, no UI replay. Build resilient handlers.
Brain AI: Limited API surface — better to skip and use OpenAI directly on top of ClickUp data.
Self-host alternative: Plane for engineering teams; ClickUp still wins if you need breadth.
Worth it for devs? As an internal-tooling platform — yes, if the team is already on ClickUp. As a greenfield choice — Linear or a self-hosted option will give you fewer headaches.

For the broader SMB-perspective comparison (pricing in detail, the hidden Brain cost, alternatives like Asana and Monday), the WordPress version of this article has the full breakdown.

Originally published on trackstack.tech with the SMB pricing analysis and FAQ.

Notion vs Obsidian for Developers: APIs, Plugins, and Why I Use Both

TrackStack — Tue, 26 May 2026 05:33:48 +0000

I keep my project tracker in Notion and my actual thinking in Obsidian. After three years of moving between the two, that split is the only sane answer I have to "which one?" — and it's mostly driven by what each tool's API and file format make easy.

This isn't another "Notion is great, Obsidian is great, depends on you!" post. It's the developer cut: what you can actually build, what locks you in, and where each tool quietly fails when you push it.

The lock-in test, before anything else

Run this thought experiment for any note-taking tool: if the company shuts down tomorrow at midnight, what's your recovery story?

Notion: You get a Markdown export. Databases collapse into flat folders, inline blocks lose fidelity, internal links break. Rebuilding a complex workspace elsewhere is a weekend job at best, "lost forever" at worst. The export technically works; the workflow that depended on it does not.
Obsidian: You already have a folder of .md files on your disk. Open it in VS Code, Logseq, Foam, or any markdown editor. You lose plugins; you don't lose data.

If portability matters to you (and as a developer, it should), Obsidian wins this round without firing a shot. Whether that's enough to outweigh everything else is the rest of this post.

Notion's API: programmable, well-documented, rate-limited

Notion's REST API is genuinely good. It's the rare SaaS API where the docs match the behaviour. Adding a page to a database is straightforward:

import { Client } from "@notionhq/client";

const notion = new Client({ auth: process.env.NOTION_TOKEN });

await notion.pages.create({
  parent: { database_id: process.env.NOTION_DB_ID },
  properties: {
    Name: { title: [{ text: { content: "New idea" } }] },
    Status: { select: { name: "Inbox" } },
    Created: { date: { start: new Date().toISOString() } },
    Tags: { multi_select: [{ name: "research" }, { name: "ai" }] },
  },
});

This means you can build real automations: cron jobs that scrape an RSS feed into a Notion reading list, Slack bots that capture quotes, scripts that batch-import old notes. The API rate-limits at ~3 req/sec average per integration — fine for personal use, painful for bulk operations.

What you can't easily do via the API: full-text search across pages (limited), edit specific blocks deep inside a page (clunky), or react to page changes (webhooks exist but only for selected events). For "push data in" the API is great; for "pull data out and process" it's workable; for "react to edits" you're polling.

Obsidian's plugin API: TypeScript, local-first, no rate limits

Obsidian isn't a SaaS — it's a local app — so there's no REST API. Instead, you write plugins in TypeScript that run inside the app. Minimal plugin that adds a command:

import { Plugin, Notice } from "obsidian";

export default class StampPlugin extends Plugin {
  async onload() {
    this.addCommand({
      id: "insert-timestamp",
      name: "Insert ISO timestamp",
      editorCallback: (editor) => {
        editor.replaceSelection(new Date().toISOString());
      },
    });

    this.addRibbonIcon("clock", "Stamp the page", () => {
      new Notice(`Vault path: ${this.app.vault.adapter.getName()}`);
    });
  }
}

The plugin API exposes everything: read/write files in the vault, register commands, hook into edit events, build settings UIs, render custom views, traverse the link graph. The community has 1,500+ published plugins because the API is approachable.

The flip side: there's no way to interact with Obsidian from outside the app. If you want a cron job to add notes to your vault, you write directly to the markdown files on disk (or use a sync provider as the intermediary). That's not a bug — it's the philosophy. Obsidian doesn't own your data, so it doesn't need an API to give it back.

Where each one wins for developers

Notion wins on structured data. Databases with typed properties, filtered views, and rollups give you something close to a personal Airtable. If your "knowledge" includes things like a reading list with status/rating, a content calendar, a CRM-ish contact log, or a project tracker with kanban — Notion handles these in 5 minutes. Trying to recreate the same in Obsidian needs the Dataview plugin and custom query syntax.

Obsidian wins on text. Plain markdown means every other tool in your stack already speaks the format — VS Code, Git, GitHub, pandoc, your shell. Want to grep across 10,000 notes?

# Find every note that mentions "kubernetes" in your vault
rg -i "kubernetes" ~/vault --type md

# All notes modified in the last 7 days
find ~/vault -name "*.md" -mtime -7

# Word count across the entire vault
find ~/vault -name "*.md" -exec wc -w {} + | tail -1

You can't do any of this against Notion without using their API and burning rate-limit budget. For developers who already live in the terminal, this is genuinely transformative.

The split that actually works

After years of trying to pick one, here's what I run in 2026:

Notion for structured projects. Content calendar, client tracker, weekly review, OKRs. Anything that benefits from "show me the kanban / show me the calendar / show me the filtered list of overdue items."
Obsidian for thinking. Daily notes, research, code-related notes, journal, longform drafts, anything that grows by linking to other things.
Resist the urge to sync them. I tried for a year. Every sync solution adds more failure modes than it solves. The two tools work better as separate brains for separate jobs.

The total cost is ~$50/year for Obsidian Sync (Notion Personal Free is plenty for my project tracking). Cheaper than any all-in-one solution that does both jobs worse.

A migration script that's actually useful

If you're considering moving from Notion → Obsidian, the export gives you a Markdown zip — but it's gnarly. Page IDs in filenames, broken internal links, embedded databases as inline tables. A small Python pass cleans most of it:

# notion-to-obsidian.py — quick cleanup pass on Notion's markdown export
import re
from pathlib import Path

EXPORT = Path("./notion-export")
OUT = Path("./obsidian-vault")
OUT.mkdir(exist_ok=True)

# Notion filenames: "Page Title abc123def456789012345678901234.md"
NOTION_ID = re.compile(r"\s+[a-f0-9]{32}(\.md)?$")

# Notion internal links: "[Title](Title%20abc123...md)"
LINK = re.compile(r"\[([^\]]+)\]\([^)]+%20[a-f0-9]{32}[^)]*\)")

for md in EXPORT.rglob("*.md"):
    # Clean filename
    clean_name = NOTION_ID.sub(".md", md.name)

    # Read, rewrite internal links to wiki-style
    text = md.read_text(encoding="utf-8")
    text = LINK.sub(r"[[\1]]", text)

    # Drop Notion's auto-generated frontmatter blocks if any
    text = re.sub(r"^Created:.*\n", "", text, flags=re.MULTILINE)
    text = re.sub(r"^Last Edited:.*\n", "", text, flags=re.MULTILINE)

    (OUT / clean_name).write_text(text, encoding="utf-8")

print(f"Migrated {len(list(OUT.glob('*.md')))} files to {OUT}")

This is not a perfect migration — databases still become flat folders, image references need separate handling, callouts and toggles lose their special rendering. But it gets you to "openable in Obsidian without screaming" in one pass, which is the hard part.

Gotchas, both directions

Notion's API counts every call. If you're polling for changes every minute, that's 43k calls/month, well within personal limits but burns through integration quotas if you build on top. Use the last_edited_time filter to fetch only changed pages instead of full database queries.

Obsidian's plugin API can break across versions. Major Obsidian updates occasionally break plugins; if you depend on a plugin for core workflow, pin the plugin version and test before updating Obsidian.

Don't store secrets in Notion pages. Their search is full-text and accessible to anyone with workspace access — including past members whose invites you forgot to revoke. For API keys and secrets, use a real password manager, not your note app.

Obsidian Sync is end-to-end encrypted; Notion is not. Notion can read your data; Obsidian (with Sync) cannot. For sensitive personal journals, this matters. Self-host the markdown files via Git or Syncthing if you don't want a third party in the loop at all.

Both have AI features that send your notes to LLM providers. Notion AI sends to their backend (which calls OpenAI/Anthropic). Obsidian AI plugins use your API keys, so the API provider sees the data. Neither is "private by default" when AI is involved — read the docs before enabling.

TL;DR

Notion has a great REST API. Easy to script "push data in" workflows. Locks your data in a database that exports poorly.
Obsidian has a great plugin API and gives you plain markdown files on disk. No external API, but you don't need one — grep, find, and Git already work.
For developers specifically: Obsidian for thinking, Notion for tracking structured stuff. Use both, accept the split, stop trying to find one tool to rule them all.

If you write code for a living, the migration cost of getting trapped in someone's proprietary format is real. Bias toward plain text where the philosophy of your notes allows it.

Originally published on trackstack.tech with the broader non-developer comparison and FAQ.

Email Marketing Automation in 2026: 5 Tools (and 1 Self-Hosted) Through Their APIs

TrackStack — Mon, 25 May 2026 06:02:21 +0000

I've wired up email automation in 5 different SaaS products over the last 3 years. Every time the team asks "Mailchimp or…?" — and every time the right answer depends on whether you actually need marketing campaigns, transactional sends, or both. This post is the version of that conversation aimed at people who'd rather see a curl than a pricing table.

The decision tree

What are you sending?
├── Transactional only (receipts, password resets, magic links)
│   → Resend / Postmark / SES (skip the rest of this post)
│
├── Marketing only (newsletters, campaigns, drips)
│   → Brevo (free, has API), MailerLite ($10/mo), 
│     or Listmonk (self-hosted)
│
└── Both, from the same tool
    → Brevo (unique combo at this price)
    │ or
    → Klaviyo (if e-commerce)
    │ or
    → ActiveCampaign Plus + transactional add-on ($$$)

The "both from the same tool" path is where most teams over-engineer. Splitting transactional (Resend) and marketing (anything) is usually cheaper and gives better deliverability — but harder to manage one source of truth on the contact.

The platforms, briefly

Brevo — best free, decent API, dual-purpose

300 emails/day on free, unlimited contacts, basic automation. Bills by emails sent, not contacts — a huge win if you have a big inactive list. Their REST API supports both transactional sends and marketing list management:

// Add contact to a list AND send transactional welcome — one Node script
import fetch from "node-fetch";

const BREVO_KEY = process.env.BREVO_API_KEY;

async function onboardUser(email, name) {
  // 1. Add to marketing list
  await fetch("https://api.brevo.com/v3/contacts", {
    method: "POST",
    headers: {
      "api-key": BREVO_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      email,
      attributes: { FIRSTNAME: name },
      listIds: [3],          // "New users" list
      updateEnabled: true,    // upsert
    }),
  });

  // 2. Fire transactional welcome
  await fetch("https://api.brevo.com/v3/smtp/email", {
    method: "POST",
    headers: {
      "api-key": BREVO_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      to: [{ email, name }],
      templateId: 7,           // your template
      params: { firstName: name },
    }),
  });
}

Two API calls, both authenticated by the same key. Most platforms force you to pay for separate transactional infrastructure (Mailgun/Postmark) plus marketing — Brevo bundles them.

MailerLite — clean UI, decent API, smaller free

500 subscribers on free (cut from 1,000 in September 2025), 12k emails/month, automation builder included. API is straightforward but transactional is a separate paid product (MailerSend). For just marketing, the API works well; the value prop is the editor more than the API.

ActiveCampaign — best automation, API is verbose

No free plan, $15/month entry for 1,000 contacts on Starter. The automation builder is the industry benchmark. The API works but it's REST in a 2010 sense — endpoints for everything, lots of object types (contact, deal, tag, list, automation, custom field, etc.). You'll write more code per integration than you would on Brevo or Klaviyo. Use it only when your team has bought into ActiveCampaign for the automation power, not for API DX.

Klaviyo — event-driven, the best dev API

Klaviyo's free tier is small (250 contacts, 500 emails/month), but their API is the cleanest of the bunch and built around events, not lists. You don't "add a contact to a campaign" — you push events, and segmentation rules on Klaviyo's side decide who gets what:

// Track an event — Klaviyo handles segmentation + automation triggers
import fetch from "node-fetch";

await fetch("https://a.klaviyo.com/api/events/", {
  method: "POST",
  headers: {
    Authorization: `Klaviyo-API-Key ${process.env.KLAVIYO_KEY}`,
    "Content-Type": "application/json",
    revision: "2024-10-15",
    accept: "application/json",
  },
  body: JSON.stringify({
    data: {
      type: "event",
      attributes: {
        properties: {
          OrderID: "ORD-12345",
          Total: 89.99,
          Items: ["sku-001", "sku-007"],
        },
        metric: { data: { type: "metric", attributes: { name: "Placed Order" } } },
        profile: { data: { type: "profile", attributes: { email: "user@example.com" } } },
      },
    },
  }),
});

That single event triggers any automation Klaviyo has set up for "Placed Order" — receipt, cross-sell sequence, review request 7 days later, whatever. This is why Klaviyo dominates e-commerce: shops want event-driven, not list-driven thinking, and the API matches.

HubSpot Marketing Hub — only if HubSpot is your CRM

2k emails/month on free, $20/month Starter, then a $890/month cliff to Professional. The API is solid (HubSpot has invested heavily) but you're paying for the whole CRM bundle. Don't pick HubSpot Marketing standalone — pick HubSpot if you already use their CRM.

Listmonk — the self-hosted answer

Listmonk is open-source, Go-based, single-binary or Docker. No task counter, no contact limit, no premium feature gates. Drop this on a $6 VPS:

# docker-compose.yml
services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_PASSWORD=listmonk
      - POSTGRES_USER=listmonk
      - POSTGRES_DB=listmonk
    volumes:
      - listmonk-data:/var/lib/postgresql/data

  app:
    image: listmonk/listmonk:latest
    restart: unless-stopped
    ports:
      - "9000:9000"
    depends_on:
      - db
    environment:
      - TZ=Europe/Kyiv
    volumes:
      - ./config.toml:/listmonk/config.toml

volumes:
  listmonk-data:

config.toml points at the Postgres above plus an SMTP provider (Amazon SES, Mailgun, or even Gmail for testing). The API is JSON, well-documented, and supports lists, subscribers, campaigns, and transactional templates.

What you don't get out of the box: visual automation builder (you wire campaigns to send on a schedule or trigger them via the API yourself), abandoned-cart logic, behavioral segmentation as deep as Klaviyo. What you get: complete control, $5/month total cost, no vendor lock-in. For SaaS founders running small lists who'd rather write code than fight a SaaS UI, this is the play.

Transactional vs marketing — the split most teams should make

A common mistake: picking one tool to do both because "it's simpler." Reality:

Transactional (receipts, password resets, magic links): low volume per user but mission-critical, must arrive in <30s, can't go to spam. Postmark, Resend, SES, Mailgun are purpose-built. Sending IP reputation is managed for transactional separately.
Marketing (campaigns, drips, newsletters): bulk send, latency doesn't matter, deliverability is shared-IP territory until you scale.

Mixing them on the same shared IP means a bad marketing campaign (spam complaints) can throttle your password-reset deliverability. Brevo and ActiveCampaign run separate infrastructure for the two even though they're one product. Klaviyo doesn't do transactional at all.

The split most teams should make: Resend or Postmark for transactional ($0–10/month at SaaS scale), Brevo or Listmonk for marketing. Two integrations, both small.

API quality, ranked

Based on my actual integration experience, not vendor copy:

Klaviyo — clean REST, event-first, excellent docs, sane errors, generous rate limits (75 req/sec)
Brevo — clean REST, both transactional and marketing under one key, docs OK
HubSpot — surprisingly good, OAuth flow is well-supported, schema is large but consistent
ActiveCampaign — works, but verbose; many endpoints, inconsistent response shapes between v1 and v3
Mailchimp — works, but the segmentation API is genuinely painful (string-based filter syntax that's easy to get wrong)
Listmonk — clean and simple, but smaller surface area than the SaaS APIs; some features exist only in the UI

Common pitfalls

Double opt-in vs API adds. Most platforms have a "skip double opt-in when added via API" setting, but the default usually requires confirmation. If your onboarding flow assumes the contact is immediately on the list, configure this explicitly or your welcome sequence won't fire.

Idempotency on contact creation. Re-running an integration test can create duplicate contacts. Brevo's updateEnabled: true, Klaviyo's profile upsert by email, and Mailchimp's MD5-hashed-email subscriber ID all solve this — but you have to use them. Default behaviour is often "error on duplicate," not "merge."

Rate limits. Klaviyo gives you 75 req/sec; Brevo 400 req/min; ActiveCampaign 5 req/sec. Bulk imports need throttling. The Mailchimp batch endpoint exists for a reason — use it instead of looping single calls when adding more than a few hundred contacts.

Webhook signature verification. All these platforms support outbound webhooks (e.g., "campaign sent," "contact unsubscribed"). All of them sign payloads. Verify before processing — it's not optional. The pattern's the same as Stripe or HubSpot HMAC.

Custom fields and types. Spreadsheets and JSON have loose types; CRMs are strict. A blank "" is not null, a "yes" is not a true, a "$1,200" isn't 1200. Normalize before API call. This burns more integration time than auth setup.

TL;DR

Marketing only, free + good API: Brevo. 300/day, unlimited contacts, REST that doesn't make you cry.
Marketing + transactional, one bill: Brevo again. Rare combo at this price point.
E-commerce, event-driven: Klaviyo. The best API of the bunch, period.
Already on HubSpot CRM: HubSpot Marketing Hub Starter.
Hate vendors, love Docker: Listmonk on a $6 VPS.
Avoid: Mailchimp (API is dated) unless your team is already locked in.

For SaaS founders specifically, the split I'd recommend in 2026 is Resend (transactional) + Brevo (marketing) + a webhook into your app, total ~$10–20/month at small scale. You'll spend less time fighting tooling and more time on the actual product.

Originally published on trackstack.tech with the SMB-perspective comparison table and FAQ.