How to Build an App Like Klaviyo

Klaviyo costs $400/month for 10,000 profiles. At 50,000 profiles it is $700/month. At 100,000 profiles you are paying $1,700+/month. At 200,000 profiles the invoice crosses $2,500/month.

A custom alternative costs $200K-$280K to build and takes 18-22 weeks. Do the math for your scale and your growth trajectory — it usually becomes obvious whether building makes sense.

This article covers the full architecture: the unified customer profile, the event streaming pipeline, the flow builder, SMS compliance, revenue attribution, and the ClickHouse analytics engine that makes complex segment queries run in milliseconds.

Klaviyo vs Mailchimp: A Different Product Category

Mailchimp is a list-and-campaign tool. You upload contacts, build emails, send them, and look at open rates. It works well for newsletters and simple sequences.

Klaviyo is a customer data platform with a marketing layer on top. The core is the unified profile: every email event, purchase event, web behavior, and SMS interaction merges into one real-time customer record. The marketing layer — flows, campaigns, segments — operates on top of that data model.

That distinction changes the architecture entirely. If you are comparing the two and deciding which type of platform to build, start with our guide on how to build an app like Mailchimp. This article assumes you need the deeper data integration that Klaviyo offers.

Who Builds a Klaviyo Alternative

Three categories of companies commission this type of platform.

E-commerce platforms that want native retention marketing. A platform that already owns merchant product data, order history, and customer records has a structural advantage over Klaviyo. Instead of Klaviyo pulling data via API, the marketing engine lives inside the same database. Segment queries run faster. Attribution is exact, not probabilistic.

Marketplaces with multi-vendor complexity. Klaviyo is built around a single-merchant e-commerce model. A marketplace with 200 vendors needs per-vendor email sending, per-vendor suppression lists, and per-vendor attribution. Klaviyo does not handle this cleanly. Building a custom platform that models vendor-level email ownership from the start is the right call.

D2C brands at scale. A brand with 200K+ profiles and predictable growth pays $2,500+/month on Klaviyo. At $30,000/year, a custom build with full data ownership pays back in under 10 years — and the economics look very different if the brand plans to scale to 1M+ profiles.

The Unified Customer Profile

This is the hardest and most important architectural decision.

In a standard email tool, a subscriber is a row in a database table with an email address and some properties. In a Klaviyo-like system, a customer is a profile that aggregates events from multiple sources in real time.

A single customer profile stitches together:

• Email events (sent, opened, clicked, bounced, unsubscribed)

• Purchase events (order placed, order value, products purchased, repeat purchase)

• Web behavior (product viewed, category browsed, search queries)

• SMS events (sent, delivered, replied, opted out)

Every one of these events arrives as a discrete data point with a timestamp. The profile stores the raw events and computes derived properties — total order value, days since last purchase, email engagement score, predicted churn probability — as aggregates.

The real-time requirement is non-negotiable. When a customer abandons a cart, the abandoned cart flow must fire within minutes. That means event ingestion, profile update, and trigger evaluation all happen in near real time, not in nightly batch jobs.

Event Stream Architecture

Apache Kafka is the backbone. Every event — whether it is a product view from a pixel, an order from a Shopify webhook, or an email open from your sending infrastructure — lands in a Kafka topic.

Consumers read from these topics and perform three operations:

Profile updates. The raw event merges into the customer profile in your PostgreSQL operational database. The profile's derived properties (engagement score, days since purchase) recalculate.

Trigger evaluation. The flow engine subscribes to the event stream and evaluates whether any active automation flow should fire for this customer. If a customer just viewed a product they have not bought, the browse abandonment flow may trigger.

Analytics writes. The event writes to ClickHouse for historical querying and segment generation.

This three-consumer pattern keeps the operational database fast for reads and writes, the flow engine responsive for trigger evaluation, and ClickHouse accurate for analytics — without each workload interfering with the others.

The Flow Builder

Klaviyo calls its automation system "flows." The concept is the same as automation workflows in other tools — trigger, then a sequence of timed actions with conditional branching.

The five flows every e-commerce platform uses:

