
Ask HN: If you were CTO of a new start-up, what would your stack be? - acron0
Just an exercise in curiosity. Nothing high-scale, website is your product, ~10,000 users.
======
seivan
Rails, building a versioned API. Try to keep it incredibly light weight with
just VERBS applied to resources. Trying to avoid that word that starts with R
and ends with ESTful.

I might use RBX or JRuby depending on what kind of and the amount background
processing. Basically if I need native threads.

For things that might be heavy and require both speed and massive concurrency
I might switch that out to either Go or Erlang.

In fact, for some portion of the APIs I suspect not to use ruby and instead
Go/Erland. Depends basically on the situation.

I will probably stick to SQL, PostgreSQL to be precise. For heavy
relationships, I'd use Redis for associations. Keeping Model IDS in sets or
orderedSets. That way I could just keep my SQL light weight and only need
indexing the ids and avoid that whole mess of compound index.

Memcache with Rack-Cache.. I'd suspect I'd rely heavily on HTTP Cache. That
way I don't need to cache data objects, and have to redo the json all over
again. Basically tring to avoid layers of caches, when I could just do it at
the user end point. Of course I understand edge cases will turn up. So I'll be
prepared for that.

Then the client(s). iOS, just because I'm pretty certain whatever we offer, we
can offer it better on the mobile platform as a native, also I can code OBJ-C
& design for iPhone.

Web, I'm probably not going to be doing the web-frontend much so I leave it to
whoever I deem fit for the web. Whoever this person is, hen will be in charge
of both the design as well as the code base for the web front-end. Meaning
whatever stack hen choses to work with.

Preferably Bourbon.io with SASS/SCSS and either Ember.js or Batman.js.

~~~
bpicolo
Verbs and resources ARE REST. By definition.

~~~
seivan
:) I was just being facetious.

~~~
atomical
For the whole response or just that part?

~~~
seivan
Just that part. I feel like people abuse the acronym too much.

I had a company call their api RESTful., it was XML being served in JSON
through SOAP.

------
songzme
If I'm looking at ~10,000 users, I will go with Ruby on Rails (ROR) because I
have a few years of ROR experience and I can get things done faster. ROR
handles many things for you (like security) and there are many gems out there
to help you get things done that otherwise would have been complicated (devise
for generating users database). When you are done, push it up on heroku and
you will have a solid product.

If your site is very real time (chat, real-time data), I'd look into meteor.
They are a framework built on top of NodeJS and its built from the ground up
to be real time. Like ROR, they do many wonders for you app (security) and has
built in user authentication system.

If you are looking to build the site for a learning experience and want to
learn how the web works and build everything from the ground up, go with
NodeJS. Install packages yourself, tinker around with security, etc. Its a
great exercise.

------
msaspence
Your stack should be whatever will allow you to test your assumptions the
quickest.

For a lot of cases this will be whatever you are most familiar with. There
will be some cases where a piece of tech you haven't used before simply offers
enough benefits to make it worth climbing the learning curve. However you want
to use the best tool for the job, for startups the job isn't to build an
amazing, scalable and maintainable code base, or even a great product. It's to
find a "repeatable and scalable business model" before you run out of money.

This means speed is of the essence, choose what ever technology you can launch
your MVP and test your assumptions with in the shortest possible time. At the
same time balancing medium term scalability and maintainability concerns.

------
memracom
Scala with Akka, and RabbitMQ for scaling across multiple servers. This would
be a bit more work up front than a web framework like Django but it would be
more maintainable in the long run due to the fact that Akka encourages writing
simple loosely coupled code that does one thing (Single Responsibility
Principle). Even more important is to get the dev team working using TDD (Test
First Development) and provide a proper vision to guide them. Things like
Uncle Bob's Clean Code book, and the raw, original Agile manifesto before it
got sucked into the Scrum and XP methodology machine. Even though the code is
more functional than object-oriented, the SOLID principles still mostly apply.

