• by James Rooney , December 3, 2014

At some point, marketing technology companies face a decision: license some existing product, or build it themselves.  Almost regardless of company size, this is a near-constant question.  Choose poorly and you’ll soon end up with the dreaded “Frankenstack.”  Choose wisely and you can have a smoothly integrated system of licensed and internal subsystems more quickly and at lower cost than building everything in-house.  

The proponents of a fully in-house tech stack are vocal about how stitched-together Frankenstacks are problematic due to poor integration between point solutions.  This is fallacious – pointing to a given poorly integrated system, calling it a Frankenstack, and concluding that any other hybrid system must also be poorly integrated doesn’t make a lick of sense.  Properly considered system integration will provide maximum good at the lowest cost of manpower and dollars; that’s the point. 

The most effective approach to building a tech stack is actually pretty straightforward.  The devil is in the details, and the hardest challenge is sticking to the approach when outside parties (clients, management, sales) are clamoring for a faster rather than optimal output. 

First, you need to perform a simple evaluation of the inputs and desired outputs.  Don’t get hung up on the how yet; we’re defining the platonic ideal at this stage, with no compromises.  Once you ascertain your goal, lay out the components needed to achieve it; you’ll want to loop in engineering resources at this step. 

Then the real legwork starts: the discovery phase.  Here you’re evaluating what’s already commoditized and available to buy or license.  Many times you’ll find an existing technology that does exactly what you need for each component; there are a lot of ad tech companies building a lot of products and there’s a good chance your use has been solved.  If an existing product doesn’t meet your need exactly at a commoditized price, then you face the big decision: do you change your desired goal to work within the closest fit, or build exactly what you want? 

Note that “we’ll deal with that later” isn’t an option.  As soon as you start on that path you have started a Frankenstack, and while sometimes you can fix it later, if you can’t, you’ll have to start from scratch or be saddled with an insufficient output.  Forever.  This is the critical time, where an extra week or month designing the right solution – or not taking that time – will define your stack.    

The bottom line is that inter-operability between disparate parts is totally achievable as long as one does due diligence.  Bad “Frankenstacks” generating data sets that can’t talk to each other cleanly is a nightmare, but one that is always avoidable.   The major mistake that a lot of companies make is that when bringing in a new component, they don’t ensure that the new part is within the same cookie space (or other form of compatible user space) that syncs to the existing stack components, or they allow the connection to happen at too high a level such as “campaign” rather than “impression.” 

Hybrid tech stacks can deliver the benefit of having lots of outside engineering talent solve problems you’re not interested in, so you can devote all of your engineering to the problems your clients are interested in.  That drives business value, keeps in-house engineering focused on the hardest problems, and gives your clients the best possible complete end-to-end solution -- regardless of who builds each cog in the system.