
Ask HN: What is the best tech stack to develop a SAAS Service? - AgharaShyam
Hi Guys,<p>I want to know what languages and frameworks should i learn in order to develop a vertical SAAS Service. This includes making an iOS, Android and a Web App.<p>Feature that i want to develop are - 
- Inventory Management
- Dealer Management
- Accounting
- Payroll
- Analytics (Important)
======
shotgungg
I wanna say "There are no best tech stack". It all depends on your use case.

What language are you good at OP?

You can quickly mock up majority of your use case using PHP, ruby or even
Node.

Create a monolithic app and stay away from microservices until you have
clearly drawn service boundaries. I'd say (6 to 12 months) in production. You
dont need the headache of the distributed overhead.

Just keep in mind that you should "write code that can easily be disposded or
replaced, not extensible"

For generating client sdk's i suggest using swagger. Grpc is there but i have
trouble grasping protobuf sharing at the moment

For user clients, i would go for react native.

You're better off using a 3rd party for analytics when you are starting up: if
you have the money, I'd suggest using segment, new relic or even google. Else,
do it with prometheus or kibana.

My 2 cents

~~~
lsiebert
This is good advice, though I'd note that Swagger unfortunately can't match up
exactly JSON api (in the jsonapi.org sense).

------
pacnw
First, do know that the scope you have outlined is a huuuge undertaking. Maybe
think of limiting the scope to start off with (inventory mgmt OR dealer mgmt
OR accounting OR payroll). For tech stack, my suggestion is to use a back-end
that provides as much out of the box as possible.

Ruby on Rails provides huge bang for the buck with their integrated database
ORM, as does Phoenix (what I used). Your scope involves a lot of referential
data, stick to traditional robust SQL database system (Postgres for example).
If you use a NoSQL db, you may be quicker out the gate (as it'll take any JSON
you give it), but once you get to the analytics with lots of joins, it won't
be as much fun (personal experience). Also, I would suggest using the server
frameworks' rendering engine to get your MVP up and running, as you can then
fast iterate between data model changes and visual representation (i.e. HTML
output), and avoid front-end builds and all that encompasses. Phoenix is very
snappy, and with something like Turbolinks can potentially be as snappy as a
dedicated front-end app.

Personally, I needed very interactive front-end, so had to build a separate
front-end using Ember. I found Ember with Ember Data provides a robust toolset
that manages complex data. I also have experience with React and Vue, but keep
in mind with their state management (e.g. Redux / Vuex) that you'll need to
manage complex data relationships yourself. As far as mobile, don't think
native, as you'll need to learn specific technologies to implement that as
well (more time...). Grab a bootstrap template that is already responsive, and
you can run the same web-site on an iPad (forget the phone initially). Good
luck!

source: just finished a 2 year build of an investment-related accounting and
analytics webapp

------
gii2
Generally I would go with .NET Core - it is still in its infant stage, but by
the time you have MVP it will be OK - Microsoft are throwing a lot of efforts
in this direction.

For the mobile apps - Xamarin. You will still write C#, just use a different
way of thinking.

Having the same technology stack in web and mobile will allow you to reuse
skills one day when you build a team.

~~~
jetti
Just FYI, .NET Core is at 1.0 and already has a LTS version. It is definitely
production ready now.

------
AgharaShyam
So what i am planning to build is SAAS service that provides all the feature's
listed above and more, customised for an (unspecified for competitive purpose)
industry. The web client is used for entry of data related to sales, stock,
payroll. I am also making apps for various operator's inside the plant to
upload data using their android phone's and tablets.

Then i want to process and display all this data (related to Manufacturing,
Sales, Marketing etc) on web, iOS and Android.

So essentially there will be apps for employee's working in the plant (for
data entry) as well as for the managers and owners (to monitor everything and
make decisions)