Browse abandonment. A customer views a product but does not add it to cart. Fire an email after 30 minutes. If no purchase in 24 hours, fire a second email.

Cart abandonment. A customer adds to cart but does not purchase. Fire within 1 hour, then again at 24 hours, then at 72 hours.

Post-purchase. Order confirmed. Send order confirmation immediately. Send a review request 7 days after delivery. Send a replenishment reminder based on the product category's average reorder window.

Win-back. A previously active customer has not purchased in 90 days. Send a re-engagement sequence with an incentive.

VIP segment flow. When a customer's total order value crosses a threshold, they enter the VIP segment and receive a dedicated onboarding sequence.

Building the visual flow builder is 4-5 weeks of work. The harder engineering problem is real-time trigger evaluation at scale. When 50,000 customers browse your product catalog simultaneously, the trigger evaluation engine must assess each profile against each active flow without creating a processing backlog.

Revenue Attribution

Revenue attribution is what separates Klaviyo from a basic email platform. Without it, you can tell an email was opened. With it, you can tell an email generated $47,000 in orders this week.

The mechanics require two components.

An attribution pixel or purchase event API on the checkout page. When a customer completes a purchase, the event fires with the order value, order ID, and customer identifier. This event hits your Kafka pipeline and routes to the attribution engine.

An attribution window. The standard options are 5-day and 30-day last-touch attribution. If a customer clicked an email within the last 5 days and then purchased, 100% of the purchase value attributes to that email. Multi-touch attribution splits credit proportionally across all touchpoints within the window.

Last-touch is simpler to implement and explain to clients. Multi-touch is more accurate but requires a more complex calculation and a longer explanation during onboarding.

Build last-touch first. Add multi-touch as a reporting option in version two.

SMS Engine

Adding SMS alongside email creates a unified channel view of the customer. For e-commerce, SMS dramatically outperforms email on open rate — 98% open rate for SMS versus 20-25% for email — which makes it valuable for time-sensitive flows like flash sales and cart abandonment.

The SMS engine has three components.

Carrier integration. You connect to a carrier aggregator — Twilio is the standard choice, Bandwidth is the enterprise alternative. The aggregator routes your messages to the correct mobile carriers. API integration with Twilio is 1-2 weeks of work.

Opt-in compliance. In the US, TCPA requires explicit opt-in consent for marketing SMS. You cannot send SMS to a customer who gave you their phone number for order confirmations without a separate SMS marketing opt-in. In the EU, GDPR applies. Building compliant opt-in flows, consent storage, and preference management is not optional — violations carry per-message penalties.

Number type selection. The three options are toll-free numbers (fastest to provision, lower throughput), short codes (5-6 digit numbers, higher throughput, 8-12 week FCC registration), and 10DLC (standard 10-digit numbers registered to your business, now the default for US marketing SMS). 10DLC registration through carriers takes 4-6 weeks and requires brand and campaign registration. This is a non-trivial timeline blocker — start it in week 1 of your build.

Predictive Analytics

Klaviyo offers three predictive metrics: churn probability, next order date, and customer lifetime value prediction.

These are ML models trained on your customer event history. The input features are:

• Days since last purchase

• Number of orders in the last 90 and 365 days

• Average order value

• Email engagement rate (opens, clicks)

• Product categories purchased

• Recency, frequency, monetary (RFM) scores

A gradient boosting model (XGBoost or LightGBM) trained on these features predicts churn probability and next purchase date with reasonable accuracy on a dataset of 50,000+ customers. Below that volume, the training data is too thin to be reliable.

CLV prediction uses a similar model but predicts total expected revenue over a fixed future window (usually 12 or 24 months).

Budget 4-6 weeks for the ML pipeline: data preparation, model training, prediction serving via a Python microservice, and integration into the profile and segment system.

Skip predictive analytics in version one if you are under 50K customers. The models will not be accurate enough to be useful, and the development time is better spent on the core event pipeline.

Why ClickHouse

This is the architectural decision most teams get wrong.

Segment queries in a Klaviyo-like system look like this: "All customers who purchased shoes at least twice in the last 90 days, have not opened any email in the last 30 days, and have a total lifetime value above $500."

