hckrnws

This may be a bit of an old allusion, but Lotus Notes is a great example of this. Notes is fundamentally a programmable, non-relational, client/server replicated database with a UI on top of it. It's a workflow engine for accomplishing whatever business processes a company might have that can be made to keep working pretty well when the client computer is offline. It can be anything.

But it is remembered first and foremost as an email system, a feature that's fairly trivial to implement once you have a replicated database and a UI on top of it that can display lists and text. But it had to be an email system first because you can't sell something that can do anything if it doesn't do anything.

I remember a long long time ago people used Filemaker Pro for all sorts of small data driven applications. I used to think stuff like that would be the future of computing, but instead Filemaker Pro faded into obscurity and most people just use Excel for those kinds of problems now. Or worse, the problem is solved in a clunky and fragile way with outrageously expensive Peoplesoft/Workday/Salesforce type solutions.

That is kind of how it went, but there was more than email in its early days. Email existed, but Lotus also sold a separate email product. The rumors at the time ('94) were that Lotus was going to remove email from Notes and focus on apps. But instead IBM bought both and merged them. It got kinda lost from there, while also getting way bigger, but that is a different story.

Even so, it did have some app templates that came with it back in those early days - a helpdesk ticketing system, a sales CRM, discussions. I forget what they all were, but there was definitely a base of examples aside from email for people to start with.

I spent about two years in early development of a "Zombocom" product and one question on my mind was "Whatever happened to Lotus Notes?" Superficially it seems the time is right for a rapid development platform for web apps based on an object database with synchronization support. I was sharply divided about the role of email in such a product:

I became a qmail fanatic around 1999 and enjoyed running a smart mail server but as we got into the early 2000's I experienced a series of crises involving worms, viruses, malware, spam, deliverability and such. Today I want nothing to do with running a mail server! It's not a problem where you can just invest once and it is done but instead it is like one of those service games.

I like the idea of email as a paradigm for asynchronous workflows, and if you're doing business by email (as in CRM) it is useful. On the other hand today the email market is pretty tied up with the likes of Gmail and Outlook

I worked at Seagate in the early 2010s, and they made pretty intensive use of Lotus Notes across the company—-it was pretty dang cool to see how sophisticated/useful the internal applications were that non-“developers” created!

That's HCL Notes, now... https://en.wikipedia.org/wiki/HCL_Notes

Probably because they already had to support it. HCL won IT support contracts in many banks across Europe and probably elsewhere. I reckon many of those banks still use old IBM tech like mainframes and Notes (for email and internal apps). It's hard to support something when it's EOL and you don't have the source code.

Domino and Notes is still being actively developed by HCL... https://www.hcl-software.com/domino

I was going to say you couldn't pay me to use Notes again. I went to the link you posted and here was on the top carousel something interesting... So domini/notes is under active development, by a witch company no less.

I just have a terrible experience using Notes. I have either somehow erased or locked away most of this memory but I remember getting back to Outlook with a job at a different place and thinking I'll never bad mouth excel again. Yes, notes was that terrible for me.

----

CRITICAL ALERT: The Domino Development team has identified an issue that will affect ALL Domino server versions as of December 13, 2024.

If you have no active support contract with HCL for Domino; we would like to assist you in resolving this issue. Please fill out our form and one of our specialists will be in touch with you to discuss your options.

See our Knowledge Articles below for more information: Dec 13th Defect Fix Guidance for IBM Domino v9.0.x and v10.0.x Customers https://support.hcl-software.com/csm?id=kb_article&sysparm_a...

CRITICAL ALERT: Mail not routing after Domino restarts beginning December 13, 2024 https://support.hcl-software.com/csm?id=kb_article&sysparm_a...

----

I have the vague memory that it was a distributed reimplementation of PLATO Notes, which had otherwise similar capabilities but was born as a bug tracking system?

It was more of a message board. I mean, I guess you could use a message board as a bug tracking system, but most of the uses I saw were more groups of people planning things... graduation parties, keggers, jam sessions, etc.

Thank you! I don't have any experience with PLATO itself.

A few PLATO stories:

The first time I saw a PLATO terminal was wandering through one of the engineering buildings at UIUC in '78. I was captured by the "friendly orange glow." There were some people there so I snuck in and started talking to them. I was able to convince them to give me an account on the down-low... don't tell anyone about it 'cause I don't want to get kicked off the system. So I would swing by there or the library on off-peak times so I wouldn't be accused of using the system for frivolous things like music while other people were doing SERIOUS work.

It turns out, part of their plan was to give a real account to anyone who wandered by. It was back when we really weren't sure what personal computing was going to look like and they were a university so they experimented with letting high school students, random musicians, liberal arts students, people from town... anyone who asked for an account pretty much got one.

One day I learned the new-ish terminals were run by an 8080 CPU and had some I/O off to the side (I think mostly to run a slide projector.) I mentioned this would be great way to control a network of synthesizers and one of the guys said "Oh! You should talk to Sherwin!" -- they were talking about Sherwin Gooch who made the "Gooch Synthetic Woodwind" that hooked up to the PLATO terminal and made wood-windy sounds. I went looking for him but all I found was a box of parts and a story about how he had left town to go to Florida State.

Several years later I'm at Florida State working for Paul Dirac (this was right before he passed away, so probably '85.) And hey! They have PLATO terminals at Florida State. I was musing about using them to control synthesizers again to people in Tallahassee and one of them says "Hey! You should talk to Sherwin! He made some musical instrument to hook up to the old terminals!" And I went looking for the mythical Sherwin only to discover a box of parts and a story that he had taken a job in Sili Valley.