I want the web dashboard to look somewhat similar to -
[https://demo.baremetrics.com](https://demo.baremetrics.com)

And since i have no experience in building mobile apps i want to know what
languages/frameworks would be best suitable to develop good/native looking
apps for iOS and Android using web technologies.

Thanks.

~~~
tobltobs
It sounds a bit like you would put the cart before the horse. You first should
think about your data model, including how to solve user access and permission
logic. Then build an API to access your data and a generic Web Interface to
access the API. And then you can start thinking about which framework you use
for your mobile apps. If all this is done you could add a dashboard.

------
kayman
What language or framework do you know well right now? Use that.

~~~
mintskoal
I can't agree with this more. If you've got an idea and know some
framework/language better than others and that can get you up and running
quickly, use that. Refine later.

------
i336_
Some additional details about the project may be useful to others - you've
described a fairly wide range of scope at a rather abstract level here.

I'm quite confident a number of highly knowledgeable people have looked at
your question but have been unable to answer for lack of context. Narrowing
things down a bit would likely get you more focused answers.

With that said, the best tech stack is the one you already have in your
pocket. You could argue that this is why having a good all-around knowledge of
all of the major stacks is a good idea.

~~~
AgharaShyam
Thanks for the suggestion i336_

So what i am planning to build is SAAS service that provides all the feature's
listed above and more, customised for an (unspecified for competitive purpose)
industry. The web client is used for entry of data related to sales, stock,
payroll. I am also making apps for various operator's inside the plant to
upload data using their android phone's and tablets.

Then i want to process and display all this data (related to Manufacturing,
Sales, Marketing etc) on web, iOS and Android.

So essentially there will be apps for employee's working in the plant(for data
entry) as well as for the managers and owners(to monitor everything and make
decisions)

I want the web dashboard to look somewhat similar to -
[https://demo.baremetrics.com](https://demo.baremetrics.com)

And since i have no experience in building mobile apps i want to know what
languages/frameworks would be best suitable to develop good/native looking
apps for iOS and Android using web technologies.

Thanks.

~~~
i336_
After carefully considering what you've said, my first question is what
development experience you _do_ have. On the one hand the "finished product"
overview you've provided could simply be for conciseness, or it could be lack
of experience. (My point is that I have no idea.)

On the surface you're describing something that's been done many many times
(kinda obvious). On the one hand this means you could find someone to work
with to help you on this fairly easily, on the other hand you're looking at 5
figures easily... which is likely why you're trying to figure this out
yourself, now I think about it :)

I'm hesitant to suggest looking at existing off-the-shelf solutions; I get the
impression that finding systems that haven't rusted together in the areas you
need flexibility is touch-and-go and hard to figure out in advance. It may go
incredibly well, or you may end up maintaining a massive headache that's
incredibly hard to fit-out for your needs. One possible idea that may work to
some extent is finding open-source projects that implement some or all of the
functionality you want; they may be useful for parts/ideas or real-world
answers to "how did they solve this bit," or even better you may find they
actually work for you (yay free stuff!).

While you may come up with extra defining/deciding context/requirements, the
main decision point I'm thinking of is whether you consider it a must (or a
huge-value add) for things to be partially functional if there's no consistent
network connection. This applies to sales/management (on a train, or at
exactly the right vortex point between a bunch of buildings, and cellular just
dropped out?) as well as plant operators (hypothetical contrived example: a
non-essential machine just went bezerk and is spouting so much RF the Wi-Fi
just died). That said, generally supporting transient network loss is... hard;
you need a database design that, at every point in read/write, can tolerate
"another client may have committed an update but that data might not be in the
query we just did yet," which the application design must be built with
awareness of (it's so fundamental it can't be abstracted).

If "the plant Wi-Fi just died" disrupting operations is okay (for example, you
have somone on-site who can rapidly diagnose a wide range of issues, you have
spare APs and related kit available, etc), then you'll save yourself a lot of
time by just developing this as a webapp. Others may argue for native apps,
but if you do a webapp, you can target desktop (Win/macOS/Linux(?)) + mobile
(Android/iOS) just by using media queries. Suddenly several thousand lines of
Swift and Java disappear :)

With enterprise setups like this, you also get to call the shots on what you
contractually agree to support Android/iOS-wise; you get to specify the
minimum versions, and you can also check the user agent and throw warnings or
blocking error messages for versions you don't like. This isn't a public Web
site, so you don't have to work for everybody. And so you get to guarantee
that certain Web APIs are available :)