Running this against a PostgreSQL database with 2M customer profiles and 500M event rows takes 3-7 minutes. Users cannot wait 7 minutes for a segment count.

ClickHouse is a columnar database built for analytical queries on large event datasets. The same query runs in under 2 seconds on ClickHouse. Columnar storage means the database only reads the columns involved in your query filters — not every column in every row.

The operational data model stays in PostgreSQL. Profile reads and writes, campaign configurations, user accounts, and billing data all live there. ClickHouse receives a copy of every event via a Kafka consumer and handles all analytical queries: segment counts, campaign analytics, attribution rollups, and cohort analysis.

Shopify and WooCommerce Integration

For a Klaviyo alternative, e-commerce platform integration is table stakes.

Shopify integration uses the Shopify Admin API and Shopify webhooks. Webhooks push order events, cart events, and customer events in real time. The Klaviyo approach is real-time: every order and cart event fires within seconds of occurring on the store.

WooCommerce integration uses the WooCommerce REST API and custom webhooks configured via the WooCommerce settings.

The depth of integration matters. A basic integration pulls order history in a nightly sync. A Klaviyo-level integration captures every web event (product views, search queries, category browsing) via a JavaScript pixel on the storefront, plus real-time order and cart webhooks. The pixel data is what enables browse abandonment flows.

Building a Shopify app that installs the pixel and configures webhooks automatically is 3-4 weeks of work. WooCommerce plugin development is an additional 2-3 weeks.

Tech Stack

The full stack for a Klaviyo-like platform:

Python or Node.js for the backend. Python is preferred if you plan to build the ML pipeline in-house — the data science tooling (scikit-learn, XGBoost, pandas) is mature and the team skills typically overlap.

Apache Kafka for event streaming. Topics per event type (email.opened, purchase.completed, cart.abandoned, sms.delivered), with consumers for profile updates, trigger evaluation, and analytics writes.

ClickHouse for analytics. Columnar storage, fast aggregations, SQL interface. Use the ClickHouse cloud offering or self-host on a dedicated server.

Redis for real-time profile cache. Frequently accessed profile properties (email engagement score, last purchase date, active segments) live in Redis for sub-millisecond lookup during trigger evaluation.

PostgreSQL for operational data. Customer profiles, campaign configurations, flow definitions, user accounts, billing records.

Twilio for SMS sending. Connect to the Twilio Messaging API for SMS and to a dedicated email infrastructure (Amazon SES or SendGrid) for email.

Timeline and Cost

Cost range: $200K-$280K for a full platform. Without predictive analytics, budget $160K-$200K.

Build vs Buy

Use Klaviyo when:

• You have under 100,000 profiles and are growing slowly

• Your data model matches Klaviyo's single-merchant e-commerce assumptions

• You need email and SMS running in 2 weeks, not 20

• Your engineering team does not have experience with event streaming and columnar databases

Build custom when:

• You have 200,000+ profiles and the monthly invoice is climbing past $2,000

• You are building a marketplace that requires multi-vendor email logic

• Your product generates customer events that Klaviyo does not model (B2B SaaS events, in-person purchase events, subscription lifecycle events)

• You need full data ownership for compliance, and cannot have customer purchase data in a third-party SaaS

If your primary need is email campaigns without the deep data integration, the simpler architecture in our Mailchimp build guide will get you to market faster and at lower cost.

What RaftLabs Builds

We have built MarTech platforms, customer data pipelines, and SaaS products that handle event-driven architectures. The event streaming, ClickHouse setup, and SMS compliance work are where most teams underestimate scope — both in timeline and in the regulatory detail required for carrier registration.

If you are evaluating whether to build custom or continue scaling with Klaviyo, the first step is mapping your actual data model against what Klaviyo can and cannot represent. That conversation usually takes one hour and tells you whether the build is worth it.

Our SaaS application development practice handles full-stack builds from architecture to deployment on Vercel, AWS, or GCP. Our AI automation practice can add the predictive layer — churn models, send-time optimization, product recommendation engines — on top of the core platform.