
Ask HN: Launching a new SaaS product, what stack and why? - jaynate
Wondering what the HN community thinks would be the ideal platform to launch a B2B SaaS sales platform. No right or wrong answers, interested in the discussion, pros, cons of various stacks, architectures and cloud providers.
======
mindcrime
The right stack is the one you already know. If you don't have such a stack
already, the right one is probably the one that it's easiest to recruit/hire
people for.

Like @slap_shot says, get something shipped. You should be so lucky as to be
successful enough to have to worry about scalability. If you get to that
point, you'll probably have enough money to hire enough developers to rewrite
it anyway.

That said, here's my personal choice (what we use at Fogbeam):

Web application / server-side: Grails

Web application / client-side: mostly plain old HTML/CSS and some jQuery.

Backend services: mostly Java, running as services deployed as OSGi bundles in
ServiceMix. JAX-RS using CXFRS for RESTful services, gRPC for RPC. JMS with
ActiveMQ for async messaging. Camel for message routing.

Cloud providers: AWS (EC2, S3, Route 53) for deployment of customer facing
applications. Linode for internal apps and basic infrastructure.

Databases: Mostly Postgresql.

Operating systems: Linux, mostly CentOS.

Build tools: Maven

------
fredastaire
My favorite: \- Procedural PHP / static calls \- Lightweight NoSQL DBAL (I use
MongoDB under the hood but any key/value store would do) \- Vanilla JS on the
Client \- Plain CSS witout preprocessors

Since I do a lot of JS on the client I am quite happy not to have it on the
server as well - also I dont like that npm madness / complex infrastructure
around it.

Where do you tend to?

------
slap_shot
Use the stack with which you are most familiar with and get the product
shipped.

~~~
ejcx
This. This. This. This. This.

You are way more likely to never ship and get stuck learning tons of tiny
things that don't matter. Ship, and ship with technical debt shamelessly.