After a decade of working for Bell Canada, I finally make it out to Sili Valley for a job tuning modular exponentiators for PowerPC devices. This was probably '98. And I go visit a few friends at CCRMA (Stanford's Center for Computer Research in Music and Acoustics.) I was peripherally involved with psycho-acoustic research at Bell Canada, so it's not a complete stretch for me to be there. I'm chatting with a friend I met in Tallahassee, who happened to be working in Palo Alto. I eventually mention PLATO and the Gooch Virtual Woodwind and my friend says "Oh yea! You should talk to Sherwin!" And I'm ready for him to say something like "but he moved to outer mongolia..." but instead he says "and he's sitting right over there."

So after 20 years I finally got to have my conversation with Sherwin about computer music and PLATO. Though honestly, we mostly talked about techniques for solving math problems.

---

Fast forward another 15 years and someone launched cyber1.org, which is an online emulated CDC6700(?) running the PLATO software. Just download the pterm package and you can talk to it. You could, apparently, use your old login id so people could find you on the system again. I couldn't remember by group authenticator so it took a few days to get logged in. But what I didn't realize is they way they got everyone's account info was they restored backup tapes from various PLATO installations.

I logged in and was presented with pnotes files from about 30 years earlier.

Surreal.

And it gets weirder because one day I'm in the Living Computer Museum in Seattle and they have a PLATO terminal on display. You were encouraged to use the DEMO account to look at what old networked systems were like, but just for fun I try my FSU account info and... viola! I'm in my FSU account from 1985 on an actual PLATO terminal downstairs talking to an actual (non-emulated) restored CDC6700 upstairs. Like cyber1, they got people's account info from the same backup tapes.

Obligatory: https://www.dreamingincode.com/

[dead]

I remember, when I was just starting, the founder of the company saying that if you tell him you're offering an 'engine' that's mostly saying you don't have an app. Of course, some successfully sell 'engines', but I think there's a basic truth that you need users to make your business work and make what you're building better and battle-hardened, and to get those users you usually have to be providing just what someone's looking for, and that often means making an app.

Some 'frameworks' or 'engines' budded off from work on a concrete problem, e.g. Django first for a specific CMS, Rails from Basecamp, Unreal Engine from Unreal the game. Work's not as much of an 'engine' as those are, but it's definitely turned out a big focus is on how customers can build their own stuff (both in the frontend and the data side) and integration. But for anyone to care about all that it has to be an app first!

Having a real product is a costly signal (i.e. a genuine one) that the developers are doing enough dogfooding.

