Why Our Platform: An engineer’s perspective

Picture this. You’re half-way through a sprint. Suddenly, Marketing and Sales decide to agree on something (they sometimes do) and start pressuring the Product team to add a new story into the sprint backlog. They want to integrate with {{weird_marketing_automation_platform_name}}, which feels completely alien in comparison to anything built by the team. Ah, and it’s urgent.

Developers start pushing back (this thing doesn’t fit into the rest of the application at all, everyone is worried about the Frankenstein being created, etc), but Marketing managed to get the purchase approved and now the sunk cost fallacy kicks in: the company spent too much money on this purchase, and it’s from {{giant_vendor_name}}, so the engineers will have to make it work.

Fast forward to the sprint retrospective, and everyone is complaining about it. It completely disrupted the sprint goal so the original stories weren’t delivered. The final solution looks horrible and the experience for the customer is actually pretty bad: they now receive 40 different emails with information packs for no apparent reason and are left wondering what in the world is actually happening. There is absolutely no way to tell whether or not this initiative is actually moving the needle, and poor Andrew, the dev who took most of the blows for this integration, hasn’t spoken in 72 hours — except for the occasional muffled scream which everyone can tell is a horrible profanity.

Does this feel familiar, if slightly exaggerated? Probably. I’ve seen it happen countless times in so many companies.

Why does it happen?

There’s always been a big divide between divisional silos in most companies. The whole situation of Sales vs Marketing vs Engineering — sometimes Engineering, Product and IT/Ops are also broken into separate departments — is constantly turned into memes. It’s a problem that’s deeply rooted in corporate culture. Obviously, if you’re always fighting to get your work prioritized, you end up trying to find alternative solutions. 

When you look at marketing specifically, this creates a huge landscape of thousands of SaaS tools - most of them focusing on really narrow problems — that have to be integrated back into the overall stack. These tools are often satellites of the really big tools provided by one of the giant vendors — all of which cost an absolutely insane amount of money.

This patchwork of software ends up creating something that’s hard to understand, manage, maintain and extract value from, which causes the return on investment to be insanely low.

A few digital natives (e.g. Uber, Airbnb, and so on) are able to architect from the ground up for real-time (think event streams, websockets, pub/sub, etc), which in turn accommodates the type of marketing/customer experience (CX) initiatives described above with much less drama. That said, it still costs a lot and requires highly specialized skill sets. Not to mention an incredible amount of custom code.

What it means for engineers

There are a few things that come out of this, all of which are less than ideal:

1. The maintenance of fragile integrations between these SaaS tools ends up becoming a developer’s job.
2. People get scared of using these tools to their full potential. A whole string of processes that could easily be automated end up becoming manual (raise your hand if you ever had to SSH to a bastion host to run a script — or, even worse, manually change a database record for something that clearly should have been automated). 
3. No one really understands what these tools can and can’t do — so a lot of features that aren’t critical to the application end up being developed as integral, synchronous processes. Now there’s increased latency for the whole app in order to send an email with recommended products after a single purchase (which, don’t get me wrong, is super important — but shouldn’t have added 10 seconds to your checkout).
4. Valuable information is scattered across a whole mess of decentralized datasets in an array of cloud applications from different providers. Ingesting, mapping, understanding and classifying all this data becomes a huge job — which not many companies manage to do well. It all just goes to waste — a data nerd’s nightmare.

So, again, why Our Platform?

When we started MakerOps Inc., we had identified the gap between the real-time experience that most customers today expect and what most companies are able to deliver due to the processes described above. We decided we weren’t going to add to this problem. We didn’t want to just create another SaaS tool and throw it into the already fragmented technology landscape.

We have a team with decades of combined experience in all the areas I mentioned at the beginning of this post — Marketing, Sales, Engineering and Data Science, among others. From an engineering perspective, these are the things we set out together to deliver in order to achieve our goal of helping companies offer real-time experiences (real-time X):

1. A highly scalable event stream that’s about as plug-and-play as it gets. You instrument your applications and ta-da — events are flowing through this stream. The number of events is growing? No problem: the stream can handle it. No configuration needed.
2. A visual workflow builder that, out of the box, can solve most CX requirements. No more writing custom applications to do simple things such as sending an SMS/email because a user performed a particular action. It’s all solved without code, so engineers can focus on solving the hard problems.
3. A really simple way of adding custom code. There’s no substitute for good old code when you have a really complex problem, so you can literally just add your own functions as workflow steps. And it’s all just run-of-the-mill functions — no snowflake DSL that feels about as familiar as a helium-based life form from another galaxy.
4. A data lake that’s automatically hydrated based on the events that are being collected. Events collected from user actions are also automatically stored in the Experience Data Model format — meaning less time worrying about different models and how to map them. Things are standardized and ready to be analyzed.
5. A way to visualize how your users are interacting with your application. User profiles are automatically created as events come through. You can also see a timeline of events — even the ones that are coming through in real-time.
6. Who likes to write custom HTML for emails? I don’t. I’m sure you don’t, either. We added a template manager so SMS, emails, and landing pages can be templated and built using a drag-and-drop interface. Any variables can be interpolated in real-time as part of a workflow. Amount of code written? Zero. Amount of time spent testing the emails in 493 different email clients? None.

It’s all done with no infrastructure concerns: no DevOps overhead, no configuring VPCs, subnets, security groups, Kafka clusters, Lambda event sources, and so on and so forth — you just instrument your applications to collect events and write the eventual function, if necessary as part of a more complex workflow.

This is how our platform is helping companies automate real-time customer experience operations - by ensuring that the business tools are well aligned with what engineers expect and want. Business value can and should be created without the introduction of massive amounts of tech debt and complexity.

It’s all about speed and enablement. It’s also about the future. We believe the future is unified across the business using intelligent processes that can analyse events in real-time and classify, learn, predict and action — but we don’t see ourselves as the sole builders and gatekeepers of this future. We’re interested in providing the tools that enable this vision, so we can build it together with our community. Engineers can focus on building things that will provide the biggest bang-for-buck while experiences can be automated with minimal friction. Valuable data is easily available, so everything can be done in a more scientific way: it’s a win for everyone.

Real-time X has always been difficult. Navigating through the maze of SaaS providers and tools, along with messy datasets and fragile integrations tends to require large teams with extremely specialised skills that most companies can’t afford, find or attract. 

We’re here to level the playing field and allow any company, large or small, hyper-technical or completely analog, an equal chance to delight their customers, employees and suppliers with real-time X.

If any of this sounds interesting, don’t hesitate to reach out — we’d love to hear from you!