Copying Big Tech is Hurting Startups
How blindly following FAANG/MAANG and other big boys is slowing down startups world wide, and what to do instead.
In hype-heavy SaaS Startup land, looking in awe at the big boys and what they’ve achieved is the natural state of being.
Every startup wants to be a unicorn, so whatever these companies do is taken for sweet cake, overanalyzed and used as blueprints for success.
There’s nothing wrong with learning from the successful, by the way.
The Uber story, for instance, is well documented, and can be used for all kinds of learning paths, such as Lean Startup principles.
The same goes for Dropbox.
Many Big Tech companies have shared a lot of inside information that has helped the tech community, and most of these giants have contributed a lot to the open source community.
But while it’s great fun to look at what they did to become successful, and there are great takeaways from their early steps, it’s something else to idolize these companies and simply copy their ‘best practices’ onto your tiny little startup.
I would even argue that applying some of these practices will hurt you.
Here are five Big Tech practices that might be great at the scale they operate at, but are probably ill-suited for you:
1️⃣ TAKE A MICROSERVICES APPROACH
This one’s really persistent.
I’ve seen plenty of startups getting stuck in the mud while trying to go for a full-blown microservices architecture.
One example I’ve already mentioned in an article is the case where a relatively inexperienced team inherited quite the monolith, and ambitiously overreacted in wanting to ditch it, overstretching in their efforts to create a full blown microservices architecture.
Result: complete standstill, because they used a big-bang approach and release an alternative platform 2.0, instead of trying to slowly iterate away from the monolithic legacy using the Strangler Fig pattern (a best practice to slowly ‘strangle’ old code out while keeping the solution working).
It’s a much better idea to start out small, using well-known principles to make things modular, yet easier to build, test, deploy and manage.
The so-called Modular Monolith is a compromise between the classic monolithic architecture and the more modern microservices architecture. It involves dividing a large, monolithic application into smaller, self-contained modules that can be developed, tested, and deployed independently.
This approach allows for more flexibility and scalability than a traditional monolith, while still retaining some of the benefits of a monolithic architecture, such as simplicity and ease of deployment. The idea is to keep the application as a single unit, but with well-defined boundaries between the different parts. This helps to avoid the complexity and overhead of a microservices architecture, while still allowing for a more scalable and adaptable application.
Once you’re ready, parts of the modulith can be taken out into independent services (which might be microservices, but could also be serverless functions).
The key consideration when moving into a more complex, distributed landscape is that your team structure needs to be ready for it.
No distributed software without distributed teams.
2️⃣ USING BIG, BLOATED FRAMEWORKS
In 2013, Facebook was faced with the issue that the way their platform worked was not sustainable, with the growing amount of moving parts in your average endless-scroll-enabled Facebook page.
React was their answer, and it solved this continuous updates puzzle.
But you’re not Facebook (or Meta).
Also, it’s not 2013 anymore.
With the evolution of the Modern Web (post IE), there is a growing movement towards embracing native Web Standards (such as Web Components) and considering the Browser to be a framework on itself.
Contrary to 2013, there’s an overwhelming amount of arguments to not start with a big framework:
1. Browser Evolution
The browser has evolved a lot since 2013. Some of the main root problems that made Facebook develop React have long been solved, in that the browser’s rendering engines are now much faster, and especially much more efficient in their in-place re-rendering of individual elements (details here).
2. Language Evolution
The language itself (ECMAScript) has evolved, and now has a lot that would have avoided a 100% proprietary, extra syntax like JSX to even be invented. String/template literals and variable resolving are now built into ES (since 2015).
Imagine how much more efficient the right side code is, with so much less custom processing…
3. Dependency Hell
Once you start using a framework, you’re no longer in control (the framework is). This increases the probability that you’ll need a framework-specific NPM package for everything you need to achieve that the framework doesn’t do automatically, or what it does in a way that doesn’t suit your needs.
This then gets worse when developers are so terribly ill-informed about what the web can do natively (see under 4️⃣). I’ve worked with React developers who didn’t know that the <input /> element could have other than “text” or “password” types. The framework package ecosystem was their answer to everything.
4. Custom Elements / Web Components
Custom Elements (Web Components) are a native way to extend HTML itself. A perfect way to encapsulate syntax, styling and logic, that is far superior to any rendering framework in terms of efficiency, speed, memory usage, and (network) bandwidth usage.
Instead of needing a framework to make the above syntax work, the browser already understands it, and attaches your custom elements to the DOM.
You can then add small pieces of JavaScript and CSS to your component, tie it to its own component code base, and reuse it everywhere.
In fact, by using web components, you just started removing the dependency on a framework in developing UI Components, as you can use the same web components across all frameworks (and in vanilla JS code of course).
5. De-JavaScripting
There’s a recent trend in web development that says JavaScript, these days, causes the biggest penalty to user experience, and we have to try to cut back on it.
This means less use of big bloated frameworks, more focus on vanilla javascript on top of semantically correct and functioning web pages, progressively enhanced with vanilla javascript (and mainly custom elements/web components).
Some of the people promoting this approach are Jeremy Keith, Alex Russel (@slightlylate, Infrequently Noted), Paul Lewis, Addy Osmani (@addyosmani), Rob Eisenberg (EisenbergEffect), and myself (/in/mvneerven).
Away from having <𝚍𝚒𝚟 𝚒𝚍=”𝚊𝚙𝚙”></𝚍𝚒𝚟> being the one tag to hook up your app to, and a big JS bundle having to come across.
Away from SPA solutions even 🤯, because Web Components are ideal in MPA setups.
Unsurprisingly, good ol’ progressive enhancement — but now with Web Components, is getting traction again. Jack Franklin of Google has described it as island architecture.
Selecting a frontend stack is a big choice, one you’re better off using your own criteria to make it, instead of just hopping on the bandwagon.
Not selecting a framework, and in fact consciously trying to leverage the actual power of the web, with as little JavaScript as possible, is kind of refreshing!
3️⃣ ADDING MORE AND MORE FEATURES
If you’re tempted to keep adding more features to your app before having tested the waters, chances are you’re simply unclear about what makes your initial offering stand out.
This is a big problem, because you’ve probably lost touch with your audience. Finding product-market-fit needs to be an efficient game, since you haven’t got traction yet.
The big boys might be adding features continuously, at a pace you can only dream of.
But your forte is your niche, and what you should aim for is hitting that sweet spot, that approach that makes your MVP an MLP (Minimal Loveable Product). The unique touch that makes your end users loooooove every touchpoint with your software.
If you can’t quickly name it, it might be time to reflect on whether you actually know what your Unique Value Proposition, your USPs are.
If you have clear unique selling points, you don’t need the extra features (at first).
Ash Maurya’s Lean Canvas can help in identifying and validating your USPs.
4️⃣ DEVELOPING A NATIVE MOBILE APP
There are still startups that assume they’ll need to develop both a Web App (for desktop use) and two native mobile apps (Android & iOS), just because the largest SaaS companies in the world have done so.
Then there’s a large group that will tell you this is no longer needed, and that there are frameworks that will allow you do it all from a single code base. This narrative is heavily influenced by Big Tech like Google and Meta (Flutter, React Native).
While these frameworks provide solid development platforms, the underlying statement seems to be: forget about the web platform itself if you want to target web and mobile from one code base.
This is an extremely persistent, but very wrong portraying of the web’s maturity, and I’ve been scratching my head about it for a long time.
Until this year, when the State of HTML survey (official results coming soon — December 2023) show us that a vast majority of web developers knows less than half of what the web can do.
I was in the top 1% of all respondents, by scoring 87%, while someone I know was still in the top 25% with a score of 45%.
This means that even senior Web Developers are not up-to-date with the native capabilities of their web browser.
In fact, they’re often surprised when I tell them what I use built-in browser capabilities for.
While your app could be an exception, it makes sense to start from a standpoint of not needing a native app until you do, instead of the other way around: a PWA (progressive web app) may be more than enough, and it will certainly make a difference in costs and hassle.
The argument of the frameworks being well-documented compared to standards stuff are simply not true. There are great resources that help you with anything, ranging from general purpose to standards reference material:
PWA
Custom Elements & helper libraries
Reference
… and obviously StackOverflow and Generative AI (ChatGPT, Co-Pilot, Phind, etc.)
5️⃣ MANAGING THEIR INFRASTRUCTURAL SETUP
Too many startups end up building a solution like we did 20 years ago.
In 2019, I wrote a piece here about what a paradigm shift Native Cloud is.
Here’s a table from that article, that shows some of the main elements of that paradigm shift:
Obviously, you don’t have to go all-in at once, but IF you start really leveraging the power of native cloud, you’ll also notice that your managerial overhead on deploying, scaling, securing, optimizing, and maintaining will be drastically lowered:
The cloud provider takes care of most of it, if you use managed services and serverless offerings.
But to do that, you must overcome two issues:
- Your fear of vendor-lock-in
- Your Native Cloud knowledge gap
From a CTO perspective, let me reflect on both issues.
Fear of Vendor Lock-In
Some people I speak to are heavily concerned with the possibility that Cloud Providers would suddenly die, or double prices overnight. Admittedly, this would be kind of a problem, wouldn’t it.
For me, it’s mostly fear of the unknown, and maybe just bias.
I’ve been in the Cloud field for more than 10 years, and I can safely say that prices have only been going down, while capacity and capabilities have grown exponentially.
One word: competition.
Also, the risk of Amazon, Microsoft or Google stopping with their Public Cloud offering is, let’s say, minor.
If, still, you want to have an easy opt-out, consider separating your core logic from the syntactic sugar that’s needed to set up stuff like serverless functions, so you can keep using it and just need to look at the plumbing. Not that your work will be done, but at least it will ease the pain.
For me, the benefits of Native Cloud will always outweigh the risks. Hands down. Especially for everything smaller than a Unicorn. And when you do reach serious scale, you can reevaluate and maybe think of doing what 37signals did last year.
Your Native Cloud knowledge gap
Sure, if you don’t yet know how to leverage the power of Native, Managed Cloud, there’s a need to be told how, but it definitely comes with the benefit of not having to deal with a lot of stuff. In fact, for startups, it frees up a lot of headspace and operational costs, and allows you to focus on how to get your MLP (see above) out.
And when, suddenly, you get PMF, and traction goes through the roof, you’re assured that your SaaS will scale with it, regardless. Because true Native Cloud is elastic by nature (scales up and down automatically).
Starting out with Native Cloud is much easier than you think, but it really starts with being curious and open, having a continuous learning mindset.
This is exactly what I see going wrong in many young startups, who hire a developer who starts building yet another app as a containerized solution, running on his/her machine, simply saying “it’s a container, deploying is lift-and-shift to any hosting party!”.
One tip: don’t treat Cloud as a deployment destination. Treat it like an ecosystem. It’s not an afterthought, it’s a way of working.
If you think DevOps are people who take your solution and coordinate putting it into the Cloud, you’re wrong: DevOps is a culture!
Conclusion
As tempting as it may be, don’t just blindly follow the practices that the well-known giants are using or marketing. The problems they needed to solve are not your problems, and you don’t have their scale.
It’s okay to look at how they’re addressing things, but please dive a bit deeper, such as looking at what they did at a certain point in their journey, when they operated around your current scale.
And then apply some more thinking.
Create your own blueprint, using Lean and Design Thinking: reduce waste, and continuously try to do things as efficiently as possible, with wowing the end user in mind.