In all fairness there _is_ the AppCache and ServiceWorkers+IndexedDB can cache
web apps for offline use, but I wouldn't rely on them because the storage
areas they use can be cleared.

Now I think about it, you _could_ build minimal Android/iOS shells that load
your HTML/CSS/JS into a WebView with some simple caching tacked on to
guarantee code availability in offline situations. That could work quite
nicely, and the native codebase would be tiny. With this Wi-Fi dying isn't a
problem but now you need to go back to mentally modelling eventually-
consistent database schemas.

On the backend side, what sort of traffic volume do you intend to handle? Do
you intend to have the backend be on-site? (You could do a managed on-site
setup where you have (monitored) SSH by contract but the system runs on client
servers.) This would distribute processing load across the sites. If you want
to centralize everything then you need to think about how many clients you
want - then double or triple that figure (and then maybe multiply it by
itself) - and you should have a good idea of the sort of volume you need to be
able to process. There's a reason all the "how we process 1.21 jigabytes of
messages _every second_ " posts on here are so popular! You may need to look
into high-throughput, easily-shardable datastores.

Regarding those graphs... well... note that you're looking at the revenue the
guy who built those graphs is getting! :D I can see there's a fair bit of
intelligence in the graph displays, and fine-tuning a similar system with a
quarter of the functionality is something that would take a bit. Certainly
possible, but it would take a bit.

Unfortunately I have very little advice to offer in the area of actual Web
development; I haven't explored the scene much yet. I know that there are a
dizzying number of developer offerings available. Your best bet is to forge
ahead trying them and see which one you like.

I'm not a developer myself (in that I don't have a software engineering
position - nor the mindset for one, just yet); I just spend all my time on HN
:)

I wonder how much more specific you could be (for the benefit of everyone)
without giving anything away.

By the way, thanks for mentioning the Baremetrics demo - that's really cool
that they're open like that.

~~~
AgharaShyam
Thanks for a very detailed answer. I appreciate it.

You are totally right in that i don't have any real web/application
development. In fact i just started university but i have been programming for
a few years (mostly problems on sites like code chef in C, C++ no products)
but recently got this idea when i visited a plant that my father owns. There
are about 600 such plants in the same area and they use fairly old software or
not at all. So i talked to him about my idea and he thinks it will be very
useful and also commercially successful since there is virtually no
competition. That's why i decided to learn web development. But now i am
realising it's tougher than it looks. I asked this question in order to get an
idea what all the things i need to learn in order to even attempt to build
something like this. Now that i look at my question i think i should have
asked "How to be a full stack web developer?". So if anyone is still reading i
think this would be the question that you should answer or maybe i should have
just googled it and started working

~~~
saluki
Nice that you have a connection to get your foot in the door at your Dad's
plant. Customer #1.

The path I would recommend to learn full stack development.

Go through the books Head First HTML and CSS (get an inexpensive hosting
account you can FTP files to and setup some domains, point to your hosting),
next go through Head First PHP and mySQL. Next is Headfirst Javascript then
Headfirst jQuery.

After those you should sign up for teamtreehouse.com.

You could play around with developing this in PHP without a framework, setting
up a login in system you would learn a lot. Sometimes frameworks are tough to
understand what all the magic is happening behind the scenes if you haven't
creating a simple app with login, etc in vanilla PHP on your own. For your
customer version though you will want to use a framework, more secure, better
organized code, etc.

I would recommend developing this with Laravel(PHP) it has a great community
so you'll be able to find great learning resources to get started. (Rails is
good too, but I think Laravel will be easier to get started/deploy your app)

Also I recommend developing on a mac. Windows always seems to have obscure
issues that you will waste hours/days on.

laracasts.com will get you started with Laravel.

There are great deployment tools forge and envoyer. Hosting on Digital Ocean
is perfect for most apps, AWS and linode too)

Use stripe for billing.

There is a SaaS add-on to the framework call Spark. It's ok but, I find I'd
rather roll my own stripe/SaaS integration.

