Building a Startup, Part 1: Creating The Shadow Infrastructure

When building a startup, there are many obvious things you know you need to do. Hire great people. Focus on a big space and own it. Get input from customers. Build cutting-edge technology that scales. The list goes on and on.

What my team didn’t expect was how much time we would spend thinking about, building, and wiring together Voicera’s world-class data backend.

Eva, Voicera’s enterprise voice AI, interacts with our customers on the phone, SMS, our web app, calendar, and email, as well as through third-party integrations like Slack, Salesforce, Google G-Suite, and Office 365. We focused on integrating Eva wherever a professional spends time. In building a startup with a product that has this kind of 360° surround, we found we also had to develop and integrate a shadow infrastructure to give us visibility into our customer lifecycle, product utilization, and trends. This technology had nothing to do with our core product. But what we ended up with allows us to analyze every touch we have with customers and serve them faster and in a more personalized manner.

The level of investment required to deliver this level of visibility for our startup was not initially obvious to us. Over the course of the last year, we learned a lot.

I wish we had a guide to follow before diving in ourselves—so the hope is that this three-part series helps provide a template for the next startup founder to stub their toes just a little bit less.

Establish Your Approach

There are lots of different paths to building and instrumenting a startup. On one extreme, you might choose a single vendor, do a heavy deployment, and hope that their roadmap supports you as your needs evolve. Or you could go with a curated set of best-in-breed point solutions, which individually might give you great tool sets, but leaves more of the wiring to you.

While our needs have evolved, our approach has remained fairly consistent. We curate a set of tools to use, push them to their limits, hold them to a high bar, and when we outgrow them, we upgrade individual components. The single most important advantage of a startup is speed. We didn’t want any single component to hold us back.

Our approach to creating a shadow infrastructure for our AI product focused on five attributes:

WYSIWYG: We wanted our marketing team to be able to quickly make as many changes as possible with minimal impact on our engineering team. This meant we were looking for tools that provided powerful “what you see is what you get” (WYSIWYG) interfaces for templating, targeting, and deployment.

Light Footprint: We wanted to minimize the size of the third-party JavaScript footprint we had to deploy. We strove to implement tools supporting async server-to-server integrations, minimizing data passing on the client side.

Universal Data Bus: Our various systems must be aware of each other. For instance, if a user had a bad product experience in our web app, we wanted our email system to be informed, our support system to log it, and our engineering team to be able to trace it. We also would want that captured in our business intelligence dashboards and proactively recorded in Salesforce.

All of these use cases are possible without a shared data layer—we could plug each tool directly into our backend, but that seemed brittle and a waste of time. A data bus that could be integrated once, and which could federate data between and across systems, seemed like a good idea.

Speed to Deploy: We were overwhelmed by the number of tools on the market, and we were not sure which would work best for us. We wanted the ability to deploy quickly and efficiently, test tools out on real production data, and then spin them down if they were unsatisfactory. We looked for cleanly designed APIs, the ability to purchase and set up the integration without talking to a human, good documentation, and swift response times to customer support issues.

Best in Class: We wanted to make sure that we were using the best tools we possibly could and had the flexibility to substitute components as we grew. Since no single vendor or solution is best in class at everything, we made this choice knowing that we would own the burden of making different components play nicely together. In hindsight, this was the right choice for us.

Whatever your needs are, take a step back and think about what matters most to you. It is very easy to jump right into a tool or get enamored with some feature that will end up mattering less in the long run.

To prevent this, put these attributes into a formal document that all stakeholders can easily access and add to when evaluating platforms. That way, everyone is literally on the same page when vendors come calling, and you’ll end up with a single scorecard that includes everyone’s feedback on how various platforms compare.

Once you have a rough sense of your overall approach, the next step is to map out your product use cases.