I've also noticed this. Seems rare to find successful frameworks that were actually built out as a framework from the start.

See also the rule of three (repetitions before you extract a function, and clients before you extract a library)

Here are two that I worked on for 10 and 5 years, respectively:

https://Qbix.com/platform

https://Intercoin.org/applications

Maybe I was just a crazy socialist LOL

Here is the why:

https://intercoin.org/community.pdf

https://intercoin.org/IntercoinSolutions.pdf

Given that this is the first time I’ve ever heard of either of those, I think the point stands.

You think those are successful?

This was previously phrased in startup advice as "start with a single vertical and generalize afterwards", "don't try to boil the ocean", etc. A lot of less-experienced entrepreneurs start with wanting to conquer all markets with their new paradigm, but the truth is you first need to capture specific segments/verticals or you'll be spread too thin.

Similarly, with a software solution, you need to make it integrate into an existing stack used in the market, or else build the layers to make it something that can fit neatly into a business's processes. E.g. if there's already an established market for engines or frameworks, then a business can use your conforming engine almost plug-and-play. Otherwise you have to build the app and UI layers on top to make it end-user-facing.

Once you've achieved some success in a vertical or layer (e.g. appointment bookings for salons), you can abstract the core solution/framework and start applying it to other verticals or build adapter layers to start attacking other layers (e.g. appointment bookings for everything).

I'd add my own piece of advice: try to avoid violent growth. Slapping an adapter on something is usually a kind of violent growth. An adapter might 100x your pool of potential users overnight, but it can also easily lead to situations where people depend on your product but have expectations that you are completely unaware of, thus blocking you off from the next tier of growth.

While I’m not quite sure what we’re talking about here in terms of platforms, I’ll mention a couple of personal and team server platforms that are subject to the Zombocom Problem and a couple that aren’t. WordPress, NextCloud, and OwnCloud try to be all you need and even though they have plugins they seem subject to the Zombocom problem, because stuff gets shoehorned into a particular app. On the other hand there is https://sandstorm.org/ and Dokku, which let you run an app and just give resources to them, so if you want to run a Trello clone you can just run the Trello clone.

Sandstorm had a clear goal of getting critical mass and changing personal servers forever and I think in many ways it was close.

WordPress is the exact example of the opposite of your point. WP started as the edge of a wedge. But contrary to the examples in TLA, it didn't become an everything platform deliberate and predetermined, but organical and messy.

It started as a "blogging tool" and only that - it still is to some extent in 2024: it still has traces of "blogs" in its DBA, code, templating and so on.

It was successfull exactly because of that focus. As opposed to Joomla! and Drupal and many others that never even made it. WordPress gained a "plugin system" but later than most others and far more limited. In the beginning plugins were really to customize your blog - but it was still very much a blog.

When blogging wasn't that popular anymore - relatively, it pivoted into more of a brochureware CMS by leveraging the plugin system, but core was very much still a blog. I can't recall how many requests I had from customers to "remove this confusing blog-thing, we don't use that don't we". It could not be removed.

Then, after a while, it became the everything CMS. Slowly and rediculously clumsy. It still is. It's far worse at "being a webshop" than almost all dedicated webshop software one can choose instead. It's rediculously inadequate for anything close to "social media" - or user-generated content (due to its depenance on- and design of- the caching, mostly).

So, WP may be some "everything platform" by popularity and common use. But it's both bad at this and never predetermined to be that.

What would you choose instead, in this day and age?

For what?

That's the crucial question. Because the important parameter to "what is best ?" isn't the "day and age", but the exact use-case, and to lesser extent, requirements, existing stacks, team capabilities etc etc.

If you have a company with 58 wordpress instances, then I'm pretty sure the best option for almost any use-case for the 59th instance is "wordpress".

But if you are an artist that makes and sells bracelets from local sea-shells, with little interest in learning technical stuff, you are almost certainly better of with an etsy and/or shopify. If only for the TCO.

