Advertising
Software engineering for Marketing Technology
Most marketing teams do not need another tool. They need the dozen they already own to share one trustworthy view of the customer, and to do it inside what consent law now allows. That, not another dashboard, is the work.
Why the domain matters
MarTech is the software behind owned marketing. The customer data, the automation, the email and messaging, the personalisation and the analytics that a marketing team uses to reach people it already has a relationship with. It is a distinct discipline from adtech. Adtech is about buying attention on someone else’s inventory: real-time bidding, paid media, programmatic exchanges. MarTech is about the channels you own and the data you are entrusted with (your list, your app, your site, your CRM), and the lifecycle marketing that runs across them. The two get lumped together, but they have different constraints, different data and, increasingly, different legal footing.
The defining reality of the sector is not a shortage of capability. It is sprawl. The average marketing team has bought dozens of point tools: a CDP here, an email platform there, an analytics suite, an A/B testing tool, a CRM, a handful of channel apps, and almost none of them share a coherent view of the customer. The same person is three different records with three different identifiers, and no system can say authoritatively what was sent to them, what they did, or what they consented to. So the real problem is rarely capability; it is fragmentation and data you cannot trust. The value we add is unifying that data, integrating what already exists, and doing both without pretending consent law is optional.
We are engineers who build martech products and untangle martech stacks, and we will be blunt about both. Buying another tool almost never fixes a data problem: it usually adds one more disconnected record. And privacy law genuinely limits what you can do with customer data; that is not a compliance department being awkward, it is the actual constraint the architecture has to be designed around. Because we operate what we build, we live with the consent edge cases and the identity-resolution mistakes, which is exactly why we treat them as engineering problems from the start rather than fine print at the end.
The challenges in marketing technology
The stack is fragmented and nothing shares a customer
A typical marketing team runs a dozen or more tools that were each bought to solve one problem and none of which agree on who the customer is. Email knows an address, the CRM knows an account, analytics knows an anonymous cookie, the app knows a user ID, and no system reconciles them. The result is that no one can answer a simple question like “what have we actually sent this person, and how did they respond?” without a manual export and a spreadsheet. This is the core martech problem, and buying another tool almost always deepens it.
The data is untrustworthy, so decisions are guesses
Duplicate profiles, stale attributes, events that fired twice or not at all, identifiers that never got stitched together, marketing data is famously dirty, and dirty data quietly poisons everything built on top of it. Segments include people they should not, automations trigger on false signals, and reports disagree with each other. Teams lose more time reconciling numbers than acting on them. Until the underlying identity resolution and event pipeline are trustworthy, every clever campaign is built on sand.
Privacy and consent genuinely limit what you can do
GDPR governs how you may hold and use personal data; PECR governs marketing by email, SMS and the use of cookies and similar tracking. Between them, and with third-party cookies deprecating, a large amount of what martech historically did by default is now either unlawful or requires explicit consent. This is not a checkbox at the end: it constrains what data you can collect, how long you can keep it, which channels you can use to reach whom, and how personalisation may work. Designs that treat consent as an afterthought get rebuilt.
Consent is a data problem, not a cookie banner
Most organisations think of consent as the banner on the website. In reality, consent is a piece of state that has to travel with the customer across every tool: whether they agreed to email, to SMS, to profiling, to cross-device tracking, and when, and via which version of which notice. If that state does not propagate to the email platform, the CDP and the analytics pipeline, then a preference the customer set in one place is silently ignored everywhere else. That gap is both a compliance breach and a broken customer experience.
Attribution is genuinely hard and often oversold
Marketers are under pressure to prove what worked, and the tooling promises tidy answers. But with cookie deprecation, cross-device journeys, walled gardens and consent-gated tracking, deterministic last-click attribution is decreasingly meaningful and multi-touch models rest on assumptions that are easy to hide. The honest position is that attribution is directional, not exact, and a system that presents modelled estimates as hard fact does the team a disservice. Building attribution well means being clear about what the numbers can and cannot support.
Personalisation degrades fast and can cross a line
Personalisation engines are only as good as the data and rules behind them, and both rot. Segments drift, product feeds go stale, a rule fires the wrong message to the wrong person, and “personal” becomes “creepy” the moment it uses data the customer did not expect you to have or consent to. The engineering challenge is not the recommendation logic; it is keeping the inputs fresh, the rules governable by marketers rather than developers, and the whole thing inside what the customer actually agreed to.
What we build for marketing technology
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Customer Data Platforms and unified profiles
The heart of the sector: pulling identity, attributes, events and consent from every source into a single, trustworthy customer profile that the rest of the stack can rely on. We build the ingestion, the identity resolution that stitches records together, the event schema, and the profile store: whether you are adopting a packaged CDP and need it integrated properly, or your requirements justify a bespoke one. The point of a CDP is not the tool; it is that everything downstream finally agrees on who the customer is.
Marketing-automation integration
Connecting the automation platform to the systems that should drive it (the CDP, the CRM, the product itself), so that journeys trigger on real, current signals rather than nightly CSV imports. We build the event flows, the segment sync, the suppression and consent propagation, and the reconciliation that makes sure what the automation thinks is true matches what actually happened. This is usually where a stack stops feeling like disconnected tools and starts behaving like one system.
Personalisation and content-delivery engines
The infrastructure that decides what each customer sees (on site, in app, in email), based on their profile, behaviour and, critically, their consent. We build the rules and the serving layer so that personalisation is fast, governable by marketers, and constrained to data the customer agreed to. We are honest that good personalisation depends far more on clean, consented inputs than on the sophistication of the algorithm.
Analytics, attribution and reporting
Event pipelines and reporting that marketing can actually trust, built to survive cookie deprecation and consent-gating. We instrument first-party events cleanly, model journeys where deterministic tracking has gaps, and present attribution with honest confidence rather than false precision. The goal is a single set of numbers the team believes, not five dashboards that disagree.
Consent and preference management
The often-missing backbone: a consent and preference layer that captures what each customer agreed to, versions it against the notice they saw, and propagates it to every system that touches their data. We build it so that a preference set once is honoured everywhere (email, SMS, profiling, tracking), because a consent record that does not reach the sending system is worse than useless.
Bespoke martech products
For teams building martech to sell rather than to use. A CDP, an automation platform, a personalisation or analytics product of their own. We build the product itself: the multi-tenant data architecture, the ingestion at scale, the identity resolution, and the consent and privacy controls that any serious martech product now has to offer its own customers as a first-class feature.
Where we help
A single customer view that finally reconciles
Stitching the email address, the CRM account, the anonymous web visitor and the logged-in app user into one profile, with consent attached, so the team can answer “who is this person, what have we sent them, and what may we still do” from one place. This is the identity-resolution work that underpins everything else, and the point at which the fragmented-stack problem starts to dissolve.
Consent that actually reaches the sending system
A preference centre and consent store wired so that when a customer opts out of SMS or withdraws consent to profiling, that state propagates to the messaging platform, the CDP and the analytics pipeline within moments, not overnight, and not never. The measure of success is simple: a preference set in one place is honoured in every place, and you can prove it if a regulator asks.
Lifecycle journeys triggered on real behaviour
Onboarding, re-engagement, win-back and post-purchase journeys that fire on live product and behavioural signals routed through the CDP, rather than on stale nightly imports. The engineering is in the event plumbing and suppression logic that makes sure the right message reaches the right person once, at the right moment, and never after they have asked you to stop.
Reporting the marketing team believes
Replacing the monthly ritual of reconciling five tools that disagree with one trustworthy event pipeline and a reporting layer built on it. Clean first-party instrumentation, honest attribution that flags where it is modelling rather than measuring, and numbers that survive scrutiny, so the team argues about strategy instead of about whose figure is right.
How we build for martech
We start by mapping the stack and the data, not by proposing a tool. Which systems hold what, which identifiers exist, where the same customer lives as three records, and where consent is captured versus where it is actually honoured. This audit almost always reveals that the presenting problem (“we need better personalisation”, “we need attribution”), is really a fragmentation-and-data-trust problem underneath. We would rather tell you that early than sell you a project that papers over it.
We treat identity resolution as the foundation everything else sits on. Before automation or personalisation or analytics can be trusted, the stack has to agree on who the customer is. We design the identity graph, the matching rules, and the handling of the awkward cases: the same person on two devices, the shared family email, the record that should never have merged, because getting this wrong corrupts every system downstream in ways that are hard to unpick later.
We design consent in as a first-class piece of state, not a banner bolted on at launch. Consent travels with the customer: what they agreed to, when, against which notice version, across which channels, and it propagates to every system that acts on it. We would rather build this backbone properly once than watch a preference the customer set get silently ignored by the one tool that needed to know.
We are honest about what data can and cannot do. Attribution is directional; personalisation depends on clean consented inputs more than clever algorithms; and a lot of what the customer imagines doing with their data is now constrained by law. We say so plainly, because a martech system that quietly oversells its own certainty causes worse decisions than one that is candid about its limits.
Because we operate what we build, we design for the messy middle: the vendor webhook that arrives twice, the identity merge that has to be reversed, the consent withdrawal that must take effect everywhere before the next send. These are not edge cases in martech. They are the daily reality, and building for them from the start is the difference between a stack that can be trusted and one that quietly leaks errors.
Privacy, consent and the rules that shape martech
Two regimes dominate UK martech, and they are not the same thing. The UK GDPR governs any processing of personal data: how you collect it, what lawful basis you rely on, how long you keep it, and the rights customers have over it. PECR, the Privacy and Electronic Communications Regulations, sits on top and governs electronic marketing specifically: it is PECR, not GDPR alone, that sets the rules for marketing by email and SMS and for cookies and similar tracking technologies. A martech design has to satisfy both, and they constrain different things.
For email and SMS marketing, PECR generally requires consent, with a narrow “soft opt-in” allowance for existing customers on your own similar products. In practice this means the sending system has to know, per person and per channel, whether it is permitted to contact them at all, and that permission has to be current. A list you may lawfully email is not the same as a list of addresses you happen to hold, and building automation that ignores that distinction is how organisations end up in front of the ICO.
Cookies and tracking are squarely PECR territory, and this is where third-party cookie deprecation bites. Non-essential tracking requires consent before it runs, which means analytics and personalisation that historically fired on page load now have to be gated on a consent signal, and degrade gracefully when it is absent. Designs that assume tracking is always available produce both compliance breaches and misleading data, because the tracked population is no longer representative.
Underneath both regimes is data-protection discipline that shapes the whole architecture: a lawful basis for each use of personal data, data minimisation so you hold only what you can justify, retention limits, and the ability to honour access, deletion and objection requests. In a unified-profile world those rights are an engineering requirement. You cannot delete a customer on request if you cannot even find all their records, which is one more reason identity resolution and consent belong at the centre of the design.
To be clear about our lane: we are the engineering partner, not your data-protection officer or your legal adviser. We build systems that implement the consent rules, retention policies and data-subject rights your privacy function defines, and that can demonstrate compliance when challenged. The definitive judgement on your lawful bases, your notices and your PECR position comes from qualified people, and we will build to their requirements rather than improvise our own interpretation of the law.
The martech integration stack
The Customer Data Platform, packaged or bespoke, is the hub the rest of the stack should revolve around. Integrating it well means clean ingestion from every source, identity resolution that actually reconciles records, a consistent event schema, and consent carried on the profile, so that downstream tools consume a single trustworthy view rather than each maintaining their own partial, conflicting one.
The CRM is usually the system of record for known-customer relationships and the sales-owned view of the account, and it rarely agrees out of the box with the marketing view. We build the sync that keeps the two coherent: reconciling identifiers, resolving which system owns which field, and making sure an update in one does not silently overwrite something authoritative in the other.
Email, SMS and push platforms are where marketing consent turns into an actual message, which makes them the systems that most need current consent and suppression state. We integrate them so that segments, triggers and suppression flow from the CDP and the consent store, and so that a withdrawal of consent reaches the sending platform before the next send rather than after a complaint.
Analytics, A/B testing and attribution tooling consume the event stream, and their value depends entirely on the quality and consent-status of that stream. We instrument first-party events cleanly, route them consistently, and make sure consent-gating is applied at the source, because analytics built on inconsistently tracked, partially consented data produces confident numbers that are quietly wrong.
E-commerce and product platforms are the source of the behavioural and transactional signals that make lifecycle marketing and personalisation work: carts, orders, browsing, product catalogues. We integrate these as live event feeds into the CDP rather than as nightly batch imports, so journeys and personalisation react to what the customer is doing now, not what they did yesterday.
The consent-management platform ties it all together, and it is the integration most often treated as an afterthought and most damaging when it is. We wire it so that the consent and preferences it captures propagate to the CDP, the messaging platforms, the analytics pipeline and anywhere else personal data is acted on, because a consent record that never reaches the systems that need it protects no one and breaks the customer’s trust.
Protecting customer data in martech
Martech systems aggregate exactly the data attackers and regulators care about most: names, contact details, behaviour, preferences and increasingly rich profiles of individual people. A CDP that unifies everything into one profile also concentrates the risk into one place, which raises rather than lowers the security bar. We treat the profile store and the event pipeline as sensitive-data systems, not as a marketing convenience, and design the access controls and data handling accordingly.
Data minimisation is a security control as much as a compliance one: you cannot leak, misuse or be forced to explain data you never collected. We push back on the instinct to capture everything just in case, and design so that the profile holds what there is a lawful, articulated reason to hold, which shrinks both the breach blast radius and the compliance surface at the same time.
Consent state is itself security-sensitive, because acting against it is both a breach and a harm. We protect the integrity of consent records (versioned, auditable, tamper-evident), so that you can always show what a customer agreed to and when, and so that a bug or a bad import cannot silently re-enable contact with someone who opted out.
The usual disciplines apply and are non-negotiable: encryption in transit and at rest, least-privilege access to profile and campaign data, and careful handling of the many third-party integrations a martech stack depends on, because each vendor connection is another path to the same sensitive data. Marketing tools are frequently the weakest link precisely because they are treated as low-stakes; we do not treat them that way.
Finally, the data-subject rights that GDPR grants are an operational security concern too. Deletion and access requests have to work across the unified profile and every downstream system, reliably and provably. Because we operate what we build, we design these paths to actually function under real conditions rather than existing as a policy no one has tested. The time to discover a deletion does not propagate is not when a regulator is asking.
What changes
One trustworthy view of the customer
Identity resolved and consent attached, so the whole stack finally agrees on who each person is, what they have been sent, and what may still be done with their data. The reconciliation-by-spreadsheet ritual stops, and campaigns build on data the team actually believes.
Consent that holds everywhere it matters
Preferences captured once and honoured across every channel and system, versioned and provable. A defensible position under GDPR and PECR, and a customer experience where an opt-out actually means opt-out, not a complaint waiting to happen.
A stack that behaves like one system
Tools integrated so journeys trigger on live signals, reporting reconciles, and the team spends its energy on marketing rather than on wrangling disconnected platforms and arguing over whose numbers are right.
What we build for marketing technology
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for marketing technology?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in marketing technology choose us
We fix the data problem, not sell you a tool
Our first instinct is to map your stack and your data, not to recommend another purchase. Most martech pain is fragmentation and untrustworthy data, and we would rather unify what you have than add one more disconnected record to the pile, even when that is the less lucrative advice.
Senior engineers who understand identity and consent
The hard parts of martech (identity resolution, event pipelines, consent propagation), punish inexperience quietly and expensively. Our people are senior engineers who have built and operated these systems, and who know the awkward cases because they have had to unpick them in production.
Honest about privacy law and about data’s limits
We will tell you plainly when something you want to do is constrained by GDPR or PECR, when attribution is modelling rather than measuring, and when personalisation is running on data you should not be using. We treat those limits as real, because they are.
We operate what we build
We stay with the consent edge cases, the identity merges that go wrong and the deletion request that has to reach every system. Living with those realities is exactly why we build the unglamorous plumbing properly the first time rather than leaving it as someone else’s incident.
Related sectors
Part of Advertising. Adjacent sectors we also know.
Common questions
We keep buying martech tools and things are not improving. Why?
Because the problem is almost never a missing capability: it is that the tools you already own do not share a trustworthy view of the customer. Each new purchase adds another disconnected record rather than resolving the fragmentation underneath. The fix is unifying your data, usually through a CDP and proper identity resolution, and integrating what you already have so it behaves as one system. We will map your stack before recommending anything, and more often than not the honest answer is to integrate rather than to buy again.
What is a CDP, and do we actually need one?
A Customer Data Platform unifies identity, attributes, events and consent from all your sources into a single customer profile that the rest of your stack can rely on. You need something that does this job if no system can currently answer “who is this person, what have we sent them, and what may we still do with their data”, which is most teams. Whether that is a packaged CDP integrated properly or a bespoke one depends on your scale and requirements, and we will give you a straight view rather than defaulting to the more expensive option.
How do you handle GDPR and PECR consent across the stack?
We treat consent as a first-class piece of state that travels with the customer (what they agreed to, when, against which notice, across which channels), captured in a consent layer and propagated to every system that acts on their data, from the CDP to the email platform to analytics. The point is that a preference set once is honoured everywhere and can be proven if a regulator asks. Note the split: GDPR governs the data generally, while PECR sets the specific rules for email, SMS and cookie tracking. We build to implement the rules your privacy function defines; we are not your data-protection adviser.
Can you give us accurate marketing attribution?
We can give you honest attribution, which is not quite the same thing. With cookie deprecation, cross-device journeys and consent-gated tracking, deterministic attribution is decreasingly complete and multi-touch models rest on assumptions. We build clean first-party instrumentation and reporting that is clear about where it is measuring versus modelling, so the numbers are directional and trustworthy rather than precise and misleading. A system that presents modelled estimates as hard fact leads to worse decisions, and we will not build one.
Do you build martech products, or just integrate our existing stack?
Both. For marketing teams, most of our work is unifying data and integrating the sprawling stack you already run so it behaves as one system. For companies building martech to sell (a CDP, an automation platform, a personalisation or analytics product), we build the product itself, including the multi-tenant data architecture, identity resolution at scale, and the consent and privacy controls that any serious martech product now has to offer its own customers as a core feature.
Building for marketing technology?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if marketing technology is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.