Since this is an audience of passionate technologists, here's the top piece of advice I have:
Do not be seduced by the technology!
I killed one of my startups this way. I've seen many many die this way.
It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical.
Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
"Be regular and orderly in your life, so that you may be violent and original in your work." Gustave Flaubert
You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
Don't get me wrong though! There's certainly a time and a place to play with all the coolest and trendiest stuff, but if you're optimizing for growing a business, that is the time for choosing low-risk, simple, mature tools.
This is excellent advice. There is a local company near me that has been working on their SaaS for almost 2 years now and still yet to launch. They started it on Angular 1 and are now re-factoring it on Angular 2 (or maybe 4 now). During this time they released a small open source Angular library but not even an alpha release of their own product. Keep in mind their product is not gear towards devs. They also hit every Angular conference they can and are always doing dev meetups. That is fine for after you launch and are making $$ but seems like a lot of wasted time and money when you have yet to release a product after 2 years.
During this same period, I launched 2 SaaS products on boring PHP 7 and Python for the backend and HTML, jQuery/intercooler.js for the front-end. Both profitable and growing.
I think sometimes devs don't realize the hardest parts of starting and growing a business have nothing to do with code or the tech stack you choose. Marketing, getting and retaining customers and everything else in between is way harder than writing code.
Why? Because it doesn't reduce cognitive load. One seems to require at least as much brain space to code things in Angular, as you do just writing pure Javascript. That's a no-no, that means it's not a labor-saver long-term.
From what I understand, the CEO had a previous company that repackaged, setup & sold custom social network software to companies. He made decent money while it was hot and is using that to fund this endeavor. I guess you can't really blame him if he is self funding. I don't feel right about calling them out by name. I hope it works out for them in the long run.
Both SaaS apps. Different markets but one of mine is similar in complexity to theirs. They could have launched a year ago if they were not wasting time re-writing the app in Angular 2 & 4 and spending time open sourcing Angular libraries.
I personally do not want to spend time re-writing my app every 6 months before it is even launched. I would much rather spend the time acquiring customers. I tend to choose a stack at least to start that I know I won't need to re-write in 6 months. Unless of course it needs to be re-written/refactored to accommodate all those customers knocking at my door ;)
That generally means I stay away from the front-end flavor of the week when starting a new app. Don't get me wrong, I myself have used Angular and Vue for a couple of projects but not in the beginning and not for the core product. I don't like the instability and constant changes of a lot of the newer frameworks.
I think the lesson here is use what tools you already know, and are intimately familiar with. There's no reason it takes two years to launch an Angular app, unless you keep updating to use all the latest and greatest features and versions. The same goes for an old workhorse technology like PHP, avoid using the new stuff in favor of proven frameworks and patterns.
Javascript hipster echo chamber: you're not using react [or insert other trendy framework pushed by code schools and tutorial makers]? Product user: does not give a rip about your precious tech stack.
Completely agreed. Here's another way to look at it from an economic perspective:
It's usually best to focus on propping up your differentiation and competitive advantages, going stock with everything else. If you rely on standard components for things that aren't your special sauce, then you get to ride market forces of commoditization which will drive the cost of those standard components towards zero.
Can you build your own backend database in Haskell instead of using Cassandra or PostgreSQL? Yeah, that would probably be really cool and do well on these boards. Then look back at how many hours you spent getting that to just understand simple SQL, and how many customer-facing features that could've been. Is it cooler to build that database than to set up an email auto-mailer? Yes! Special functional algorithms that operate on B-trees are far more exciting than simple state machines that send emails. But the latter is what the customer cares about, so therefore that's what you care about.
One interesting exception to using cutting-edge stuff may be making it easier to hire cutting-edge people.
It doesn't matter how smart you are. The opinion of the market is the only one that matters, and it expresses it in the form of repeat sales.
I want to emphasize this, and expand on it: Your cool tech startup is not about the tech.
You exist to solve a problem.
Sure, you might use your Cool Tech(TM) to solve the problem. But the salient point is that the problem gets solved. Your customers don't give a rats ass if you solve it with automatic hyperparameter selection for LSTMs, or if you solve it with an Excel macro. They just want. Their problem. Solved.
Agreed. It's one thing if the Cool Tech actually gives you a competitive advantage by solving the problem better, easier, with lower costs, faster, more personalized, etc.
Outside of that...it's all about the business. That's why so many successful businesses are built with Ruby and not "benchmark winner of the week" because Ruby tends to deliver on almost all of the business cases around solving problems and growth.
If you're a larger business and planning to deploy at scale to an existing customer base, the business problems tend to change more towards performance and Right Tool for the Job.
I remember when ruby was the hot tech a few years ago, frowned upon by conservative developers. I learnt ruby back then. I'm glad ruby is now recognized as a more mature ecosystem that does things well, even though it is one of the boring technologies now.
Is Ruby/Rails faster now? I built a few simple sites on Rails 2.3 via Passenger, and my God, it was such a performance hog compared to every other web stack I'd ever used. Probably mostly a function of how heavyweight RoR was, but I never got deep enough to figure out what was so slow about it. It may also have been user error, but it seemed like others were bragging about getting it to levels of performance that would be frankly embarrassing on most stacks.
One thing Rails has over, say, Laravel or Django is the JRuby option which has made significant strides in performance in the last 6 months. There's also Truffle Ruby, Graal and Oracle's Substrate VM which all target Ruby performance so my money is on a significant Ruby resurgence later this year by which time Oracle will likely have open-sourced Substrate VM.
Don't get me wrong, I'm a huge Elixir advocate largely because you get the performance and scaling perks of other languages with very close to the development perks of Ruby.
I just get tired of hearing the "but Ruby is slow" drum beats when it's so consistently successful. Scaling web servers is easy. Scaling the database is hard.
Yeah, I was just asking if it had improved. Scaling web servers might be easy, but it adds administrative overhead, and if you don't have big piles of VC money to burn, it bites into budgets that would be better used hiring more people and working on product. And it makes it so you have to waste your time reworking your server structure earlier than you would have to otherwise - suddenly you need a load balancer, a shared session store, etc. When I ran a company, these were very real concerns.
It being successful doesn't excuse its slowness, in my opinion. There are lots of bad products out there that are successful by many metrics. Speed is an important part of making something good, and RoR added significant hurdles to making very fast sites. There are other stacks that don't have that issue that are also successful, but have other downsides.
Anyway, not worth rehashing these old arguments, I just wanted to know if it had improved. Sounds like it has.
There was a time when Ruby was "the cool exotic and unproductive technology". A lot of wheels had to be reinvented (and new ones added) before it became what it is today, there is nothing special about it.
All mature technology will come with a known set of tools and processes to tackle almost any problem very quickly, as long as you're familiar enough with the stack.
One thing that's especially productive about it that helped to grow the 3rd party ecosystem is that the options you have for dependency injection in Ruby due to monkey patching give you an experience much closer to Aspect Oriented Programming.
It also makes it easier when you need to add functionality somewhere high up the inheritance chain without having to rebuild the entire chain around your new object base, or fork the library, use your fork as the dependency and make the change directly.
In the world of object oriented web development, Ruby was close to a miracle in time-reduction in WORKING with an ecosystem.
It really depends on the interaction between the discipline of your team and the failure modes of the tool. A culture of code review which puts a high bar of justification and documentation-for-new-contributors on monkey patching can counteract this failure mode.
Do you code review what each new library does? It doesn't have to be code you wrote to cause problems. And most people treat a library as a black box with inputs and outputs. Which works well in a sane language, but often not ruby.
I would like to add that Excel macros are excellent; If Google Docs spreadsheet functionality were exportable I reckon that many existing startups could be built as a mere UI change on top of that backend.
> You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Unless you are building tools, products, or services for other engineers.
> Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
I'm going to assume that if someone is going into business for themselves then they are planning on having customers. There are ways to show off that don't put your mortgage and credit rating on the line.
> Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
I'm going to assume, this too, is obvious. What I mean is that anyone who has written a fair amount of software has probably already realized this.
What is it that makes people think programmers are a bunch of navel-gazing narcissists that take great pleasure in impressing other programmers? We do, but we're also rather intelligent people.
I say: be seduced by technology. Programming is beautiful. Hard problems are a joy to solve and bring great value to the world. Do what pleases you. Life is short.
The specific business advice I have is: learn to be a leader. Take responsibility for outcomes, give ownership to your team, and learn to guide people. If your business grows and takes off you might find you won't have much time to program everything and will have to act more like a guiding hand and lead your team in the mission and trust them to take you all there.
My other advice is: avoid intuition and gut-instincts. Use data: analyze commit history, watch your issue manager, track performance indicators just as much as sales and marketing. A business is always shifting and changing. Rely on data to help you identify trends and make effective decisions. A gut decision should be a last resort.
> I say: be seduced by technology. Programming is beautiful. Hard problems are a joy to solve and bring great value to the world. Do what pleases you. Life is short.
It's far easier to fall into a hole of technical debt this way. The extra costs incurred could be too much for your venture to bear. Among all risks new ventures take, this is probably has one of the least cost:benefit ratios.
to expand on this, i'll trot out my little adage again: most startups are marketing problems, not technology problems.
marketing encompasses the 4 P's: product, price, promotion and place. product is literally the finding of the fit between your offering and the market's needs. price is the portion of the value you deliver to the customer that you capture. promotion is finding and providing potential customers with info about why your product is the shizzle. place is how you deliver the product to your customer (e.g., physical store, direct sales, saas, app store, etc.).
build things that support your marketing activities, rather than building tech that you hope you can market.
What you're saying sounds reasonable but I think it is completely wrong.
I strongly believe that startups very rarely fail because they have chosen to build on a particular immature technology. Some fail or stall because they cannot bring themselves to stop redesigning and rebuilding on the next new technology or design philosophy every couple of months.
But these are completely different issues (related by psychology for sure but not by necessity)
My opinion is you should choose what you find coolest and most exciting now and then stick with it!
Of course the technology you choose should have some traction but don't choose technologies of the past! Whatever you choose will be the past soon enough and that is when you must find the strength to stick with it and get on with creating value for users.
I don't think his comment says that they failed because they chose the wrong trendy language. They are failing because they are too concerned about the language and the process rather than the result.
While I don't really agree, I do think that if one intends to work on a side project or a bootstrapped company, they need to do it in a way that is somewhat enjoyable for them.
It requires lots of energy to see these projects through, and it's hard to emit that energy on something that you don't enjoy doing. If using a less common technology is going to get you working on the problem enough to start getting some velocity, that may well be a worthwhile tradeoff (as long as it's not too out there).
The other thing to consider is that while a basic library supplied by a young language may suit your needs when you're starting out, larger ecosystems are likely to have more advanced libraries that have better performance characteristics, support more obscure use cases, etc., which will only become more valuable as one grows.
Since hiring for engineers is so competitive, it is arguable that choosing fancy tech can give an advantage there. It has been done successfully (in a hiring sense)... Twitter pushing Scala, Jet.com on F# are two I can think of.
The downside is it could backfire on who you're able to hire. It could just lure people who will either want to migrate to the next new-and-shiny or just leave quickly.
I think one thing a lot of startups think is that they absolutely have to be able to attract the best and brightest. In 90% of cases, average level programmers can build your product just fine. Unless you are building for enormous scale or your product is using cutting edge technology, you simply don't need a bunch of programmers from the top 1% or even top 10%.
In my company, we hire middle of the pack programmers for a bargain and use commonly known tech stacks.
> you simply don't need a bunch of programmers from the top 1% or even top 10%
Having done some recruiting at a startup last year, even getting the top 50% to reply to an email is a tough proposition. The problem really stems from brand awareness. No one has heard of your startup, so in a sea of "help wanted" postings on Angelist, Stack Overflow or Craigslist or cold emails, it's extremely easy to be ignored.
Using novel technology and getting the word out (as Twitter and Jet.com did), can at least get technical awareness within a motivated subset of engineers who are interested in said new stuff -- and of all skill levels.
That said, Peter Norvig made a pretty good refutation of your core point[1]. Say your initial site was successfully launched by average engineers. If you're not always trying to hire better than the average employee at your company, your team just gets worse over time.
I'm sure he's right when you are building a one percenter company. But my team will likely never grow to a size that it will ever take on a life of its own outside my control. 5 engineers tops when we hit market saturation. Each new hire I make is more skilled than the last because I can pay more as time goes on.
I just don't think research done from the perspective of the biggest tech company in the world has any relevance on 99.9% of small tech startups.
Doesn't this say more about the flaws of the business and/or the management than it indicates this being a good idea? Many of the most successful software companies do everything they can to attract and retain the upper end of software engineers and they don't do this because it's bad for businese. Presumably they do this because it provides more value for the company than having more programmers or trying to save money on salaries/perks.
Perhaps, but I actually think getting the best and brightest is more of a factor of having tons of VC money. In that case, you need to move as fast as possible, and every little bit helps. If you are building a niche business with limited TAM, you just don't need the top tier, assuming of course you aren't building something groundbreaking from a tech perspective.
Interesting perspective. Kind of reminds me of the discussion yesterday about programming contests not being the best indicator of software engineering success. Personally I love programming contests, but reading your comment I can see how it's not the most important thing to be in the top 10% in Algorithms.
Your main focus should always be to ship good user tested product, and I agree you don't have to be the best programmer to build something that users want and like.
Wow, love this article. The context of this article is how I ran my consultancy and the developers didn't enjoy my choices to choose the "boring" tech over what new tech they wanted to bring in, in the middle of a project. "Secrets of Consulting" is a great book if you've never read it, too
I'd like to add: if you find the time, try to have a side-project on your own time where you apply all these cool new things you were looking to apply in your company. This will help you keep your sanity and it will let you experiment with that technology so that you can make a better informed decision on wether to implement it in your company or not.
And yet, 99% of founders out there don't care about building a unicorn. It's just a handful in silicon valley doing anything they can to be the next big thing.
Most entrepreneurs are happy building a good product that helps their customers while making a good living at it.
I'll throw in that this doesn't necessarily mean just use Ruby on Rails and get coding.
I mean, that will probably allow you to ship a bare bones MVP pretty quickly, but making improvements to said MVP in a timely manner may be a different story.
Case in point: I used to work for a company that developed a product that was made in RoR and was probably actually pretty nice looking at one point. Unfortunately customers had ideas for what sort of improvements should be made to the MVP, and very few suggestions were turned down. So, after some time, the codebase grew pretty hellish, and it became harder to release substantial improvements in a reasonably timely manner. If I remember correctly shortly before I left they decided to replace it with something built from scratch using a leaner Ruby framework called Sinatra.
For that reason I'll typically write projects in Node or Golang, but typically Node. They're flexible, they're not a framework, they're not opinionated, but at the same time they both still have robust package ecosystems so I don't have to reinvent the wheel.
And actually, by all means use new technology if you can honestly tell yourself and your customers that it allows you to ship faster. Just remember, you writing code faster != you being able to ship faster. You'll probably have to bring on additional employees, so your choice of tech has to factor in how quickly you can hire and train someone to use your tech stack as well as how well they can reasonably perform with it. That being said, developers who like using your uncommon technology or tech stack are typically going to be a little more enthusiastic, just don't go too far.
> Case in point: I used to work for a company that developed a product that was made in RoR and was probably actually pretty nice looking at one point. Unfortunately customers had ideas for what sort of improvements should be made to the MVP, and very few suggestions were turned down. So, after some time, the codebase grew pretty hellish, and it became harder to release substantial improvements in a reasonably timely manner.
This is the problem, not Rails. I've been using Rails for years since 2009 without any problems. I've also used PHP, Java, and Node. These projects have survived 5+ years not because of any language or framework but by treating code as a craft.
Ultimately you're in business to convince customers to pay you money in order to use the thing you built. If the code base goes to hell after making customer-requested improvements to the MVP then that's a problem with the design of the MVP code base combined with a lack of refactoring to improve said design. It could be that management didn't want to spend the time or money to rebuild the codebase to let those new features be added in an organized way; that's a management problem. A very experienced developer/lead could translate from nerd to English and from English to Management so the people in charge could understand why they needed to not get new features for three months while the code gets refurbished. If management still says no, because there's no money or they've got impatient customers then that's a different issue.
The specific part of "code as craft" that you need here is a recognition of the value of what chefs call "mise en place". You need to have your work environment in an orderly state that it enables you to work efficiently.
This is true and I totally adhere to it, but, I also think sometimes it's useful to choose the latest and greatest not for the technical aspect, but to attract good devs to work for you.
I don't know. I think there's room for a high-end niche shop that only deals in functional languages, for example. I see enough data now that 1 line of functional = 4 lines of Java/C/Go for the same amount of work done, to think that perhaps, SOME trendy technologies are actually worth their mettle.
I think the real limitation is not jumping on trends but managing cognitive load. That is your real limitation, the capability of the programmer-mind to fathom all the states their code can get in. To optimize towards that, you have to pick technologies that force the least amount of cognitive load on the developer. Functional languages such as http://elixir-lang.org/ seem to accomplish this (according to those who have switched to it and blogged about it, example http://mattscodecave.com/posts/elixir-for-pythonistas-pt1.ht...). In the javascript space, Elm seems to accomplish this. http://elm-lang.org/
But lastly, if you pick the right technology, you might naturally get access to a pool of very high quality developers, the type who are already interested in that very technology.
I don't get the point of hiring "Java people" and whatnot, anyway. Polyglots are the way to go.
The thing that made Paul Graham a thing was his use of Lisp to edge out his competitors at the time. The fact that Viaweb was later rewritten in [whatever it was rewritten in] is irrelevant. That's my final point.
Totally agree with you. In thread of "Linux is obsolete" Ken mentioned the same thing[0] as "...Most users could probably care less if the
internals of the operating system they use is obsolete..." Although, He is talking about OS, but it is true for other as well.
Technology is actually an advantage. I would look at it this way, if you used N tech, and it actually results in a faster, better app, meaning happier users and therefore more business.
Doesn't really give you an advantage if you don't have customers. Even after you have customers, oftentimes the old/boring technology actually results in a faster, better app.
There are always tradeoffs, though. Using technology X instead of technology Y isn't free; maybe there is an additional up front engineering cost, or maybe it's harder to hire devs who know X, or something else. And it's impossible to generalize, of course, but usually the tradeoffs for using superior tech aren't worth it in the short-/medium-term, which is all that matters as a startup.
I don't think you and he are in disagreement. Obviously you should do what will give your business an advantage. He is just saying that it is easy to think that certain new technologies will give you an advantage, but then realize later that what they cost you in bugs/complexity/maintainability etc. make it not worth it for the business. So it's usually better to go with tech that is tried and tested rather than always reaching for the latest new thing.
All the more reason to stick to tried and tested tech. Engineers like to experiment themselves, not have the foundations they stand on be experimental.
I don't think that really answers the question. If your customers are developers, then you need to bring something new to the table or you won't have any customers. You can't sell them someone else's products...
You're talking about two different things. "Technology" in the phrase "don't be seduced by the technology" means, the tech used to build your product. Not the technology of your product itself. Obviously you should innovate when making your product itself, but the tools used to make the product don't need to be bleeding edge for you to do that.
E.g. if you make a website, it should be a unique and engaging website. But you can make a unique and engaging website with Java. Even though it's old tech, your users will not know or care.
I understand what you're saying and totally agree. However, I was under the impression that the parent poster was talking about the products, not the tools, due to the way that it was phrased regarding "foundations".
Our customers are (I work at https://paw.cloud)
For us we are happy with django for backend since we can trust it, but when we do cool stuff with django we take a few days to right up a blog article that for us is direct marketing.
>Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
It could be anything in the top 20, really [0]. The problem is that devs have an impulse to do something experimental and cool, since they have to work with workhorse languages all day at their day jobs.
The myth that they tell themselves is that $REVOLUTIONARY_FEATURE_Y will greatly improve their productivity, but the fact of the matter is usually that no matter how revolutionary the features, it's hard to overcome the benefits that come from an active ecosystem of well-tested and widely used libraries. Even if productivity is improved 20x by the revolutionary feature, a library that has 10 man-years of effort in it will take you 6 months to implement. Rinse and repeat.
This is not to mention the availability of online references and established conventions/best practices, the impact of hitting esoteric errors, and so on.
A good example of this is probably reddit. Originally written in Lisp, they eventually gave up and compromised down to Python due to improved tooling and library availability. [1]
It's just really hard to beat the reliability, community, ecosystem, and features that are table stakes when using a competent web framework.
When you're poking at a new market, you really don't have time to give a shit about writing CSRF middleware. That's one less customer interview or feature request to grow your business. I'm sure you can do it, and no one's doubting your capability to do so. But these are just things that are tricky to implement and takes everyone time and effort to do so correctly.
I have a couple of criticisms of your article. Firstly, you give a list of successful companies who made the "safe choice" you're advocating, but you fail to mention that at the time the companies adopted those projects they were actually the cool, risky new upstarts. Your first example, Twitter, started in 2006 - a mere 18 or so months after Rails 0.8. If Twitter had followed your advice of using a 13 year old web framework when they started, what would they have been using? ColdFusion? They succeeded by using the productive new technology - which at the time (absolutely not now) was Rails.
And secondly, some of the features you list the frameworks as having are questionable at best. Rails has built-in user accounts, permissions and admin interface? Since when? And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
I think you confused the two messages of "don't build your own web framework" (I heartily agree) with your assertion that a startup in 2017 would be somehow remiss to not be using frameworks developed in the time of Windows XP, with which I do not agree.
For me the current "Rails in 2006" framework is elixir/phoenix, and for the slightly less adventurous, something in nodejs - maybe meteor or plain express. Of course Rails still works, and is not an absolutely horrible choice, but it's for last decade's web, and has profound disadvantages compared to today's technology.
I agree with you completely that these frameworks are old. They don't get features like websockets immediately. From a performance standpoint, they are lacking with respect to compiled languages. Statically-typed choices have come a long way.
However, for new business owners who don't care so much about getting an A+ for technical excellence, I would still stand by this advice. The benefits of technology maturity and ecosystem are extremely compelling.
Today, for someone who just wants to let their users log in with Facebook, Elixir has far fewer user-friendly resources and will require more technical expertise to produce the same result. How many StackOverflow questions address common woes in these popular frameworks as opposed to the up-and-comers? How easy is it to hire someone to build + maintain? What about for hiring on the cheap? What existing libraries and integrations exist?
Of course, these things get better for new technologies over time. Until then, I can't tell people to use them if it incurs a disproportionate cost to achieve the same return.
Lastly, that "it's old" is not a compelling reason to me to recommend something else. GNU/Linux was created in the 90s, and it's still everywhere and growing. There's a job for an operating system to do, and GNU/Linux solves it well enough for the amount of effort required to use it. I believe the same to be true for Django or Rails in building a fast business prototype for most enterprise or consumer use cases. I think measures of suitability for the task are more relevant than age.
Well, I agree with you of course. Re-reading my comment, I overstated my case somewhat. The truth, as always, is somewhere in the middle. I suppose I was reacting to the previous comments as well, asserting that anyone choosing anything other than the boring, tried-and-true mature stacks for any new project whatsoever was being "seduced by technology" and otherwise an irresponsible and non-pragmatic neophilic dilettante who is not a Serious Businessman Like Me.
For the use case you're describing, I agree completely with your comments. Perhaps a useful razor is - if you can't state specifically why you can't use rails (and don't say "it doesn't scale"!) - then use rails. I concede that 90% of the time, this is probably the case.
And yes, harping on about its age was silly of me. Age does not inherently mean anything. I'd use postgres (1984!) over mongodb anyday. And erlang is older than ruby. Right tool for the job is far more important, thanks for pulling me up on that.
All that said - I still think that categorically stating "use boring technology" or "just use rails" for absolutely any new project is harmful. New technologies are not always just about the new shiny, they can provide capabilities and functionality simply unachievable with the old. Look at what you can do with concurrency with phoenix. Look at what you can do with react native. Roundly writing off the whole idea of using this new tech as "magpie development" is just lazy.
> And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
Why? If you're proficient in multiple languages, there's no real upside, especially if each language is easily hireable.
And it's particularly irrelevant if the front-end or back-end is weighted more heavily than the other in terms of product value, when you might hire distinct rather than "full stack" devs someday.
1. Your devs can always go to where the work is - if you divide FE/BE and suddenly you have a feature that needs a lot of BE dev, you can move people from the now-mostly idle FE team rather than try to hire them
2. You can share business logic between FE/BE for client-side functionality. I've seen a surprising amount of bugs that boiled down to "oh we updated code on the back end but forgot it surfaced somewhere in FE code as well and didn't update there"
Of course, YMMV and this probably highly depends on your project, architecture, quality sensitivity, etc etc. But to say sharing FE/BE languages has "no real upside" is a bit... optimistic IMO.
Front-end and back-end almost always use different build/debugging tooling, different unit/integration testing frameworks, and even different paradigms. Unless your developers are good at constantly switching modes, it's hard.
"no real upside" is wrong, as you point out, but I would stand by "no guaranteed upside" :-)
Do not be seduced by the technology!
I killed one of my startups this way. I've seen many many die this way.
It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical.
Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
"Be regular and orderly in your life, so that you may be violent and original in your work." Gustave Flaubert
You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
Don't get me wrong though! There's certainly a time and a place to play with all the coolest and trendiest stuff, but if you're optimizing for growing a business, that is the time for choosing low-risk, simple, mature tools.