And the bakery around the corner who just needs their opening hours and some nice impression in the form of a video, story and some images (brochureware) online, wix, squarespace or one of its many (open source) competitors. Or, if you just need a quick three-page landingpage for your tech startup, in a team of mostly software engineers, a hugo or jekyll site is quite probably by far preferable.

There are so many alternatives that "do one thing and do it well (or better than the generalists without focus)". It's really about having the ability to filter through these instead.

That’s refreshingly sensible advice.

Thanks for that. It’s spot-on.

I don't think WordPress is a good example at all. All sorts of weird stuff gets shoehorned into Excel (see the horrors of any prop trading firm). The point is: Excel is wildly successful, because before it was a platform, it was a solution to an important specific problem. Same with WordPress.

You're falling into the Zombocom trap when your initial value proposition is the same as Zombocom's.

Good point. WordPress is the wildly successful one of the five I mentioned.

It also did this to a certain extent, from the post:

> This customer acts as the edge-of-the-wedge for expanding into adjacent use cases (next best customer is music)

These include various types of content (VideoPress, portfolio plugins, podcasts, custom post types), shopping (WooCommerce), and forums (BuddyPress, bbPress)

However, it isn't quite a general purpose self-hosted app platform. Something limited it from continuing it going into adjacent use cases, and I think part of it is that its plugins still tie into a system that's still oriented towards blog/CMS use cases.

Sandstorm's architecture is incredible, and I love it a lot.

In my opinion though, it did kinda fall into this. It was an extremely secure and well thought out way to run concurrent user web apps. But none of the apps there were better than the proprietary Google suite or equivalent, and for self hosters, the need to explicitly port the app vs the simpler but less secure and less integrated 'just run a docker container' meant it lost there too.

There's also some limitations on what the apps can do, for example, I don't think Sandstorm has a good story for searching and indexing the contents of grains, the way other services could.

I think the killer app idea at the time was hospitals or governments with strict regulations and it didn't land well enough.

They chose apps that had personality. For instance, one of their flagship apps, Rocket.Chat, had a slash command for lenny face. https://docs.rocket.chat/docs/slash-command

This was good, and goes against the Zombocom problem.

However, as you said they didn't address self-hosting as well as they could have. I don't think it was because of other domains, but because they were envisioning people sharing them or paying for a cloud host, and didn't try to emphasize only apps that don't guzzle CPU, memory, or storage. Rocket.Chat is a MongoDB app. GitLab is another one: https://apps.sandstorm.io/app/zx9d3pt0fjh4uqrprjftgpqfwgzp6y...

Similarly on Dokku you wouldn't have apps sharing a database instance. If you had two apps that needed a database, you'd start two postgres instances.

I don't think they ever failed to see the Zombocom problem or attempt to avoid it. Curating apps for security made since. However, it didn't see enough use for them to add lots more apps to their library.

Adding an easter egg command to your chat app is trivial. Actually making it good, stable, usable is not, especially if you prioritize easter eggs.

Slack has /shrug which isn't that far off.

Idk though, I stand by it. Any company that wanted a chat app could get slack or skype or teams instead, and they are backed by a big business who assures they're safe, come with desktop apps that have pop up notifications, and were quicker to boot up, and frankly are better.

And, personality or not, any app that was ported to Sandstorm you can still run off Sandstorm too.

