The California Gold Rush (1848–1855) lasted only 7 years. In that amount of time, it brought 300,000 people to California, invigorated the US economy, played a key role in ushering California to statehood in 1850, and caused a precipitous population decline of Native Californians.
One of the most profound lessons of this period in history stems from the analysis of winners and losers. It is well known that merchants made far more money than miners during the Gold Rush. One of them is a ubiquitous American brand Levi Straus & Co that is still selling rugged and durable work pants that put them on the map (‘wild horses could not tear them apart’). The great thing about supplying prospectors was the steady business: they needed shovels, tools, food, clothing, lodging – irrespective of whether they ended up finding gold or not. This is not much different from investment banks charging fees for every trade. They reap the profit by making the market, not by going long or short.
A similar dynamic is now on clear display in Silicon Valley. Less that 100 miles from Sacramento and Coloma, the ground zero of the original Gold Rush, modern merchants are popping up at a great speed. Their common goal is to supply startups with everything they need on their quest to the magical inflection point, when your traction graph turns into the coveted hockey stick.
Modern merchants
There are currently many examples of companies built with the express purpose of supplying startups running their 1.0 experiments. To qualify, a company needs to have a business model that does not directly sell a service or product to customers. Instead, their customers are startups and their business model is that of enablement.
Consider these examples – there are many more, but I am using some I personally came across or had to evaluate for our own product:
- Optimizely – one of the key properties of building a 1.0 product is the extreme uncertainty. Most startups are throwing platefuls of spaghetti at the wall, hoping some will stick. The technical process of throwing the spaghetti is called ‘A/B testing’, and Optimizely allows you to create experiments, expose your users at A or B variant of any part of your product, and find the winner. You don’t quite know why A or B is better but Optimizely can tell you which one to pick.
- Appcues – common startup headache is getting users to understand your value proposition, use your product and stay with it long enough to drive up engagement metrics. Appcues will allows you to create product tours, and even follow users through tasks, observing their progress and suggesting next steps.
- LaunchDarkly – 1.0 products are a mix of key features that work well, and newly built features that are a bit more shaky but may still offer value to some users that opt in. Controlling the feature flags, dynamically updating them, building up white lists and other more sophisticated ways of controlling your product gets complicated quickly, and many startups delegate this to LaunchDarkly.
- Stripe – once you achieve engagement and a growing list of returning users, it’s time to monetize your idea. That means managing payments – what Stripe does.
- Freshdesk – once you get paying customers, you need to provide customer support. Freshdesk offers support ticket management and various tools to streamline the support process.
Why do these companies even exist? Because most startups are based on a single, hopefully groundbreaking idea. Operationalizing that idea and bringing it to users is like a series of concentric circles, with layers of table stakes around the pure idea. Most startups want to get the idea out as soon as possible (they are racing against the VC funding runway), and need to outsource most of the enabling facilities.
Building most 1.0 products is like building a tent city – you need to do it fast, and be able to dismantle and move to a different location on a moment’s notice (should pivoting become necessary). It is simply not cost-effective to invest in building sturdy brick houses at this point in time.
The dangers of outsourcing
I am not a fan of any of these products. This should come at no surprise as I am not working for a startup. I work for a large company that can fund a new idea until it runs out of patience, not money. But you don’t need to work for a large company to share my sentiment – all you need to do is work for a startup that saw the hockey stick and is now building version 2.0 of your product, having validated the idea and secured long-term funding and even some revenue.
Modern merchants are Trojan horses
This is common sense – most of the companies I listed above are in the Cloud, and you engage with them by creating an external account. In order for their value-add to find a way to your product, you need to place some glue JavaScript in your pages, invoking the APIs with your account’s API key. Not all of the supporting apps work like this – some can be called on the server side, but sufficient number of them act too close to a Trojan Horse for comfort.
For example, Optimizely allows you to run A/B experiments by controlling portions of your site. You can inject any DOM element directly through the client side API you add to your own page. It does not even have to be malicious – a junior Offering Manager can make a mistake and instantly break your product in production, bypassing Dev/QA/Prod quality control process you so carefully constructed.
In the interest of full disclosure, Optimizely does acknowledge this problem and now offers Optimizely FullStack option, allowing server side A/B experiments, where developers fully control the page elements they are testing.
Appcues is actually making it clear in their Enterprise marketing page:
Empower your teams to create compelling user experiences without engaging engineering and development resources.
Appcues Enterprise
Obviously, the only way you can ‘create compelling user experiences’ without ‘engaging development resources’ is by bypassing your engineering and injecting UI into the pages directly, from a third-party server, at real time. Developers are going to love that.
Once the neck-breaking days of 1.0 are over, you will want some quality control of your development process. This will become really hard if your product is a Frankenstein’s monster, containing a mix of your original code and many third party services. At any given point, interruption in these services can affect your site (I am not even talking about actual Cloud compute and storage providers – that’s one layer below). It is also hard to enact any kind of development process progression. You can run any number of automated Q/A tests in your pre-prod stage – a significant portion of your product’s behaviour is controlled outside of your build approval process.
Data security issues and global operations
As these modern Gold Rush merchants assist you in vital operation of your 1.0 product, they have access to sensitive areas – PII (personally identifiable information), users, data they generate, account transactions, engagement metrics etc. Of course, each of them will tell you that security is very important to them, and will have dedicated resources about their security posture. Nevertheless, your product’s security guarantee is dependent on the sum of the security guarantees of each and every third party service you use. This may be acceptable as you are getting your loving product off the ground, but may become an issue once you start growing your 2.0, or try to launch the coveted Enterprise edition. Enterprise customers are known to ask prickly questions about security, and may frown at your use of any of the services that got you thus far. It may even become impossible to secure GDPR compliance with some of them, simply because they don’t have servers in the right geography, or are not GDPR compliant.
Even if you manage to retain satisfactory security posture, some of these services may become a limiting factor of your growth plans. Many of these products are built by California startups themselves, and lack worldwide deployment. This means that even if you start deploying your product to various data centers around the globe, calling back to US West coast servers may invalidate most of the performance gains of deploying closer to non-US customers.
Cloud dependency
Regardless of how you engage with these products (client side or full stack), they exist as third party servers you need to talk to. Most Enterprise editions of Cloud products install on premises. As a rule, most startups born on the Cloud dream about the point in the future when they will offer Enterprise edition and finally make it big. Unfortunately this entails being able to make your entire product installable behind Enterprise firewalls (my daily life involves using Enterprise version of a number of the popular Cloud products such as GitHub, Slack and Travis behind my company’s firewall).
Once you get to this point, you will rue the day you became so dependent on dozens of modern Gold Rush merchants. You will have to slowly replace each and every one, or disable them in the Enterprise edition. Luckily, some of them will simply not be needed: for example, financial transaction management is useless because Enterprise versions are typically sold through sellers or paid online, then downloaded and installed.
Enterprise customers frown upon any outbound traffic attempt from their servers (some insist on air-gap environments), which means that most of the usage tracking tooling will need to be disabled (or replaced with batch tooling that collects usage, then sends it as a digest, not real time, assuming it is enabled by the Enterprise customers).
A pattern I have observed in recent years is that companies with Enterprise versions of their products use their Cloud counterparts to pilot and launch new features, and run experiments there. Once hardened, they are made available in the Enterprise version, minus all the supporting Cloud software. Features typically lag the Cloud version by 2-3 months, subject to customers’ maintenance windows.
Parting thoughts
I don’t want to leave you with an idea that products I mentioned have no place in the modern application architecture. My advice is to simply understand what they are – ready-made parts of a 1.0 US West Coast-based Cloud product prioritizing rapid growth. If that fits your startup, gobble them up.
If, on the other hand, your product is more mature, has established customers, you are not a startup any more, want to regain control over your development process, security and performance, need worldwide deployment, or are building Enterprise edition of your product, understand that you will most likely have to re-build most of that functionality in-house.
Last but not least, be on the lookout for organizational warning signs. If the Design Lead pushes for Optimizely so that she can run the A/B experiments without having to deal with the impossible Development Lead, software is the least of your problems. The last thing you need is your organizational power struggles to drive your product architecture.
© Dejan Glozic, 2019
Dejan Glozic 
Leave a comment