Rethinking persona-based email automation at Side House
Adding a new persona to an existing email automation system exposed architectural limits in our Next.js cron job and Klaviyo setup. Here is how the system should have been designed from the start, and why fixing it matters for growth.
Introduction
At Side House, we already had a significant number of automated email flows running through Next.js cron jobs and Klaviyo. The system worked, the journeys were live, and the logic supported the personas we had originally planned for.
Then a new persona entered the picture.
That addition looked small at first. In practice, it forced a broader question: was the automation system built to support more than the initial audience model, or was it only built to support the exact flows we had at launch?
The honest answer is the second one.
That is a common mistake in early-stage product development. Teams move fast, focus on shipping, and model workflows around the first clear use cases. The problem appears later, when growth depends on supporting a new audience with different needs, different lifecycle stages, and different messaging logic. At that point, what looked like a set of reusable automations often turns out to be a collection of tightly coupled decisions.
The right question is not only how to add the new persona now. The more useful question is how the system should have been designed from the start so that a new persona could be added without forcing a structural rethink.
Engineering perspective
The core issue is that persona was not treated as a first-class architectural concept early enough.
In many automation systems, flows are implemented directly around campaigns, schedules, and conditions. That approach is fast to ship, but it often hard-codes assumptions everywhere: who the recipient is, what content they should receive, what events qualify them for a sequence, and what outcomes matter. Once those assumptions are spread across cron jobs, filters, Klaviyo lists, and conditional content blocks, adding a new persona becomes expensive because the logic is no longer centralized.
A more scalable design would have separated the system into four distinct layers from the beginning: triggering, eligibility, orchestration, and messaging.
The triggering layer should decide when the automation engine runs. In a Next.js setup, cron jobs are a reasonable way to schedule checks, batch updates, or recurring actions. But cron should only wake the system up. It should not contain persona-specific business logic beyond minimal routing.
The eligibility layer should answer a clean question: which users belong in which journeys, and why? This is where persona should have lived as structured data, not as an implicit assumption inside each flow. Instead of embedding conditions directly in individual jobs, the system should have relied on a shared eligibility model based on user attributes, lifecycle stage, relationship to the platform, and behavioral signals. A new persona would then be an extension of the model, not a rewrite of each automation.
The orchestration layer should decide which sequence a person enters, skips, pauses, exits, or re-enters. This is where journey definitions belong. Rather than building separate logic repeatedly for each persona, a stronger approach is to define reusable journey primitives: onboarding, activation, re-engagement, nurture, conversion, retention, and win-back. Each journey can then accept persona-aware rules and content variants. That creates a cleaner structure: the system does not ask which one-off email to send next, but which lifecycle journey applies to this type of user at this moment.
The messaging layer should handle content assembly and delivery through Klaviyo. Klaviyo is strong when it receives clean audience definitions, reliable properties, and predictable events. It becomes messy when upstream logic is inconsistent. From the start, the integration should have treated Klaviyo as the delivery and campaign execution layer, while Side House retained ownership of segmentation logic, event semantics, and persona definitions. That keeps the source of truth inside the product rather than scattering it across dashboards and flow-specific filters.
A better version of the system would also have introduced a formal persona model. That model does not need to be overcomplicated, but it should be explicit. A persona should have a stable identifier, a list of relevant attributes, allowed journeys, excluded journeys, messaging priorities, and business goals. Once defined that way, a new persona becomes something the platform can evaluate systematically.
This matters because the real scaling problem is not sending more emails. It is controlling variation.
When a new persona is added late, three kinds of duplication tend to appear. First, logic duplication: similar conditions get rewritten in several cron jobs. Second, content duplication: the same lifecycle message is recreated with minor persona changes. Third, operational duplication: marketers and developers both have to remember which flows are safe to edit and which ones contain hidden assumptions. Over time, that reduces reliability and makes iteration slower.
The earlier fix would have been to create a shared automation contract between the application and Klaviyo. In practice, that means defining a stable event taxonomy, a clear profile property schema, and a consistent way to resolve eligibility. For example, the application should be able to answer questions like: what persona is this contact, what stage are they in, what journeys are valid for them, what disqualifies them, and what has already been sent? Those answers should not depend on which cron job happens to run first or which Klaviyo flow was edited most recently.
Another important design decision would have been to make state explicit. Every automated flow system needs memory. If a user changes persona, becomes eligible for multiple journeys, or crosses a threshold that changes the messaging strategy, the platform needs a durable record of that transition. Without that, teams end up approximating state through tags, timestamps, or inferred behavior, which becomes brittle as soon as the portfolio grows. A dedicated automation state model would have made persona transitions easier to manage and much easier to debug.
Observability also becomes critical once personas multiply. The system should have been designed with logs, delivery traces, eligibility explanations, and simple auditability from day one. When a contact does or does not enter a flow, the team should be able to see exactly why. That is not just a developer convenience. It is the difference between a controlled automation platform and a black box.
In hindsight, the better architecture was not “more flows.” It was a persona-aware automation engine with reusable journey logic, centralized eligibility rules, explicit state, and a cleaner separation between application logic and Klaviyo execution.
That would have made the addition of a new persona a configuration and modeling exercise, not an architectural correction.
Product perspective
The reason this matters goes far beyond technical cleanliness.
A new persona does not just mean a new email audience. It usually means the product is reaching a broader operational reality than the original version anticipated. That is why this kind of change often feels bigger than expected. It exposes whether the company built its communication system around a narrow initial use case or around the full shape of the market it wants to serve.
For Side House, adding this new persona matters because it expands who can be addressed with relevance. That is the real unlock.
When automated lifecycle messaging is designed around only one or two audience types, growth eventually hits a ceiling. The product may attract additional segments, but the communication layer is not ready to support them properly. Messaging becomes too generic, timing becomes less accurate, and the product experience starts to feel like it was designed for someone else. That hurts conversion, retention, and trust long before it becomes obvious in a dashboard.
By contrast, a persona-aware system makes growth operationally viable. It allows the company to increase the size and diversity of its portfolio without flattening everyone into the same journey. Different personas often need different education, different reassurance, different proof points, and different calls to action. Treating them the same is rarely efficient. Treating them differently through a structured system is what turns automation into a growth asset instead of a maintenance burden.
This is especially important when portfolio expansion is a strategic priority. Growth at that level is not only about acquiring more opportunities. It is about supporting more variation without losing consistency. The communication model must scale with the portfolio model. If it does not, every new segment adds friction, manual work, and risk.
There is also a speed advantage. Once persona is modeled properly, launching new flows becomes faster because the team is no longer rebuilding the entire decision layer each time. Product, growth, and engineering can work from the same structure. That reduces alignment overhead and makes experimentation safer. Teams can improve messaging for a specific audience without destabilizing the whole lifecycle system.
The user experience improves as well. Better persona handling usually leads to clearer onboarding, more relevant education, stronger activation paths, and fewer mismatched emails. Users do not experience the architecture directly, but they absolutely experience its quality. They feel when the product understands where they are, what they need, and what should happen next.
There is also a strategic discipline benefit in going through this redesign. Being forced to add a new persona late is uncomfortable, but it can be valuable. It pushes the company to define who its audiences really are, what outcomes matter for each of them, and where shared journeys stop being enough. That kind of clarity improves both product thinking and go-to-market execution.
So while the immediate trigger is technical, the real value is commercial. A better persona model creates a more scalable growth system. It helps Side House support a much larger portfolio with more relevant communication, more predictable operations, and a stronger foundation for future expansion.
Conclusion
Adding a new persona to an existing email automation setup is often the moment when a team discovers whether it built flows or built a system.
At Side House, this change made one thing clear: the original setup was effective for the first stage of growth, but it was not modeled for enough variation. The mistake was not using Next.js cron jobs or Klaviyo. The mistake was letting persona logic live too deep inside the flows instead of treating it as a core layer of the system.
The better approach would have been to separate triggering, eligibility, orchestration, and messaging from the start, and to define personas as structured entities with explicit rules, journeys, and states.
That design would have made the new persona easier to add.
More importantly, it would have made future growth easier to support.
That is the real lesson. In automation, extensibility is not a technical luxury. It is a product requirement as soon as growth depends on serving more than one kind of user well.
Follow our journey on Side House.