Also Spark does use Vue.js though so since you're just learning I would stick
with developing the app using jquery for ajax interactions and think about
moving up to vue in the future.

I would create the MVP as a web application for all the interactions. Then
once you have that established you can look at adding true android and iOS
apps. Those might be better to hire out the development of. Or a future
learning project.

You should be able to set everything up as a mobile web application, use the
bootstrap framework for the look and feel of your app. There are some ready
made admin templates that can get you something similar to baremetrics.

Having your Dad's plant as an initial user for your app will be great to
refine what they need get their feedback.

Good luck. Follow up and let us know how it's going.

------
hcarvalhoalves
I would suggest Clojure to reuse code across the backend, web (ClojureScript)
and mobile (w/ React native). That can help with time to market.

------
siquick
Language should be the one you know best, and if you're aiming to launch both
web and mobile apps then make sure you build with an API-first mindset to make
your life so much easier.

------
fantasyui-com
Heart and Love, or Ghosts in the Machine.

You learn what is evolving, and you grab onto it, and evolve right with it.
This is easy territory for flame wars and "whatever fits you"/"there is no
best stack", but that's not the full picture.

Your survival depends on what you know, life is full of surprises, death in
family, cancers, car accidents, addiction, breakups, and depression.

Imagine a warrior, ask him, "what is the best weapon?" and can you really
imagine him saying "There is no best weapon", no, s/he would never say that.

You go on the most popular code hosting website, you sort by number of stars
and begin at the top.

To give you a specific answer "iOS, Android and a Web App" in context of
"Inventory Management - Dealer Management - Accounting - Payroll - Analytics"
is Apache Cordova, (iOS, Android, and others), you use npm/node this way you
will have one code base, you won't have to write the same code in multiple
languages (just imagine scaling a live data sync requirement in one app and
then standard REST in another -- keep it all in one language, or you will
fail.)

