About the ESP
Loops positions itself as “the email platform for SaaS”, and to their credit that is an accurate description rather than marketing spin. This is not a general purpose email service provider that happens to expose an API. It is a product email tool built for engineering teams who want signup sequences, onboarding flows, product announcements and password reset emails coming out of the same place, with as little ceremony as possible.
The philosophy is visible throughout. Contacts are user records with properties, not subscribers on lists. Automations are triggered by events your application fires. Transactional email sits alongside marketing email instead of being sold as a separate product. The interface is calm and well designed, the documentation is excellent, and the developer experience is among the best in the category.
Before any of that matters, though, there is a more useful question to settle, and it is about you rather than about them. Who in your business is going to be doing this work?
If a marketing team owns email and has no developer to call on, what they need is a full marketing platform. Lists, forms, imports, a real segment builder, broadcast controls, the lot, all operable by someone who does not write code. For that buyer the platform is not a convenience wrapped around something else. It is the whole product, because they have no way to produce any of it themselves and no reason to want to.
If a development team owns email because it is driven by product events, what they need is sending infrastructure. An SMTP relay or sending API, with the operational machinery that comes with it: suppression management, bounce and complaint handling, retries, logs, delivery analytics, SDKs, and people whose actual profession is deliverability. That buyer already has someone in the codebase, so whatever sits above the infrastructure is something they are capable of owning.
Loops sits between those two. It requires a developer, which rules it out for the first buyer, and it is not an infrastructure specialist, which weakens it for the second. Most of what follows in this review is a consequence of standing in that gap, so it is worth holding the question in mind as you read: which of those two buyers are you, and is this platform serving that or splitting the difference?
Onboarding Process
Onboarding is fast and unusually pleasant. You sign up, you are walked through domain authentication, and you are sending shortly after. The setup guides are clear and there is a CLI if you would rather do the whole thing from a terminal.
It is worth noticing what that setup actually consists of. You authenticate a sending domain, configure DNS records, and connect your application so that contacts and events flow in. That is essentially the same integration work you would do to stand up an SMTP relay, because it is the same underlying job. Loops has not removed the technical setup. It has put a nicer interface on the far side of it.
The catch arrives immediately afterward. The natural next step is getting contacts in, and the paved path is the API or a native integration. CSV upload exists, so you are not blocked, but the product clearly expects contacts to arrive from your application. If you are a marketer who was handed this tool, your first real task is a conversation with a developer.
Compare that to an email-first platform where onboarding ends with you importing a list, building a form and sending a campaign without leaving the interface. Loops shortens the technical setup a little and lengthens the marketing setup considerably.
Ease of Use
We should be unreserved about this part: it is the best looking email platform we have reviewed. Not one of the better looking ones, the best. It is uncluttered, fast, and clearly built by people with real taste. No feature sprawl, no upsell banners, no dashboard demanding you configure eleven things you do not need. After a run of platforms that bury the important functions under six menus of features nobody asked for, opening Loops is a breath of fresh air, and it stays pleasant to use in a way that very little software in this category manages.
That is worth saying plainly because the rest of this review is going to be critical, and none of the criticism is about how the thing feels to use. It feels wonderful.
What matters is where that simplicity comes from. On some platforms simplicity is the result of putting the money making features front and center and tucking advanced options one click away, so the depth is there when you need it. On Loops the simplicity is substantially because the depth is not there. Those two things feel identical in week one and very different in month six.
This shows up the moment you want to do something a working email marketer does routinely. Stagger a send across several hours. Build a segment combining engagement history with tag logic and a date condition. Suppress three overlapping groups from one campaign. Test five subject lines against a sample before rolling out to the remainder. None of those are exotic requests. They are Tuesday. On Loops you will find either a reduced version of the feature or a platform that does not think in those terms at all.
Which produces a particular arc that is worth naming, because you will feel it yourself if you trial this. The first week is a delight. Everything is quick, nothing is in your way, and you find yourself wondering why other software cannot be like this. Then you go to do the fourth or fifth real task of your job and the answer arrives, which is that the other software is carrying features you had stopped noticing until they were gone. The sleekness is real, but it is not a capability. Once the novelty of the interface wears off, what you are left with is the feature set, and the feature set is sparse.
There is a second, odder tension here. The interface is designed to be pleasant for a non-technical person, which is a real achievement, but the data it operates on is defined by engineers. So you get a lovely interface for a user who cannot independently feed it. The person who finds the UI delightful is frequently not the person who can change what it has to work with, and as the editor section covers, they get no AI help producing the copy or the design either.
Broadcast Feature
Broadcasts are called campaigns and the workflow is about as streamlined as it gets. Write the email, pick recipients with audience filters, schedule or send. There is a pre-send check that catches broken links, missing personalization fallbacks and unsubscribe problems, which is a nice touch that several larger platforms do not bother with.
For a product update going out to your user base, this is right. The campaign screen is built around that use case and not really around any other, and what is missing is the layer of control that separates sending an email from running an email program.
Start with pacing, because it is the most consequential. There is no meaningful throttling. When you hit send it goes, and on paid plans it goes fast. That sounds like a benefit until you have a substantial list and a mailbox provider forming its opinion of you in the first few thousand messages. Serious senders stagger delivery deliberately, splitting a campaign into portions across hours so that early engagement can establish reputation before the bulk lands. Platforms built for volume expose this directly, often as a per campaign setting that requires no advance planning. Loops has no equivalent.
This connects to a broader point about the sending side, which for a platform whose entire pitch is that developers should route their product email through it, ought to be the strongest part of the offering. Loops handles the mechanics competently: it retries soft failures, batches large sends, and makes domain authentication easy. What is absent is the layer above the mechanics. No exposed control over pacing. No public documentation of dedicated IP options or of how warmup is handled as you scale. Little visibility into which mailbox providers are treating you how. Most tellingly, the platform’s own deliverability guidance points responsibility back at the customer, advising that the fix for bounce problems is cleaner signup inputs and tighter audience segments.
That advice is not wrong. It is just not what a sending specialist tells you. Companies whose business is infrastructure treat your reputation as their problem, because their entire book depends on the pool you send from staying clean. They warm addresses, manage complaint feedback loops, handle blocklist remediation, monitor placement, and have people you can talk to when Gmail starts filtering you for reasons your own metrics do not explain. That is a specialized discipline built over years and it is the one part of the email stack that clever software design does not substitute for. Loops is asking a developer to hand over the most reputation-sensitive email their company sends, while offering less control over it than a dedicated relay would.
Back on the campaign screen, suppression exists at the account level as a blocklist, which handles the compliance case correctly. What is thin is campaign level suppression as a targeting tool, the everyday practice of excluding several specific groups from one send without permanently changing anyone’s status. Marketers do this constantly. Here you are pushed toward expressing it through filters, which works for simple cases and gets awkward fast.
Split testing exists through the experiments feature, but it is oriented around automation flows more than around the classic broadcast A/B where you test into a portion of the list and send the winner to the remainder. If subject line testing on broadcasts is core to how you work, check this against your process before committing.
The pattern is consistent. Loops treats a broadcast as one action. Platforms built for email as a revenue channel treat it as a controlled operation with stages, and give you handles on each stage.
Autoresponder/Automation Feature
Automations are called workflows, and the first thing to say is about how the builder looks and feels, because that is where the compliment belongs. It is the sleekest automation canvas we have come across on any platform we have reviewed. It is clean, quick, and a relief to work in after the cluttered flowchart tools most of the industry ships.
That is a statement about the canvas, not about what you can build on it. Branching and conditional logic are supported, you get delays, you can pause and resume flows, and you can run experiments inside them. Beyond that the picture thins out quickly, and it starts with how a workflow can be triggered at all.
There are three ways to start a workflow: a contact being added, a contact being updated, and an event.
The first is close to useless in practice, and the reason says a lot about the platform. Because there is a single audience and no lists, “contact added” means any contact added by any route whatsoever. There is no way to say that this workflow should run for people who came in through one particular source and not for everyone else, which is the entire reason list-based platforms make a welcome sequence per list. So the trigger that ought to be the simplest thing in the product, a welcome sequence, is the one that gives you the least control.
The second, contact updated, is more useful, and it is the closest thing here to a marketing style trigger since it fires on a property changing. It carries the same catch as everything else, though. It only helps to the degree that meaningful properties are being set on your contacts, and what gets set is decided by whatever your application sends over.
The third is where the platform actually lives. Events cover custom events your application fires, and they also come with native support for Stripe, Clerk, Supabase and Polar events out of the box. Developers will appreciate that: a payment failure, a subscription upgrade, a signup, a plan cancellation, all usable as triggers without writing the instrumentation yourself. If your stack happens to include those tools, a chunk of your lifecycle email can be built quickly and with very little code.
So for SaaS lifecycle email the trigger model does suit the job, more so than what many traditional platforms retrofitted onto a list based architecture. Onboarding sequences that react to what a user did in the product, trial expiry flows, upgrade and cancellation sequences. That is the work this is for.
Two limitations are worth understanding, and the second is the important one.
The first is a matter of vocabulary. The platform thinks in product events, while marketing automation frequently needs to think in marketing behavior, and those are not the same language. Someone opened the last three campaigns but has not clicked in a month. Someone entered a segment because a combination of profile values changed. Someone finished an entire sequence without converting and should be routed back to the start of it rather than dropped out of the flow. Those are ordinary marketing triggers, and here most of them either need to be modeled as custom events your developers fire, or cannot be expressed at all. The native Stripe and Clerk integrations do not help with any of it, because those describe what a user did in your billing and auth systems, not what they did with your email.
The second is the one that will define your experience with this platform more than any feature does. Every new trigger is potentially a development task. On an email-first platform, a marketer who wants to fire a sequence off a new engagement condition builds it in the segment builder in a couple of minutes. On Loops that same person needs an event to exist first, and unless it happens to be one of the natively supported Stripe, Clerk, Supabase or Polar events, that means a ticket, a sprint, and competing for priority against product work. The builder is lovely. The dependency chain behind it is what you have to plan around.
It also raises a question worth sitting with, because it comes back at the end of this review. If your developers are writing the event instrumentation regardless, and they are, since nothing here works until they do, then this workflow builder is essentially the thing you are paying for. That is worth pricing honestly.
Templates
Loops provides a set of templates that follow the platform’s aesthetic: clean, modern, minimal, text forward. They look like email from a well designed SaaS company, which is exactly what they are for.
If that is your style, the library is fine and the defaults are tasteful. If you need heavily designed, image rich, brand specific campaigns of the sort ecommerce and publisher senders rely on, the library will not get you there and neither will the editor. That is a deliberate positioning choice rather than an oversight, but it is a real constraint.
Email Template Editor
This is a strange one, so it is worth separating the two halves of it.
Visually it carries the same sleekness as the workflow builder, and the same calming effect. It is quiet, spacious and pleasant to sit in front of, with none of the toolbar clutter and panel noise that makes most email editors feel like work before you have written a word. If all you ever did was type plain text into it, this would be a lovely place to write, easily the nicest in the category.
The strangeness begins the moment you want to do anything other than plain text.
Start with the mechanics, because calling this a drag and drop builder would be generous. The nearest comparison on other platforms is a WYSIWYG editor, with one difference: anything you add to the page becomes a block you can drag up or down to reorder. So you get a writing surface with one narrow toolbar above it, you type directly onto the page as you would in any text editor, and to add an element you click its icon in that toolbar and it drops in at your cursor. There is no palette of components to drag from and no canvas to arrange things on. Hovering a line reveals a small handle, and dragging that handle moves that block up or down the page. That is the whole of the dragging.
Then look at what you can actually insert: columns, images, buttons, sections and arrays. That is the palette. And the experience of using it is unlike any email editor you have worked in before, which sounds like a compliment and is not one here. It is not intuitive, it does not resemble what you already know, and it is not something you pick up in an afternoon. Knowledge from every other platform you have used transfers poorly, and you are left poking at things to see what they do.
Arrays are where this becomes conspicuous. A marketer opens that menu, sees “array” sitting alongside images and buttons, and has no idea what it is or what it would be for. That is not a knowledge gap on the marketer’s part. An array is a programming concept, and it is there so that structured data passed in by your application can be looped over and rendered, which is a transactional email problem rather than a marketing one. The other four elements are ordinary. The fifth quietly assumes a developer is on the other end supplying the data.
That is the tell, and it fits everything else in this review. The editor appears to be reaching for a new visual language, one that feels deliberately developer-flavored. But developers do not write marketing emails. Marketers do. So the one interface in the product that only a marketer will ever touch is the one built in a vocabulary borrowed from engineering, and the person using it every day is the person least equipped to read it.
The net of it is a document editor that happens to produce email, rather than an email builder in the sense the term is normally used. For plain, single column, text forward messages that is a reasonable design and it is fast and pleasant to work in. For anything past that, you are learning a bespoke system to get results other platforms would have given you with a familiar one.
There is a markup layer underneath, which gives more structural control than the toolbar exposes and which developers will find sensible. It is worth noting who that helps, though. The person hitting the ceiling of that toolbar is usually the marketer building the campaign, and the escape hatch on offer is one they cannot use.
What you do not get is a conventional HTML mode where you paste in a template built elsewhere and have it render as designed. For many teams that is decisive. Custom HTML from a designer, a template built in a dedicated email design tool, or an existing library of proven creatives you want to bring across from another platform: all awkward at best. If your current process involves handing HTML to your ESP, expect to rebuild rather than migrate.
The related gap is dynamic content. Personalization variables work well. Conditional content, where entire sections of an email change based on who is reading it, is more limited than on platforms treating conditional blocks as a core capability. Since conditional content is one of the more reliable ways to lift revenue per send, this matters more than it appears in a feature list.
The larger omission is that there is no AI content generation in the product. No AI copywriting, no generated subject line variants, no rewriting, shortening or tone adjustment. Nothing on the design side either: you cannot describe an email and have a layout generated, you cannot have a branded template built for you to adjust, and there are no AI design suggestions.
There is an “Edit with AI” button in the top right, and it is worth explaining what it does, because it is not what the label suggests. It does not generate anything inside Loops. It packages up a prompt and hands it off to an external tool of your choosing, and the choices are Claude, Codex, Cursor and Zed.
Read that list again. Cursor and Zed are code editors. Codex is a coding agent. These are developer tools, and a marketer will not have a single one of them installed. The AI button inside the email composer points at your IDE.
We tried it, with Claude, and what came back was a set of general email marketing tips. Not copy for the email in front of us. Really generic common sense advice. That is a strange thing to offer a professional. If a person needs to be told the fundamentals of writing emails and to make sure to have a subject line, a button is not their problem, and if they already know the fundamentals, the button has given them nothing.
What you actually want, and what marketing platforms have largely settled on, is to select a block, say make this shorter or write me three versions of this, and have the copy change in place. This it is useful precisely because it operates on your email rather than on the general topic of email. Here that does not exist. You get an automated handoff and a generic prompt sent somewhere else.
That is an unusual position for a marketing tool in 2026, going on 2027, when AI generation of copy and design has become normal enough that buyers have stopped treating it as a feature to compare and started assuming it is part of what an editor is. But the more telling thing is the shape of the alternative on offer. Taken together with the array element and the markup escape hatch, it sketches a fairly specific picture of the customer this product has in mind: a startup staffed entirely by engineers, where a frontend developer is the one writing the campaign, and where the natural way to get help with an email is to fire up a coding assistant and ask it how email marketing works. If that is your company, the design makes sense. If you employ a marketer, you have just watched the tool hand your campaign to a code editor.
In practice this means generating your copy in a separate AI tool and pasting it in, which is workable but makes the nicest editing surface in the category one where a good part of the writing happens somewhere else.
Design is worse, because the gaps compound. You cannot generate a design here, and as covered above there is no conventional HTML mode, so you cannot readily bring in one you generated elsewhere either, since HTML is how AI generated email designs arrive. The one kind of content you cannot produce in this editor is also the one kind you cannot import into it.
List Management
Loops uses a single audience model. One pool of contacts with properties on them, plus mailing lists that function as subscription preferences so people can opt out of one category without unsubscribing entirely. Contacts arrive by API, integration or CSV. There is double opt in, an account level blocklist, a per contact activity timeline, and export.
The activity timeline is good. The mailing list preference model is a clean, modern approach to subscription management that some older platforms still handle badly.
The gap is segmentation depth. Filtering works on contact properties and events, which covers the SaaS case. What it does not match is a dedicated segment builder where you construct arbitrary combinations of tags, custom field values, engagement history, campaign level actions and events, nest conditions inside each other, mix AND and OR logic freely, save the result as a reusable named segment, and then combine several of those at send time.
That is not a luxury capability. It is the engine of a functioning email program, because targeting is what separates a list that stays engaged from one that quietly stops opening. Coarse segmentation means broader sending, broader sending means falling engagement, and mailbox providers notice. Segmentation and deliverability are the same conversation rather than two separate ones.
And again the organizational point. Because contacts are shaped by what your application sends over, the data available to segment on is decided by engineering rather than by marketing. If a marketer concludes that a new field would unlock a better campaign, that field generally has to be added upstream first.
Analytics
Analytics cover the fundamentals: opens, clicks, campaign performance charts, click tracking with UTM support, and goal based conversion tracking. Goals are the most interesting piece, since tying an email to a downstream product action is useful and reflects the platform’s orientation.
What is thin is the reporting depth that experienced senders live in. Domain level breakdowns showing how Gmail is treating you compared to Outlook. Engagement trends across the list over time. Comparative reporting across campaigns. The kind of view that warns you your reputation is drifting before it becomes a problem you find out about from a blocklist.
That distinction matters more than it sounds. Loops tells you how a campaign did. It is much less equipped to tell you how your sending is doing, and those are different questions. Providers who specialize in delivery treat the second question as the main event, because placement is their product. Here it is largely invisible, which means that by the time a problem is obvious in your open rates, it has usually been developing for a while.
For a team sending a few product updates a month this is adequate. For a team whose job is improving email performance quarter over quarter it will feel underpowered, and you will end up exporting data to answer questions the interface cannot.
Support
Support is a real highlight and one of the better arguments for the platform. Small team, reachable founders, real answers from people who built the product rather than canned responses from an outsourced queue. Onboarding calls are available and the documentation is excellent.
This is the underrated advantage of working with a smaller company and Loops demonstrates it well. Weigh it seriously, because support quality is something you feel every week.
The caveat is scope rather than quality. The team can answer anything about the platform. What a product focused company of this size does not offer is the deliverability side of support: someone who will look at your list, your sending patterns and your reputation and tell you how to structure a ramp for a large migration, or work out why one mailbox provider has started filtering you. That is a different profession, and it is the help you most want available at the moment your program gets big enough to need it. Sending specialists staff for it because it is their core business. A platform company generally does not.
Pricing
Pricing is based on subscribed contacts synced to the platform. Sending is not charged separately, and every feature is available on every plan including the free tier.
Free covers up to 1,000 contacts and 4,000 sends per 30 days with a Loops footer. Paid starts at $49 per month for 5,000 contacts and scales with contact count from there, reaching several thousand dollars per month at the top of the range. There is nothing between 1,000 and 5,000 contacts, so if you land in that gap, and plenty of growing businesses do, you pay for headroom you are not using.
The absence of feature gating is good and worth applauding. Being able to use automations, transactional email and the full feature set on a free plan is more respectable than the industry norm of holding basic functionality hostage to force an upgrade. Credit where it is due.
The metric is the problem. Charging by contacts stored means you pay identically for a contact you email weekly and one you email twice a year. Your bill tracks the size of your user database rather than your email activity, which is comfortable for a SaaS company where contacts roughly equal users, and punishing for anyone building a list they mail selectively.
The comparison that really stings is not with other marketing platforms, though. It is with the infrastructure option. Sending services charge for emails delivered. A SaaS company with a large user base sending each of them a handful of messages a month is a modest bill on a per-send model and a significant one on a per-contact model, and that gap widens every month your user count grows. You end up paying platform prices for user storage while your actual sending volume, the thing that costs money to deliver, may be quite small.
Put plainly: the pricing model assumes you are extracting marketing platform value from your contact database. If you are mostly sending product email triggered by events, you are not, and you are paying for it anyway.
Pros
Excellent developer experience
The API, SDKs, CLI, webhooks and native integrations are first rate and the documentation is a pleasure to work with. If your contacts and events live in your application, getting them into Loops is close to frictionless.
Transactional and marketing email in one place
Not charging separately for transactional email, and letting it share contact records, templates and analytics with marketing email, removes a vendor from many stacks.
The best looking interface in the category
Not merely clean, but the sleekest we have reviewed. The workflow builder especially is a pleasure to use, and the whole product is a breath of fresh air next to the cluttered tools most of the industry ships. Just be clear with yourself that sleekness is a feeling rather than a capability, that it wears off faster than a missing feature does, and that in the editor the calm surface sits on top of a genuinely unfamiliar system.
All features on all plans
No feature gating, including on the free tier. This is the right way to price software and more platforms should do it.
Strong human support
A small team with reachable founders, real answers and good documentation. A meaningful advantage over larger platforms with outsourced support.
Event driven automation with native billing and auth triggers
For SaaS lifecycle email specifically, the event triggered model suits the job better than the list based approach many traditional platforms retrofitted. Stripe, Clerk, Supabase and Polar events work as triggers out of the box, so if your stack includes those, a good deal of your lifecycle email can be built with no instrumentation work at all.
Cons
It asks for a developer without being an infrastructure specialist
Nothing works until an engineer wires it up, which rules it out for marketing teams who need to operate independently. But it also does not offer the delivery depth of a dedicated sending service such as an SMTP relay, which is what a developer-led team actually needs underneath them. Both alternatives are stronger at their end than Loops is at either.
You pay platform pricing for a workflow builder
Subtract what an SMTP relay already includes as standard, meaning suppression, bounce and complaint handling, retries, logs, analytics, SDKs and deliverability operations, and what remains unique here is the flow builder and the writing interface. That is a narrow purchase for the price, especially when the integration work falls to you regardless.
Marketers are dependent on engineering
Contacts, events and therefore most segmentation and triggering are defined by what your application sends. A marketer who wants a new field, trigger or targeting condition needs engineering time. On an email-first platform they build it themselves in minutes. Over a year, that difference determines how many campaigns actually get run.
Deliverability control is abstracted away
No exposed pacing or throttling, no documented dedicated IP or warmup path, limited placement visibility, and guidance that puts reputation problems back on the customer. For the most reputation-sensitive email a company sends, that is thinner than a sending specialist offers.
Limited broadcast controls
No staging of sends, thin campaign level suppression, and split testing oriented toward flows rather than classic broadcast A/B. A broadcast is one action rather than a controlled operation.
Shallow segmentation
Property and event filters rather than a full segment builder. No deep nesting, limited mixing of engagement history with profile and tag logic, and no combining saved segments at send time. The single audience model also undercuts the “contact added” workflow trigger, since with no lists it fires for everyone who enters by any route, which makes a targeted welcome sequence awkward to build.
An editor that is lovely for text and strange for everything else
Beyond plain writing you get five insertable elements, one of which is an array, a programming concept a marketer has no reason to recognise. The result is a bespoke visual language that transfers from nothing else you have used, in the one part of the product only marketers actually touch. Add no conventional HTML mode, limited conditional content, and a template style suited only to minimal text forward design, and migrating an existing creative library means rebuilding it.
No AI content generation in a product built around composing
No AI copywriting, subject line variants or rewriting, and no AI generation of layouts or templates, both of which are standard equipment elsewhere by now. The “Edit with AI” button does not generate anything in the platform. It hands a prompt to Claude, Codex, Cursor or Zed, three of which are developer tools, and returns general advice rather than copy for the email you are writing. Selecting a block and having its copy rewritten in place, which is the thing marketers actually use, is not on offer.
Reporting lacks depth
Fine for campaign results, thin on domain breakdowns, engagement trends and the reputation signals experienced senders monitor.
Contact based pricing is the wrong metric here
You pay for contacts stored rather than emails sent, so your bill tracks user growth rather than email activity. Against per-send infrastructure pricing, that gap widens as you scale.
Narrow fit outside SaaS
No landing pages, minimal form building, and a model that assumes an application generates your contacts. Publishers, agencies, ecommerce operators and anyone running email as a standalone channel are not the intended audience, and it shows.
Final words
Loops is a well built product by people who clearly care about their craft. The developer experience is excellent, the support is real, the interface is a relief after the bloated alternatives, and refusing to gate features behind tiers is the correct way to price software. Very little of the criticism here is about execution.
It is about fit, and fit comes back to the question this review opened with. Who is doing the work?
If marketing owns email and has nobody to call on, you need a platform built for that person: lists, forms, a real segment builder, broadcast controls with staging and suppression, conditional content, AI generation of copy and design, and pricing tied to what you send rather than what you store. Loops cannot be that, because nothing in it functions until a developer wires it up. That is not a gap they can close with a release, since it follows from how the product is designed.
If developers own email because it is driven by product events, then look carefully at what you are buying. You are doing the integration work either way, and that is the expensive part. Underneath it, what you need is infrastructure: reliable delivery, suppression, bounce and complaint handling, retries, logs, SDKs, and people whose profession is deliverability rather than product design. A relay service gives you all of that as standard, because that is the product category. It is also better at the part that is genuinely hard, which is placement and reputation, for the simple reason that it is the only thing they do.
Subtract all of that from Loops, since a relay already covers it, and what is uniquely left is the workflow builder and the writing interface. That is the actual purchase. It is a nice workflow builder, but it is worth asking whether it justifies platform pricing on top of infrastructure you are paying for regardless, particularly when the cost of having that kind of layer built to your own specification has been falling steadily for years and shows no sign of stopping.
The reason this argument does not apply to marketing platforms, incidentally, is worth spelling out, because it explains the whole picture. A marketing team cannot build their own platform on a relay and should not try. Relays are not designed for marketing email in the first place. They exist to deliver individual messages reliably, not to run list management, segment building, broadcast scheduling, throttling strategy, form capture and campaign reporting for a non-technical operator. Building that on relay foundations is a serious engineering project needing people who understand marketing email specifically, which is precisely the resource that buyer does not have. For them the platform is not a layer of convenience. It is the thing itself, and there is no substitute.
Which is the awkward part of where Loops has planted itself. The value of a platform layer is inversely proportional to the technical capacity of whoever is buying it. For a marketer with no developer, it is everything. For a development team already writing event instrumentation, it is a convenience sitting on top of a specialist alternative that does the hard part better and charges less for it. Loops has spent years telling SaaS teams that email belongs to their developers, and they are right about that. The difficulty is that a team who accepts the premise has steadily fewer reasons to buy the layer rather than own it, while a team who rejects it, because marketing owns email and always will, was never really the intended customer.
For an early stage company with a small user base and no strong opinions about email, it can still be a reasonable trade, and the free tier makes it easy to test. As volume grows, as your list becomes an asset you want to work rather than a table you notify, or as someone notices you are being billed by contact for email you barely send, it gets harder to defend.
Some providers offer both, running an SMTP relay for developer-driven sending and a full marketer-operated platform as separate products, so a company that needs both can source them from one place. Emercury is one example.