The killer features are one single account for everything (ala Microsoft's suite which also has that), the potential for some very cool interoperability that never quite reached its full potential, and better security, which not enough people/companies were willing to sacrifice other desirable traits for, apparently.

I think NextCloud and OwnCloud are also bad examples, as in the beginning they started with the clear goal to replace Dropbox with a selfhosted alternative. Only later in live they become what they are now, so the original point still stands.

> Platforms have to start here too. Otherwise, they’re DOA.

Completely agree with this. The person who starts building the ultimate meta-framework or meta-API as step 1 is almost inevitably doomed to failure if they can't articulate a specific problem they solve better for their users.

I have taken this approach with personal projects as well. In the past, I divided up the functionality into a bunch of neatly-organized classes at the beginning and then implemented each one in separate files. Big mistake. Much better is to put it all into one, ugly file until the kinks are worked out and then organize it later, at least in my opinion. It’s also much better for working in a flow state so that I don’t have to switch between 8 different tabs.

So even for personal projects, what’s most important is the ugly MVP that does the thing. It’s only after that works that I clean it up.

> Much better is to put it all into one, ugly file until the kinks are worked out and then organize it later

IMO this defer-until-needed approach depends a bit on having better tooling to use whenever the rework happens. Stuff like languages with statically-checkable types, good "Find Usages" IDEs, tests that exercise the overall architecture, etc.

When you can't count on those things, a constant gradual approach is needed to compensate.

It’s funny, I did a lot of python programming early in my career, and I didn’t realize just how afraid I was of refactoring until I started doing embedded work. Even as bad as the weakly typed C type system is, I found the compiler to be a godsend for changing my code later.

From the technical perspective, I see Amazon as a platform first design. They're not shy about it, they embraced it ("we so totally overengineered our infra we now can rent it!"). It's so zombocomey that you can use it to zombocomify your own shit.

We should still call it "overengineering" and not "insight". It was a risk and a compromise.

First they were a bookstore. The infrastructure came later.

You can design something in such a way that the most important and relevant piece of the solution comes later. The order doesn't matter.

Amazon is full of zombocominess. It's not a bad thing. The name itself is very zombo, _it can be anything_.

The book selling is a great MVP for their final goal, a huge wide ass platform. It's all over the company history (what they bought, how the grew).

You can design stuff in all kinds of weird ways. The first iPhone was a zombomachine. It had everything: it was a phone, it was an ipod, it was an internet device, it was a platform...

Platforms are awesome and if you have the resources you should totally build with one in mind.

The zeroth iPhone only played music btw

The first widespread portable music player, the Sony Walkman TPS-L2, was in fact a modified recorder that had a platform for audio that punched above its weight.

I agree, but I also think "how people fail at X" is a biased frame, when X is a risky, high value, naivety prone goal.

"Building a platform" is such an X. A high risk/reward goal where lots of failure is expected.

Programming languages, operating systems, hypertext, www. The earliest versions may have been small and made for a specific need... but the generalization attempts came soon and excitable zombocon words came out of mouth.

So sure... targeting your new programming language to a specific use case is a strong starting strategy. But.. it's a programming language. A platform.

The whole information superhighway was a big zombocon in the 90s. That's why the parody resonated in the first place.

I'm not entirely convinced that general platformish ideas cannot succeed. They're just hard and tend to attract the naive because if the massive potential.

This is dead on.

I think most of us have had the issue with being told to "Write me a Facebook."

I've done exactly what the article talks about, except not for something that makes money. It's a free platform that Serves a fairly neglected demographic.

Starting small is key.

I always say "Success breeds success." I set humble goals, succeed, then raise the bar on the next one.

This is really good for mentoring folks, as well. Get them used to succeeding. It may start with stupidly simple stuff, but, before you know it, they are doing really complex stuff.

For those few who might don’t get the reference, is about the (legendary) site zombo.com

https://en.wikipedia.org/wiki/Zombo.com

The very first element in TFA is a link to zombo.com.

I hadn't heard that term before. When I was in technical sales, we called it the "Tampon Sale" technique, based on an old joke:

Two little boys found a five dollar bill on the street and went to the store to spend it. The first little boy came up to his friend with his arms full of candy. His friend just had a box of tampons. "Why do you want that, instead of candy?" asked the first boy. "Look here" said the second boy. "If we buy this we can go swimming and hiking and horseback riding...."

We were trying to sell an engine and quickly learned that the Tampon Sale fails spectacularly. We had to pivot to vertical solutions.

So but how do we build software that can be anything without falling into the Zombocom trap? I believe that Bezos interview shows us exactly how.

[insert list here]

No offense, I'm from GenX, we were doing those things before Bezos came along in fact that was the norm. See VisiCalc one paragraph up for an example. Attempting to create markets for your product like with the Metaverse or blockchain solutions versus just creating products for an actual market that already exists is a relatively new phenomena in the industry. I don't know why we started doing this to begin with.

> I don't know why we started doing this to begin with.

Because Steve Jobs said:

> People don't know what they want until you show it to them.

and too many people wrongly believe that they are as smart as Steve Jobs.

The article doesn't claim Bezos originated the idea. It just uses his quote to explain his logic. In fact, the article goes on to mention VisiCalc immediately after.

To extrapolate further: trying to be all things to all people didn't originate with any particular generation, or even in the software business. Companies have been trying to please too many customers forever, only to either finally settle on the right demographic or fail.

But the article uses the phrase 'Bezos' approach' as if it's somehow attributed to Bezos or a new concept. For some reason Wall St. and Silicon Valley love learning the simple things the hard way then act like they had some great epiphany when they finally figure it out.

Everyone thinks they’re a genius that can solve every problem and no one wants to sell books better.

More realistically, everyone knows the best you can get with your own little thing is bought out. That is not enough for many smart people’s ego.

>From the inside, it may feel like you’re spending a lot of time on theory. Product thinkers don’t like that. They want to think about the customer.

Oh, finally somebody said it, thanks to heaven! Template "product mindset" with only data-driven way and unshakeable faith in the sacred custdev turn as a curse for interesting products and caused a problem of mass creation stereotypical products an gray, dull, soulless startups with only marketing packaging. But this inside-way is a really like some lost components of the product magic.

This seems very similar to concept of Architecture Astronauts [0].

I am glad author is realizing this is bad! They state their goal is to build a system that is "pliable, re-shapable, open-ended, true to its materials as a universal machine" which is as close to zombocom as it gets.

[0] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

It also describes the blockchain / Web3 / decentralization crowd. Sure, the technology is great, but if all you've built is a Twitter clone, why would anyone care to use it?

> It can be anything, but first it has to be something specific.

Spreadsheets definitely feel more like a platform. They aren't specific to what they started out on - they're very general purpose. The metaphor of "grid of numbers you can do stuff with" is extremely not-product-specific.

Spreadsheets were originally designed to mimic the paper spreadsheets accountants used.

Only with the addition of macro languages did they become do-everything platforms.

This is more or less how I was taught to approach VC investment when I switched from being an operator to an investor.

Understand the environment (market conditions, constraints, fundamental enabling technology, economics, the macro) both now and in the future. The undeniable deep currents.

Look for companies solving a relatively specific, significant, painful problem, particularly one that is a barrier to future success/riches from the developing market it enables/supports. E.g. DWDM telecoms hardware supported the explosion of the Internet. Something you can do some diligence on to figure out the real questions around it.

Once you have a list of companies/founders, look to see if a sub-group is emerging from the gaggle. Focus on those 2-3.

Finally, ask yourself "what is the google on the moon" [1] whiteboard for this company. Meaning, how big can this be, where can this go, what (in those days) could be their 2nd, 3rd, 4th product.

[1] https://www.theregister.com/2006/03/08/you_only_search_twice...

Classic hindsight/survivorship bias for me.

Bezo’s approach is sublime. It holds two seemingly irreconcilable insights in tension and transcends either lesser alternative:

Come on.

How dare they sully the Zombo.com name. Stop trying to make the phrase 'Zombocom problem' happen.

Unfortunately, the rarity of the super product means this tactic is useless.

Step 1. Be born with silver spoon in mouth

I don't know. The reality is just that most business ideas don't pan out. There were hundreds of well-funded efforts to build online retailers before Amazon happened. If you're well-off, it's obviously easier to try and try again, but you're still likely to fail.

I think the article is right in that if you don't have a clear business idea ("we're building a platform"), the odds are even worse. Except when they aren't, because in some niches, you actually have customers who want a platform. Cloud computing is an obvious example. It's just not the general case for consumer stuff.

> There were hundreds of well-funded efforts to build online retailers before Amazon happened

Maybe hundreds. Maybe not. We (the initial amzn team of bezos, myself and shel kaphan) were certainly not looking at any others that I recall besides bookstacks who had a telnet-based online bookstore.

I think people overlook the role of luck here. Bezos was simultaneously very smart but also incredibly lucky to be "the guy who was doing books on the web". It really was the ideal product for the first large scale online retail, and Bezos brought a lot of imagination and energy to the effort. But if it had not have been him, it would have been someone else, who likely would have been more or less as successful.

Personally, I think that Bezos' relentless focus on customer service was the biggest factor in amzn's early success, combined with his near-insane quality standards for the people he was willing to hire.

What was the "lucky" part? The article claims that Bezos learned that web usage was growing 2300% a year (public knowledge), decided to sell stuff on the web, made a list of 20 potential products, and decided that books were the one where an online store could best compete. Is that wrong? It makes it sound like the particular way Bezos was lucky was by happening to be smart, smarter than the rest of us who were paying attention to what was going on. But it sounds like you're saying there was some other form of luck involved. What was it?

What I mean by luck is that I don't think that Bezos (or the rest of us) had any special qualifications or experiences that meant that we were the only ones who could have made amzn work. He was lucky in that his situation at D.E. Shaw allowed him to do the market research that led him to the book store concept (notably after Shaw rejected it). He wasn't smarter than the rest of us. Had Shaw not asked him to research possible online opportunities, he may never have come up with the concept at all. And it wasn't Shaw either, given that he turned down most of the ideas Bezos presented, most of which went on to become pretty huge.

I see! So the luck was in happening to be paying attention to the right things, and happening to bet on them even though other equally smart people (like David Shaw) decided not to, given the same information? Thank you for explaining.

"Luck is when preparation meets opportunity." You need both, and a good dice roll as well.

[dead]

> Except when they aren't, because in some niches, you actually have customers who want a platform. Cloud computing is an obvious example. It's just not the general case for consumer stuff.

I think Cloud computing as a successful business comes from the same process as suggested though. It's hard to build the platform as a business by itself.

Amazon's cloud is an offshoot of their internal elastic computing needs. Google's cloud sort of is too. Microsoft's cloud is an offshoot of their enterprise software business, same with Oracle's. IBM has been renting computers to businesses since like forever, but they used to make calculators and typewriters. I've never understood what Salesforce does, but I dunno, now it does it in the cloud rather than customer hosted?

There's some maybe purer cloud businesses, but mostly they started with a simpler hosting model and expanded into cloudy offerings.

If steam was always meant to be an all the games store, it certainly didn't start that way. When it launched, it was only for buying/using Valve's games, and it expanded later.

After looking at the history of Amazon, I'm convinced their early success was due more to ruthless business practices than being an especially good book store.

Ruthless business practice? Maybe too, but very good customer support from my point as a customer, e.g.

- a shopping cart which kept my choices forever. I remember a startup clone about 20+ years ago here in Europe, whose shopping cart automatically cleared after 24 hours. That was annoying if you wanted to look for some reviews for a book later in, before deciding to buy.

- the suggestions engine "customers who bought this also bought..." was excellent 20 years ago, especially for niche products. It helped me find a lot oft interesting music, once CDs where added to the shop.

- customer comments/reviews on products. And comments on reviews, correcting facts more often than not.

Most of this started to degrade years later. No comments on reviews any more, no downvotes on bad reviews, fake reviews, "sponsored" products "suggested" in extreme, etc.

The thing I always remember was a former colleague bought a TV from Amazon in about 2008. He got an email a few weeks later from Amazon saying that they'd refunded some of his money, as the TV had gone on sale not long after he'd bought it. That is insanely good customer service.

Don't forget one click to pay. Remove all friction from the payment process.

Amazon retail was the first customer for AWS.

Just because success is unlikely, we shouldn't try for it?

There are a lot of ideas that sound good. Far fewer that are good. Being able to tell the difference makes it much more likely that you're on a plausible path to success.

Another way to see the point is to remember that it is better to make something that a few people really want than that a lot of people would like a little bit. An app is more likely to fit that bill than a platform.

There's a lot of useful learning in failing. It just helps if you can afford to fail, or be a startup and fail with other people's money

[flagged]