Some alternate choices that could be OK if you can find at least one good
developer to lead the team, are Clojure, or Erlang/Elixir. With the Erlang
virtual machine, RabbitMQ would not be necessary, although I like it because
it gives you a lot of points where you can measure/monitor the internals of
your application. I would also seriously look at adding Apache Camel to the
mix even though Akka does not require Camel to integrate actors. But Camel is
a thin layer that makes it easier to reconfigure integration points.

------
masterj
There is no way to answer this question without knowing more about what that
product is.

If that product can be well-served with a customized wordpress template (or
similar off-the-shelf CMS), that's probably what you should do.

If that website requires process tons of data in real-time, that pushes you to
a different stack.

If that website requires storing and processing tons of data, but processing
can be batched, different stack.

If that site is an interactive game, different stack.

Do you need to stream data? video? process large uploads? Should it work
offline? Should it work on multiple devices that are offline at the same time
and sync up later? Is it mainly mobile? Is it a big enterprise-y application?
Mainly consumed by teenagers on mobile phones? Serving a population in rural
Brazil / India / Bangladesh?

You could go on like this for quite some time.

I certainly have my preferences, like any dev, but the needs of the project
are going to dictate what's needed.

~~~
codemonkeymike
No one like a non answer even though it is the right answer. That being said
it is true that many will waste countless hours when a CMS is perfectly viable
and could significantly reduce headache.

------
notduncansmith
Sinatra for the API, Redis & PostgreSQL for data, Ember & SCSS on the front-
end.

Redis should be able to handle the most common data for 10k users, with PG for
the less commonly requested data.

No particular reason for choosing Ember other than I like it better than
Angular/Knockout/Backbone, and same for SCSS as opposed to LESS/Stylus.

I feel like Node would be overkill in this scenario, Sinatra is so much faster
to develop with (for me personally, I'm sure there are plenty of Noders out
there who could swing it with their eyes closed).

PostgreSQL + Redis + Ember + SCSS + Sinatra; I call it "The PRESS Stack"

------
xauronx
Honestly? For a large project probably PHP/jQuery/Bootstrap, iOS, MySQL on
AWS.

For something smaller and quick I'd try to use Parse.

------
hardwaresofton
Front-end: Angular sounds like an awesome thing to bandwagon on to, but I've
personally had more exprience with jQuery+KnockoutJS, and that's worked fine
for me. But I hear that Angular has way better structure, once you get over
the learning curve

Middle: I really like Flask -- essentially django lite, and very very quick to
get to writing real code, plugins are pretty good also. BUT, if you want to
handle websockets and stuff, you need to get something like tornado/gevent/etc
involved... I liked the quickness with which I could work with websockets with
NodeJS, but callback hell is no fun. Revel (Go) might be good, if you want to
reap some speed benefits.

Database: I would suggest Postgres. Solid as a rock, has new features (9.3 is
pretty spiffy). If you're going the non-relational route, I really like
RethinkDB -- fantastic management console, really modern functionality
(dumping is super easy, etc).

------
playing_colours
Based on your requirement I would think about 2 options for backend (REST
service):

1\. if I am a single backend developer for some period of time or have 1-2
people around I would go with what I am most familiar with and what can suit:
in my case it is Scala, Playframework, MongoDb or Postgres.

2\. If I start with a team to hire and work on the whole stack I would start
with something that is both rather hot/new to attract smart developers and
keep them motivated and stable, with good stable choice of libraries to focus
on the product not fixing issues in half-baked libraries. I believe Node.js
MEAN stack or Rails would be my choice.

For front-end I would go with Javascript/Angular.js

------
ishbits
I'm old, but just starting the design phase of a new app for my company.

Frontend will be angular and bootstrap as it's working really well for other
projects.

On the backend java, spring and jetty will be used. Netty will also be in
there as we have non http networking needs as well.

PostgreSQL is our standby database, but we're also evaluating Cassandra and
rethinkdb for our non-relational needs.

