ceslami

You make a good point - luck plays some a role. That said, where I think we got lucky was finding a good "community fit" (Step 1 from the article). It was up to us to execute well on the rest :)

In terms of audience size, I would expect smaller audiences to yield smaller results. Despite that, I think the message of the post is that building an authentic relationship with a community means you can grow alongside them over time. This means continuous feedback, new ideas, etc. All stuff that's useful to us as technologists and entrepreneurs!

Good eye, thanks! Fixed.

> Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure.

This is a pithy encapsulation of something I've been thinking a lot about recently: bud off a microservice from your transactional core if it is higher leverage to do so. Any good readings you've found on this perspective?

An example that comes to mind is: I might write my core application in Ruby on Rails, but need to perform a specialized, CPU-intensive function (PDF generation). I can delegate that to a microservice, invert a CPU-bound problem into an I/O bound one (from the perspective of the Rails core), and get the job done with less hardware.

Tell your story!

You're not wrong, but you can use that technique and benefit from Dependency CI too.

Typically, you can define your dependencies in a file specific to a certain package manager. NPM uses `package.json`, RubyGems uses `Gemfile`, etc.

It is a reasonable practice to "vendor in" your dependencies, as you suggest. But given the declaration of your dependencies in some manifest file, Dependency CI can give you valuable insights.

For the sake of discovering a middle ground between our arguments, let's look at an example of a >$1B company running Rails: Github.

Most of Github's stack is Ruby on Rails, with specialized components/sub-systems written in C. This is a common theme amongst companies that use Rails or Python at scale.

There's a reason why people keep those languages around. Its the same reason why they tend to be used for MVPs: the tool gets out of your way so you can focus on solving the hard problems of your domain. The longer you can preserve those ergonomics, the better.

> if you get far enough and need to scale

Alright -- I'll bite.

Rarely anyone "needs to scale." Plenty of $1B businesses can succeed on a fistful of c4.large's running Ruby on Rails. The same Ruby on Rails that ran their MVP. Scaling via language change isn't the path to victory, unless you picked a language that was poorly suited to your domain to begin with.

Too many companies end up following this cargo-cult advice, and spend more time grappling with their tools than innovating. Because "concurrency." Someday.

Optimizing your choice of language for anything other than a linear relationship between Real Complexity and Implementation Time is a fool's errand and a fiduciary travesty.

In all fairness, Elixir/Phoenix could become as well-learned as Ruby on Rails. We'll end up in a best-of-both-worlds scenario. And at that point, I'll happily eat my words.

But in the meantime, solve your "scaling" problems by measuring and optimizing, instead of re-writing your app in the flavor-of-the-week.

Pretty much the same as in any other language. When you want to guarantee that there will only ever be one instance of an object.

It is a useful pattern for managing data synchronization (ie, if I only ever have one instance of a User, I know another instance won't mess up its state accidentally.)

Your economics are unique compared to typical SASS, for example. The LTV of a Youtube channel subscriber is basically $0.