"Inventory Management - Dealer Management - Accounting - Payroll" is all
pretty simple (but, please explore ideas like
[http://vorpal.js.org/](http://vorpal.js.org/) just to develop your API before
getting to G-UI, finish your programs in the terminal first.

Don't pretend programs are written GUI first, they are not. GUI is a leaky
abstraction to say the least.) Don't fall for redux, relax and use
[https://github.com/mobxjs/mobx](https://github.com/mobxjs/mobx) for actual
GUI, (by the time you get to this part
[https://vuejs.org/](https://vuejs.org/) will rule)

And for your Analytics front-end D3, it is a departure from standard
JavaScript but it has a lot of love inside.

Finally, remember develop commands/API first, get your apps working in the CLI
and you will finish your program before starting it. Think about using the
power of Unix
([https://www.npmjs.com/package/commander](https://www.npmjs.com/package/commander)),
for the love of all that is mighty think about IRC, NOBODY! has time to learn
to use your apps/GUI and NOBODY! ever needed to learn how to use Siri, so
create a Command Line Interface version of your program and before you jump to
React/Vue meditate over [https://hubot.github.com/](https://hubot.github.com/)
and programs like Siri.

Finally, if I was facing your requirements, I would build a wiki/forum where
your users would interact with bots. Over time I'd rip put some of the robotic
guts and boldly go where humanity needs to be headed, I'd replace them with
what I call Artificial-Artificial Intelligence, networks of Human Mechanical
Turks where anybody could participate.

Neural networks are easy to train, but they are also easy to trick. Nothing
will beat a random sample of Humans from across the world reaching a consensus
on a tough decision.

In closing, People, Real Hearts, Human Minds, powering your network would
share in your profits, and you'd do your part in battling what ails us all,
World's Poverty.

If a mother in Rwanda and a Boy in India participating in your Mechanical Turk
can find their way out of poverty, by helping your to detect fraud in your
circuit. Then, you did your part, to help Humanity grow.

[https://www.youtube.com/watch?v=XGK84Poeynk](https://www.youtube.com/watch?v=XGK84Poeynk)
<3

------
dsacco
There is no "best" tech stack. In fact, this is one of the least important
questions you should be asking when starting a software company. In rare cases
your choice of tech stack will have a meaningful impact on your business
outcome. For example, Whatsapp probably did benefit quite a lot from deploying
Erlang. I would argue that if you have to ask this question, it's the wrong
question to focus on.

In almost all cases, the tech stack is essentially meaningless. This runs
counter to what we frequently want to believe as engineers because there
certainly _are_ meaningful _technical_ differences between languages and
frameworks. These differences just don't generally translate to meaningful
business results.

For example, I am aware of a SaaS company with fewer than five employees total
that generates over $3M in revenue annually. The profit margins are mouth
watering - total non-payroll expenses are high five figures/low six figures
each year. Everything is developed with PHP and MySQL - it would be vilified
here, but it's more successful than virtually all the SaaS companies mentioned
on HN.

I cannot tell you how many YC companies I have worked with that use Python,
Ruby, JavaScript, Go, etc. At this point when I'm on a scoping call with a
founder, I can roughly map out when the company was founded +/\- a year simply
by listening to their technology choices. I have not seen any meaningful
difference in whether or not the company ultimately went on to great success
based on the tech stack. Instead, I have seen companies go on to great success
based on proper identification of real pain points, product-market fit,
marketing and ability to execute well while wearing many hats. (But do keep in
mind that this is anecdata and subject to usual biases of statistical rigor,
or lack thereof).

My advice to you is this: develop your software in whatever language allows
you to think _more about business decisions_ and _less about technical
decisions._ Your aim should be to build fast, iterate fast and fail fast. Many
engineers who start companies struggle with this because technical decisions
are their comfort zone, but your company will succeed or fail based on how
well you identify market opportunities and figure out what your users want. If
you just happen to be most comfortable in an "academic" language or a really
trendy one, go ahead and use it. However, if you're most comfortable in
Python, but you fetishize functional programming or React + Node.js because of
the Medium posts that pop up on HN, go with Python.

Practically speaking for you specifically - I would first revisit whether or
not you actually need a web app and _two_ mobile apps. Could you get away with
a minimal web application and choosing only one mobile application to start?
Maybe develop in iOS _or_ Android first, observe how your potential customers
use the app, address grievances and product a mobile app for the other
platform in the next iteration.

As for the actual technical choices - if you know several ways of developing
iOS/Android/web applications, go with what is most familiar to you unless you
have clear and incontrovertible evidence that one technical choice is clearly
superior. If you have to learn a new tech stack to develop one of these, then
1) don't focus on it now, focus on market validation and 2) choose tech stack
with the best combination of stability and ease of use to get up to speed with
that platform.

Good luck!

~~~
jksmith
This.... This is about business, getting to market, making money. It's not
about programmers' pet interests - those days are long gone. That's why it's
important to pick a toolchain that's 1) easy to code, 2) easy to test, and 3)
easy to hire for with a reliable expectation of skill level. Unless you're
plugged into a small team of very advanced programmers, and this small team is
all you'll ever need, you won't be using something like Haskell. Likewise, if
you choose a MSFT toolchain, and are hiring blind, you're likely to do a lot
of interviewing, because the market is flooded with programmers with this
background who claim to be seniors but really aren't, and you can end up with
a messy project with lots of tech debt very quickly if you're not careful. One
toolchain I've used that does meet those three criteria I mentioned above,
therefore letting you get shit done that is closer to being on time, in
budget, and correct, is of course golang.

One more point: It's important to understand what parts of your app are
capitalizable, and which parts are aren't. The really capitalizable parts are
the ones you think bring real competitive value to the market you want to
attack - the code that addresses your valuable SME and original ideas. So
something to ponder: if you want to also develop a presentation layer, how
valuable is it really to develop that layer internally when in the long run
that work is not much of an asset, and is a time hole for development? No
matter how skilled your team is with the latest js framework I can guarantee
you that there's some team of kids out there who are much better with the same
framework and can develop your UI at half the price. So create your mockups,
define your inputs and outputs, and farm that shit out. Unload the UI headache
while in startup mode.