Why Java? We have in house java knowledge and deployment is much easier than
Python, ruby and node.

------
7Figures2Commas
Nobody proposing very specific technologies here seems to be taking into
consideration the cost of the resources who have competence with those
technologies, and how easily these resources can be located and recruited.

A good CTO will _always_ look at non-technical considerations of this nature
because, in most cases, your ability to deliver is not just about the
technologies you select.

------
xackpot
We recently had this exercise at our mobile start up when we were deciding on
stack. Like any other start-up we wanted to be nimble and fast, so we decided
to use ready products with our start up. We chose Parse BaaS for our data,
Dotcloud PaaS (PHP, CSS, HTML) for hosting. So the only major things that we
needed to worry about involved HTML, Javascript, PHP, Objective-C.

------
soundoflight
.NET and Node with Azure/Azure Mobile Services and progressively enhanced
Backbone on the front-end of the website.

------
dandrews
Anything Cognitect - just because I've never met a Relevancer I didn't like.

------
meerita
If I have to start a new project, the initial code and MVP would be rails,
just to show off, but since I've been dealing with Erlang, I must say that
baby is too sexy to say no. It would be between Earlang or either Go...

------
twog
Honestly, whatever the best tools for the job are.

My preference? Rails, Ember, Mongo, Haml/Sass

------
Fishrock123
Front-End: I'm used to jQuery + Jade, but possibly something fancier like
angular/ember, or even meteor.

Middle: Node.js + Express (unless using meteor). If not node, then Sinatra.

Database: MongoDB, Redis if necessary.

------
groundCode
Angular for the front end work. Backend API built out in either Python with a
minimal framework like flask or perhaps Go if I had the luxury of time to
learn as I built it. Postgres for the DB.

------
zerolinesofcode
roostrap. A java and Spring based framework that runs beautifully on AppEngine
along with Twitter Bootstrap 3 for the UI.

Ticks the following with ease.

[x] UI [x] API/Code generation [x] Scalability [x] Libraries and support [x]
Free to host MVP

Project:
[http://bhagyas.github.io/roostrap](http://bhagyas.github.io/roostrap)
Sample/Demo : [http://roostrap.appspot.com/](http://roostrap.appspot.com/)

------
ericthegoodking
Front-end: Angular, as it is great. Back-end: Rails, its what im familiar
with. Db: postgresql Bootstrap 3.0 -This is a great and well designed library.
sass

------
sejje
Rails or Django on Heroku, most likely.

The frameworks (try to) help you keep from botching things so bad it's painful
later, and heroku just because I hate server config.

------
agibsonccc
Scala/Play for any heavy lifting. Node for the web layer and Angular/SASS for
the front end with grunt to handle node and front end builds.

------
larrykubin
We used plain old Python/Flask with raw SQL, PostgreSQL, and HTML/JS/CSS on
our webapp and I would do it again.

------
brianbarker
Go, MongoDB, AngularJS.

Go for being modern, fast and fun. MongoDB or similar for its scalability and
being quite good for modern applications. Plus I'm just tired of SQL DBs.

AngularJS for a rich client experience, plus I look at REST servers as serving
any type of client and the thick web client is but one such potential user of
the service. Expanding to mobile or god-knows-what is easier.

I have more details about architecture I'd prefer and could write a lot on
that, but don't want to.

~~~
rpedela
Pick MongoDB only if you know it well or it exactly fits your use case.
Otherwise just use a relational DB since it will suffice, more flexible, more
scalable, and higher performance.

------
captainbenises
Rails, devise, postgres, heroku, scss, backbone.js or angular.js. Stripe,
Google Analytics, Xero, Dashing.

------
joeldidit
AngularJS, SCSS, Python or PHP, Memcache, SQL database (MongoDB where needed).

------
nyddle
Flask, Mongo, Redis, Heroku

------
mattwritescode
Django, Nginx, mysql

