11 ms·

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

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.

Kenji 9y ago
>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. When I read this, a voice in my head yelled PHP.
- horsecaptin 9y ago
  These days Ruby on Rails is fairly orderly as well.
  - wyc 9y ago
    Wrote about this here in an article titled Just Build it in Django or Rails: https://www.wyc.io/posts/just-build-it-in-django-or-rails/ https://www.wyc.io/posts/just-build-it-in-django-or-rails/ 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.
    - sho 9y ago
      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.
      - wyc 9y ago
        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.
  - krystiangw 9y ago
    I would use NodeJS for MVP. I think it is super important that you can have backend + frontend in the same technology.
    - scott_karana 9y ago
      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.
      - overdrivetg 9y ago
        Two big reasons are: 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.
        scott_karana 9y ago
        Point 2 is a good call. Hadn't thought of that. In practice, Point 1 isn't too realistic though: 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" :-)
    - vinceguidry 9y ago
      Use Hyperloop. http://ruby-hyperloop.io/ http://ruby-hyperloop.io/
  - tomc1985 9y ago
    I have to agree. Rails is so much more productive now that the cowboys are gone... they're all writing node.js now snicker
- cookiecaper 9y ago
  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] [0] https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ [1] https://redditblog.com/2005/12/05/on-lisp/ https://redditblog.com/2005/12/05/on-lisp/
wyc 9y ago
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.
westoque 9y ago
I disagree. 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. TLDR; use technology that gives you an advantage.
- 20years 9y ago
  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.
- RussianCow 9y ago
  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.
  - inetknght 9y ago
    I think "opportunity cost" is the phrase for which you're looking.
- wavemode 9y ago
  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.
- tomc1985 9y ago
  > and it actually results Big if there...
- 9y ago
taneq 9y ago
> Do not be seduced by the technology! 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.
- brightball 9y ago
  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.
  - toyg 9y ago
    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.
    - brightball 9y ago
      > there is nothing special about it. 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.
20years 9y ago
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.
- wiradikusuma 9y ago
  May I know what you built and they're building? Maybe different product easier with different tech stack? I use Scala because Google App Engine didn't support PHP for example. It's an Android app, so I use Kotlin for that.
  - 20years 9y ago
    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.
yks 9y ago
what if the customers are engineers?
- sudhirj 9y ago
  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.
  - TimJYoung 9y ago
    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...
    - wavemode 9y ago
      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.
      - TimJYoung 9y ago
        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".
- hishnash 9y ago
  Our customers are (I work at https://paw.cloud 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.
gabeh 9y ago
I love this advice. Here is a blog post that I keep coming back to regarding this. http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology
- cgrusden 9y ago
  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
Kalium 9y ago
A wise engineer once told me: be not guided by the beauty of your weapons. They are tools, fit to serve a purpose.
josebama 9y ago
Couldn't have been said better. 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.
- inetknght 9y ago
  This, absolutely. And if you're not willing to spend your free time learning, then you're probably not really tuned in to be a business man either. Yeah you can make a good business. Yeah you can make a living. But you're probably not going to make a unicorn.
  - jjeaff 9y ago
    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.
trimbo 9y ago
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.
- jjeaff 9y ago
  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. The customers will not know the difference.
  - johnsonjo 9y ago
    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.
  - trimbo 9y ago
    > 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. [1] - https://research.googleblog.com/2006/03/hiring-lake-wobegon-strategy.html https://research.googleblog.com/2006/03/hiring-lake-wobegon-... [edit] -- btw, using the new-shiny stuff is not all-or-none. You can still use tried and true tech along the way.
jasimq 9y ago
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.
- johnsonjo 9y ago
  Reminds me of an article by Paul Graham written in 2004 about Python developers. http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
Bjorkbat 9y ago
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.
- fny 9y ago
  > 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.
  - afarrell 9y ago
clairity 9y ago
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.
fauigerzigerk 9y ago
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.
- jjeaff 9y ago
  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.
- cookiecaper 9y ago
  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.
deleted 9y ago
[deleted]
bbcbasic 9y ago
C# and Java: looking at you!
agentultra 9y ago
> 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.
- naasking 9y ago
  > 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.
chauhankiran 9y ago
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. [0]. https://groups.google.com/d/msg/comp.os.minix/wlhw16QWltI/P6X-qODKsjQJ https://groups.google.com/d/msg/comp.os.minix/wlhw16QWltI/P6...
pmarreck 9y ago
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/ 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.html http://mattscodecave.com/posts/elixir-for-pythonistas-pt1.ht...). In the javascript space, Elm seems to accomplish this. http://elm-lang.org/ 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.
mindhash 9y ago
Second this...do the boring work that no one else is willing to do..

Kenji 9y ago

>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. When I read this, a voice in my head yelled PHP.

horsecaptin 9y ago
These days Ruby on Rails is fairly orderly as well.
- wyc 9y ago
  Wrote about this here in an article titled Just Build it in Django or Rails: https://www.wyc.io/posts/just-build-it-in-django-or-rails/ https://www.wyc.io/posts/just-build-it-in-django-or-rails/ 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.
  - sho 9y ago
    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.
    - wyc 9y ago
      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.
- krystiangw 9y ago
  I would use NodeJS for MVP. I think it is super important that you can have backend + frontend in the same technology.
  - scott_karana 9y ago
    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.
    - overdrivetg 9y ago
      Two big reasons are: 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.
      - scott_karana 9y ago
        Point 2 is a good call. Hadn't thought of that. In practice, Point 1 isn't too realistic though: 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" :-)
  - vinceguidry 9y ago
    Use Hyperloop. http://ruby-hyperloop.io/ http://ruby-hyperloop.io/
- tomc1985 9y ago
  I have to agree. Rails is so much more productive now that the cowboys are gone... they're all writing node.js now snicker
cookiecaper 9y ago
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] [0] https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ [1] https://redditblog.com/2005/12/05/on-lisp/ https://redditblog.com/2005/12/05/on-lisp/

wyc 9y ago

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.

westoque 9y ago

I disagree. 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. TLDR; use technology that gives you an advantage.

20years 9y ago
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.
RussianCow 9y ago
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.
- inetknght 9y ago
  I think "opportunity cost" is the phrase for which you're looking.
wavemode 9y ago
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.
tomc1985 9y ago
> and it actually results Big if there...
9y ago

taneq 9y ago

> Do not be seduced by the technology! 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.

brightball 9y ago
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.
- toyg 9y ago
  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.
  - brightball 9y ago
    > there is nothing special about it. 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.

20years 9y ago

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.

wiradikusuma 9y ago
May I know what you built and they're building? Maybe different product easier with different tech stack? I use Scala because Google App Engine didn't support PHP for example. It's an Android app, so I use Kotlin for that.
- 20years 9y ago
  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.

yks 9y ago

what if the customers are engineers?

sudhirj 9y ago
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.
- TimJYoung 9y ago
  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...
  - wavemode 9y ago
    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.
    - TimJYoung 9y ago
      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".
hishnash 9y ago
Our customers are (I work at https://paw.cloud 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.

gabeh 9y ago

I love this advice. Here is a blog post that I keep coming back to regarding this. http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology

cgrusden 9y ago
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

Kalium 9y ago

A wise engineer once told me: be not guided by the beauty of your weapons. They are tools, fit to serve a purpose.

josebama 9y ago

Couldn't have been said better. 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.

inetknght 9y ago
This, absolutely. And if you're not willing to spend your free time learning, then you're probably not really tuned in to be a business man either. Yeah you can make a good business. Yeah you can make a living. But you're probably not going to make a unicorn.
- jjeaff 9y ago
  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.

trimbo 9y ago

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.

jjeaff 9y ago
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. The customers will not know the difference.
- johnsonjo 9y ago
  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.
- trimbo 9y ago
  > 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. [1] - https://research.googleblog.com/2006/03/hiring-lake-wobegon-strategy.html https://research.googleblog.com/2006/03/hiring-lake-wobegon-... [edit] -- btw, using the new-shiny stuff is not all-or-none. You can still use tried and true tech along the way.

jasimq 9y ago

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.

johnsonjo 9y ago
Reminds me of an article by Paul Graham written in 2004 about Python developers. http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html

Bjorkbat 9y ago

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.

fny 9y ago
> 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.
- afarrell 9y ago

clairity 9y ago

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.

fauigerzigerk 9y ago

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.

jjeaff 9y ago
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.
cookiecaper 9y ago
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.

deleted 9y ago

[deleted]

bbcbasic 9y ago

C# and Java: looking at you!

agentultra 9y ago

> 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.

naasking 9y ago
> 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.

chauhankiran 9y ago

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. [0]. https://groups.google.com/d/msg/comp.os.minix/wlhw16QWltI/P6X-qODKsjQJ https://groups.google.com/d/msg/comp.os.minix/wlhw16QWltI/P6...

pmarreck 9y ago

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/ 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.html http://mattscodecave.com/posts/elixir-for-pythonistas-pt1.ht...). In the javascript space, Elm seems to accomplish this. http://elm-lang.org/ 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.

mindhash 9y ago

Second this...do the boring work that no one else is willing to do..