
Ask HN: If you were to build a CRM today what would your stack be? - SnowingXIV
In terms of learning new things, trusting that it&#x27;s secure production ready, and bootstrapping when possible. React seems interesting, but it requires a lot more additional components as you only seem to get the view. I&#x27;ve used RoR before but for something like this performance could be an issue. The good thing with rails though it has basically everything needed with plenty of scaffolding. Angular is a monster and that at least would give the entire MVC but seems to be on the decline and is not a friendly framework.<p>I&#x27;ve had other posts where I&#x27;m trying to find a good CRM, and have come to the conclusion that some will get me close but ideally building a bespoke version would give me full control and be able to add whatever features I want without arbitrary limits. Additionally, since it&#x27;s a larger undertaking compared to previous projects a lot of experience could come from it.
======
tyre
Hi! We're building a CRM for local governments
([https://romuluscrm.com](https://romuluscrm.com)), in 2016, so I can tell you
what we do.

Front end: We use Ember because of its balanced focus on progress and
stability. The team behind it is solid and batteries are included.

Application: Ruby/Rails, Elixir/Phoenix. Rails is great for getting up and
running quickly, and your problems with #scale won't be on the application
later. Elixir (really Erlang's BEAM) is great at quickly spinning up/down
lightweight processes that handle raw data. So if you want to build a CRM and,
say, manage emails, then it could be a good fit. Or if you want to process a
1,000,000 row CSV import, etc.

Database: Postgres. Binary JSON columns give you flexibility, plus PostGIS for
all of your geospatial needs. Structure as much as possible to take advantage
of the smart people who have spent countless hours building a world class
database. You'll appreciate their focus on correctness.

My overarching advice: push everything as far down the stack as possible. If
you can do it in Postgres, do so. Data correctness is your life; better that
your DB throws a fit than your application serving bogus data.

Happy to answer any specific questions!

(And I wouldn't be a YC CEO if I didn't take the opportunity to mention that
we're hiring! [http://seneca.systems/careers](http://seneca.systems/careers))

~~~
moflome
+1 For Postgres with Binary JSON, when that feature was added a few years ago
it completed changed the value prop in how we respond to customer requests
(them: "can you please add two extra fields for fax numbers?" us: "who needs
two fax numbers?")

@Tyre: we use React on the front end but have struggled with meeting
customer's UI expectations for Master/Detail displays of tabular data... the
mobile UI design paradigms on this are so rich, are there any best practices
for web UI?

Thanks!

~~~
tyre
Our first hire on the product side was a UX/Product designer specifically for
this reason. CRMs are incredibly complex and making it easy to use is a real
challenge.

What expectations are you having trouble with?

As for mobile, I wouldn't try to have it do everything that the desktop
version does. It's just not possible, at least not well, with that size screen
and type of input.

~~~
moflome
The point I was trying to make about mobile is that "master/detail" patterns
are well established and the UX clear (cf. Android & iOS default address book
apps); this is not the case on the web. Each of SFDC, SugarCRM, Insightly (and
presumably Romulus) uses a different pattern. And if you look at front-end
frameworks for guidance (Bootstrap, Foundation, cx_codaxy [0]) most don't do
more that provide data tables with in-line edit; rather tedious for CRM with
several dozen fields. We try to use UX analysis tools and interview users
(Inspectlet, UserTesting) but we still sense a lot of frustration &
confusion...

Sorry, this is heading off topic for the OP, but interesting to note the
priority of your first hire -- smart choice!

[0] [http://cx.codaxy.com](http://cx.codaxy.com)

------
maxxxxx
The stack is probably the least of your problems. A CRM usually needs to be
highly customization so picking an architecture that allows for customization
while still being maintainable sounds like the real problem. You can get this
right or mess it up with most stacks.

~~~
odonnellryan
Oh? Why do CRMs need customization? In what ways, do you think?

~~~
arethuza
The sales and customer services parts of organisations are often pretty fluid
- lots of requests to add new fields to collect new bits of data and there is
often a _lot_ of pressure to get these changes done yesterday.

Applications like Salesforce and MS Dynamics CRM are pretty much platforms for
building applications as much as CRM applications - indeed in both cases you
can license them in ways where you get the flexibility of the platform without
access to the standard CRM entities.

~~~
odonnellryan
Interesting! I wonder if there is a market for kind-of a simple CRM: but then
I suppose you'd be selling the method, not the software.

~~~
maxxxxx
I have worked in this space for a while and the typical users of CRMs won't
accept a standard method. If you come up with a method that works for all
companies you can go into sales training, write a book and become rich beyond
your imagination :-). Skip the writing software part because that will be
easy.

~~~
kapauldo
Do you mind sharing where you work and would you be free for a phone call to
give me some advice on a product?

------
od14
I'm just starting a CMS project, which is going to be my first big project.
I've done a lot of research, read a lot of material on almost every framework
possible, I wanted to make sure I would do the right choice both for my self
(ease of use, enjoyable to work with, productive), and the buisness (long term
maintainability is the most important thing).

I've gone over Angular 2, React, Vue.js, Ember, Polymer, and so many more. The
one I really connected with is Vue. While I realize it's only been gaining
popularity in recent months, there are some big companies who start to make
use of it in big scale production sites (Alibaba, Laraval, ...), this makes me
pretty confident that support will not be an issue.

For the db I would definitely choose Postgres, but I would go for plain old
relational tables, and maybe use its JSON features for data which is isolated
and does not relate to other data (e.g.saving spreadsheets data).

For the server I would choose NodeJS + Express + SequelizeJS, and I will
probably make use of some GraphQL library up ahead too. But honestly, if you
choose to make your system a SPA, then your server will not do much of the
heavy lifting anyways - it will probably expose an API point and be used as an
interface to the database, so I think any back-end stack would fit in. I would
also consider Python + Flask + SQLAlchemy, which used to be my stack of choice
few years back.

~~~
terminalcommand
I recently (for the last 3-4 months) attempted to code a CMS as a side
project. I've chosen Python+Flask+SQL and vanilla JS, but have considered
using Node and Go at various times of my coding.

The biggest disappointment I had by not using Node is that I couldn't easily
integrate all the beautiful javascript libraries by just loading a module from
npm.

For example, I'm using Quilljs for text entry, and I have to write something
that parses Quill's JSON output and turns it into a renderable html/markdown.
If I had used Node, there is already a module for it :).

If I started from scratch, I would have designed the back-end first without
using any library. (I would define my objects User, Post etc. and hid the SQL
as methods (e.g create, update, delete) under the hood) That way, I could
debug the app, add new features without having the need to setup a web server.
I could also write sound unit tests. I seriously regret not having done that.

The problem with my CMS was, that it was easy at the beginning. My customers
asked new features and I just hacked them in. Now, my code is still legible,
but since I've used wrong abstractions, it's a pain to add new features.

Your mileage may vary, I was inexperienced with FLASK and SQL at the time I
started the CMS. I've learned a lot during the making and wanted to share my
two cents.

------
d1ffuz0r
I'd recommend you to watch this talk
[https://www.infoq.com/presentations/SalesForce-Multi-
Tenant-...](https://www.infoq.com/presentations/SalesForce-Multi-Tenant-
Architecture-Craig-Weissman)

I've been dealing with different CRMs recently (SFDC, Netsuite, MS Dynamics,
AgileCRM) and I don't think tools really matter, architecture that will allow
you to customize everything is the key for CRM

As my personal choice it would be (I'm a full-time Python dev)

* Java/C# (there's nothing really dynamic in crm, entities, fields, etc with different "name" and "display_name" for each customer, IDE would allow me to manage complexity)

* PostgreSQL (no NoSQL, CRM is all about relations)

* Vue.js

* ElasticSearch (with Kafka for replication from db)

* RabbitMQ for offline jobs

------
traviswingo
I always go with the stack that I'm most comfortable with, unless I'm using an
existing stack at a company I'm working for. Learning a new stack because it's
"popular" is a recipe for disaster if you're incorporating into a product you
want to use or want to charge others to use. You'll spend time trying to
figure out how to do things that you already know how to do in another stack.

Any stack will get the job done. Use the one that yields you a shippable
product in the end.

My stack is ExpressJS, AngularJS, PostgreSQL, NGINX, DigitalOcean, Route53,
PM2. And I fly through it.

------
danso
Given that major companies have been built on what was not seen as cutting-
edge stacks at the time of conception -- Facebook on PHP, Github on Rails --
maybe Rails could still be the sensible choice? RoR might itself not be fast,
but on the upside, its community seems to be pretty forward-facing in building
plugins for client-side tech, i.e react-rails [0]

[0] [https://github.com/reactjs/react-rails](https://github.com/reactjs/react-
rails)

~~~
lucaspiller
Although they may not have been cutting edge, they were pretty hot: Facebook
was started in 2004, when PHP won the TIOBE 'Programming Language of the Year'
award, and GitHub in 2008, two years after Ruby won it (although I'd say 2010
was the most popular year for Ruby on Rails).

(This year it looks like it'll go to Java though, so :P)

[http://www.tiobe.com/tiobe-index/](http://www.tiobe.com/tiobe-index/)

------
throwaway2016a
Whatever one gets you to market the fastest with the features you need. Which
is usually "what your team is most comfortable with"

For our team that would be Node.js with a React frontend, with probably
MongoDB as the database, but every team is different.

As a side note: APIs are very important for CRMs, but as long as you design
your API well you can swap out, move around, and refactor your backend as it
makes sense.

~~~
wmichelin
Can you share your rationale for choosing MongoDB?

~~~
throwaway2016a
Being a NoSQL database I think it would lend itself well to a CRM if you look
at each lead as a document.

Performance wise it has always treated me well. It also provides a lot of
power over updating partial documents (push this item to a sub array, remove
this item from another subarray, at this item but only if it doesn't exist,
etc)

~~~
lotyrin
Agents to Cases to Leads to Contacts to Sales to Organizations seems super
relational to me. Maybe you'd want some extra-schematic info in the form of a
serialized column on each table, but that's about as far as I think you'd want
to go.

~~~
throwaway2016a
:delayed response:

Both of those are usually "belongs to" relationships. That kind of
relationship is easy to model in NoSQL. Many to many becomes difficult but in
those scenarios I'd recommend either a relational or a graph database (also
NoSQL) like Neo4j or Orient.

------
bdcravens
Why does it need a client-side framework? There's a class of apps where that
makes sense, but it feels like more and more that's becoming a default at the
expense of complexity and time to market.

~~~
grandalf
For some kinds of state management, client side is way easier to reason about
and the abstractions one ends up with make a lot more sense. CRM is likely in
this category.

~~~
jamesmccann
Can you please elaborate on how a CRM is likely to be in a category where it
would benefit from state heavy client-side?

A CRM is typically a form based app doing CRUD - to be this makes it a solid
candidate for being a stateless client.

I feel like there's a whole class of applications out there now (including my
own) that have gone down the stateful client route where it wasn't necessary
and introduce a whole new set of problems and solution libraries / frameworks
that can be forgotten about with a return to a stateless arch.

~~~
urlwolf
I would love to know the answer to this too.

~~~
grandalf
Apologies for my brief and unsupported assertion. My take is as follows,
surely many people would disagree.

For building a prototype CRM system, a server side CRUD-oriented system is
going to be the fastest. You could probably build an impressive prototype in
Rails (or similar) pretty quickly.

But as the system starts to scale, you'll end up having to extract performance
improvements either by optimizing the "within request" performance (caching,
etc.) or by creating a hybrid system that uses some client side code to do
lightweight updates to a server-rendered page. This is where complexity creep
comes in and where may projects start to die and become unmaintainable.

I think many application building decisions are optimized around the early win
of easy crud or easy data grids. Even in an app that is full of these things,
it does not always make sense to choose the easiest solution.

Instead, figure out how often data changes. If most data changes rarely, as in
a CRM system, data can be relatively lazily cached on the client.

Obviously a lot depends on what CRM app you are building, who is using it, how
long you expect them to use it, whether it's going to be used on mobile or
slow clients, etc.

------
patrickgordon
I'm building a personal CRM to help me manage my personal relationships
([https://simplerm.co](https://simplerm.co))

Stack is two separately hosted apps.

Frontend: react, redux, webpack as a single page app Backend: Rails for an API

Why? I wanted to learn react and redux and I like using Rails for my backend
and was comfortable with that.

------
merb
We used Scala, AngularJS and PostgreSQL. Actually except AngularJS we are
really really happy. Everything is fast and the development speed is
ridicoulus, especially calculations and performing operations on big lists are
extremly good in Scala. Actually we are probably introducing Redis (actually
we use Akka-Cluster for PubSub) however we think that with Redis we can even
be faster and Cache our stuff better.

For our JavaScript stack we will also look into ScalaJS and/or Vue.JS, React
and Ember, but at the end we probably handroll our own at this stage, since
our feature set is really different from what these provide (we don't need any
mobile stuff, really...), at the moment we have zero mobile clients and we
looking to build an app for a small inventory service, but thats all.

~~~
ziffusion
What problems did you run into with Angular?

~~~
merb
no problems, but actually we started using angular pre 1.0 and a lot of things
are just messy right now, we have lots of different ways how to define a
controller and the upgrade path is extremly bad for us also since we are
coming from Scala we feel the pain of the lacking type system (typescript
would of course resolve that, however we don't want to hook ourself again in
the claws of google, we gone trough GWT to Angular already).

------
sachinag
If you want to be super successful, you build it on Salesforce. Full stop. Two
- two! - different vertical CRMs (ServiceMax and Veeva) have BILLION dollar
valuations built entirely on the SFDC stack.

It'll answer all technical questions, make it easier to hire, and make it
easier to fundraise. Oh! And easier to get customers.

Then think about how people get info into your system - if its email, use
Nylas (it's gonna be email to start). If it's voice, use Twilio. If it's
directly, then abstract all the complexity and use the right terms for your
market.

I don't work for Salesforce, I never have in the past, and I barely use it
now. But choosing anything else is nuts.

~~~
busterarm
We've basically done this and in most ways it's certainly true, but it's also
incredibly inflexible and slow to develop. Apex and Salesforce's platform
limitations are a nightmare. Nearly everyone contracting in this space
delivers a shitty end-product and it's difficult to hire full-time developers
to do Salesforce because they all want to contract (it's so lucrative!). You
will sink a lot of cost into training developers on the platform and then risk
them leaving you to do contracting.

And if you run a 24/7 business or for any reason can't shut down your CRM for
8+ hours ever, god help you if you ever need to do something to modify
millions of records like ETL. I have about 2 weeks of concurrent sleepless
nights I can blame entirely on Salesforce.

Also, I hope you have deep pockets.

------
jwatte
The question is: Solving what problems, at what scale?

If you're a profitable company with a sizeable userbase, just buy Salesforce.
It's clunky, it's expensive, but you can find contractors really easily to
make it do whatever it is you want. Or you can learn the Salesforce platform
yourself and build your final CRM on top of that. Welcome to enterprise IT!

If you're a scrappy start-up, or non-profit, with a small number of people to
serve, you can use whatever you're most comfortable with. A single database
(perhaps with hot replica,) a single application server (perhaps with load
balancing for good measure) and you have everything you need. Use whatever you
already know. PHP and Bootstrap? Ruby and Rails? Node and Angular? Doesn't
matter.

If I were in the middle area -- successful company, lots of customers, but not
actually at the point where I need the Salesforce behind-covering and easy
contractor access -- then I would probably use React for the front-end GUI,
and Haskell with Warp for the back-end services, hosted on top of MySQL or
Postgres, with Redis for data caching, plus some scripts to make creating
bread-and-butter tables/indices/queries simpler and less repetitive. Like the
poster above, I kind of like having an "escape column" for "annottation data"
stored in JSON, although it can simply be a plain TEXT. As long as you don't
need indexing, it makes adding new columns easy even if you have a table
that's too big to change online.

------
jasonwatkinspdx
Given that the bread and butter of CRM is lots and lots of CRUD ui, often
showing the same data organized different ways, I'd immediately do a spike on
using relay/graphql along with your team's preferred backend technologies. I
haven't built an application this way yet so I'd love feedback from anyone who
has. My assumption is that investing the effort in getting graphql going would
pay dividends.

------
k__
I'm building a front-end stack at the moment as a private project.

The main parts are:

\- type safety, in the hope that it speeds up development. TypeScript 2 is my
main contender here.

\- on demand module loading, so I can shrink the initial page loads, will go
with Webpack 2, because it lets me use System.import() and automatically
splits these imports into it's own files

\- interaction flow control completely based on observables, because they
compose nicely and with genertic types ease development quite a bit. Will go
for Cycle.js (+xstream), because it's rather tiny and really everything there
is an observable, data and UI, also it's written in TypeScript. Feels a bit
like Angular2-lite.

\- WebComponents based UI-widgets, because I think they should be independent
from the rest of the application, don't know yet if I'd go for Skate.js or
Polymer, maybe I'd even use custom components directly. But I like the Skate
API much more than Polymer or the "native" API.

\- data retrieval will be based on GraphQL with the hope that it will lower
data-on-the-wire if the client has more control on that. I also hope that the
GraphQL subscriptions (based on WebSockets) will integrate nicely with the
observables. Apollo-Client is my fav here, it's framework independent and
written in TypeScript, too. I'll probably use their GraphQL-server, too.

Every part is pretty much independent of each other (besides everything being
written in TypeScript, haha) so I think I can use parts of it in future
projects.

Server side rendering would be a nice to have, because it would enable the
basic app functions on clients without JavaScript.

------
ohgh1ieD
> I've used RoR before but for something like this performance could be an
> issue.

We should speak about numbers, Rails would handle any normal app without
problems. I'm not a huge Rails fan but I know that its image is broken and
everyone claims that's it's slow just because someone who really needed
performance ( Twitter, Github etc.. ) said so.

We really should differ between 'normal apps' and huge apps.

So basically, Rails is totally fine for your project.

> Angular is a monster and that at least would give the entire MVC but seems
> to be on the decline and is not a friendly framework.

We are talking about angular1 ? If so, I don't think it's declining, I
actually believe that lots of established companies would not start a project
with angular2, simply because it just got released.

Angular1 is fine, I know quite a few people who started their projects 1-2
months ago using angular1, the only difference is now, that they try to keep
it modular, for example they stay close to the recommended way of doing
things, which makes upgrading to angular2 easier, they refer to the John Papa
guide[0].

Because you asked which stack we would use:

I'd use the Play! Framework or Spring Boot, since there is more CRUD I'd
probably use Spring boot, VueJs because I would not create a SPA but would
extend functionality with some lightweight frontend framework, angular1 is too
big, Vue seems right.

Postgresql, because Postgresql.

[0] [https://github.com/johnpapa/angular-
styleguide](https://github.com/johnpapa/angular-styleguide)

------
geebee
This is a big question on everyone's mind right now. "What stack should I use"
is always a big question, but sometimes web development goes through a
particularly notable state of uncertainty.

Although there are a lot of different tech stacks, I think that most of this
boils down to SPA vs integrated views with some javascript. In the rails
world, this generally means either Rails plus jQuery, unobtrusive javascript,
coffee script, and so forth, vs rails-api and Ember (or another javascript
front-end).

Right now, I lean more toward the integrated views than most of my fellow
developers. Very few people would take an always/never position on single page
apps, so this generally boils down more to how far people want to take them.
Some are more eager to apply them in a wider range of scenarios than others.

I personally lean toward the integrated view approach, and I advice caution
around SPAs - in my opinion, very much an opinion here, I think they add a lot
of complexity compared to the integrated approach, and are still in a state of
flux. If what you are writing really is mainly a set of forms that you'd like
to enhance a bit with automatic page refreshes, drop downs, drag and drop
elements, autofill and so forth, you may want to stick with a more stable
stack that isn't evolving as rapidly as SPA javascript frameworks.

There are situations where you can find yourself in a real mess with an
integrated view, that would be far easier to manage with Ember or another
javascript framework, keeping your backend logic in a relatively simple API.
Not sure if that's going to happen in a CRM - they tend to be pretty form-ish
apps, but perhaps that's because up to now, difficulties with javascript have
led us to think of them that way. The rapid evolution of JS frameworks may,
for all I know, have opened up an opportunity for serious innovation here.

One other thing - remember that it is relatively easy to expose a rails method
as an API even in the absence of rails-api. My guess is that this is true of
most integrated frameworks that provide a view tier. You won't be locked into
an integrated app provided you keep logic out of those views! You should be
doing that anyway. Also, make sure your tests don't rely exclusively on the
views to verify logic that isn't in the view (again, you shouldn't be doing
this, but I've seen it a-plenty). That'll keep you flexible enough to
transition away should you want to at a later date.

Good luck!

------
kyriakos
For a CRM the database is probably more important than the programming
language / framework.

------
cweagans
Depends on whether or not it will be a SaaS or self-hosted. If it's the
former, stack doesn't matter. Just use whatever you're most productive in. If
it's the latter, I'd go for something very easy to deploy. PHP, despite it's
shortcomings (speaking as a long-time PHP developer here), is very very easy
to deploy and PHP7 really doesn't suck. RoR is also a reasonably good choice,
as a lot of shared hosts run it with Passenger (or whatever the tech is), so
end users can just upload the files and not mess with server config or
anything.

------
jamesmp98
It seems your looking for something A) Simple but powerful, B) scalable This
is all my opinion, but I would take a chance to try out Vue.Js on the
frontend. If you want to learn something a little different, Elm looks cool
too.

On the backend, ASP.Net core is looking good to me. Although, Go and Elixir
are picking up fast. Heck, ignore the haters and use Node if you want.

Finally, don't be scared to use something "old" like Java (EE or Spring) or
even Rails (personally, I believe the whole performance fiasco is not as bad
as you would think)

~~~
onion2k
Why would a CMS need to scale? At most you'll probably have a few tens of
admin users logged in concurrently, and a few million people viewing pages
that could be baked in to static HTML assets if scaling is a priority. An AWS
micro instance and an S3 bucket would handle that.

~~~
jamesmp98
First off, we are discussing a CRM not a CMS and secondly, he said no to Rails
for perf reasons.

------
neeleshs
If you want a specific CRM solution for your company, anything that your are
comfortable with is fine. If you want to make it a platform, and a generic CRM
solution that other companies can use, you need to think about APIs, security,
customizations (custom entities, custom fields, relations, customizing UI),
multitenancy (if you want a hosted solution). The list goes on.

If latter, I would probably choose vuejs/Play2/MongoDB. (Replace Play2 with
RoR or Django or anything else).

------
goddamnsteve
1\. Ruby on Rails

2\. ReactJS

3\. Foundation for Rails

4\. MySQL

This is literally everything you need to get it off the ground as soon as
possible.

This is what has helped me build Allt.in ([https://allt.in](https://allt.in))
and UnderstandBetter
([https://understandbetter.co/](https://understandbetter.co/))

------
neverminder
Angular 2 or React front end, Scala / Play Framework 2 / Postgres backend for
some serious scalability.

------
warpech
Shameless plug (I am one of the devs):

Starcounter ([http://starcounter.com](http://starcounter.com)) is an in-memory
application platform, which is comprised of an in-memory database (ACID-
compliant) with a built-in app server.

You can compose a complex business system out of small apps (micro apps if you
will). Apps don't pull the data from the db - they run _in_ the db. Multiple
apps that run in the same db share the data in real time. Our first clients
are retail, CRM and advertising tech.

From dev perspective, we like to call our approach "collapsing the stack".
There is no ORM. Your code classes become the database tables. You can use our
(Web Components based) approach to create thin client HTML views that bind to
the data using JSON Patch. This saves you from running huge amounts of glue
code, which is typical for traditional software stacks.

Right now we are on Windows/C#. Linux and macOS is coming next year. Other
languages will follow.

------
pasta
Whatever you choose: for a CRM it's great to separate front end from the back
end. So build a very good (REST) API, because CRMs tend to be connected to a
lot of other systems.

Edit: looking at what you already considered, maybe: back end: Ruby, front
end: VueJS

~~~
SnowingXIV
I've used Vue before and it's one of those that I would love to build a
project around because like rails, the first time you use it the language
seems really magical, intuitive, and easy to write. The way it handled two-way
binding was awesome.

------
gorbachev
Personally I would look into using graph based data models.

I'm not sure how universal it is for CRM systems to be all about who knows
whom, from where and what's the nature of the relationship, but the ones I've
been involved with certainly all were.

------
eb0la
For me this is a workflow problem. CRMs are beasts that live on top of
workflows (both formal and informal ones).

If you can can get a good IBPMS for a nice price probably you have a good
solution that will be easily customized.

------
benologist
The best stack is most likely the last one you shipped a finished product
with. Every time you double down on that stack you're getting better and
faster at using it, code quality improves etc.

------
anthony_barker
My feeling is that no one wants to use CRMs. The best type of CRM is one that
autoloads contacts and information from cellphones, email, chat, accounting
systems,linkedin etc.

------
cryptos
My stack would be: Java or (better) Kotlin, JAX-RS, bean validation, JPA, CDs
or Guide, Postgres. I've no clear preference for front-end.

------
cwyers
If you have to ask a question like that, you probably shouldn't be writing
your own CRM.

------
odonnellryan
Reach out to me: odonnellryanc@gmail.com

I've built the framework to a CRM (Python and Flask) and I wonder how it'd
line up with your needs. I'm not currently using it, as it needs a bit more
work, but I'd love to talk to you about your project.

------
busterarm
Vue.js/Weex or Elm, Elixir/Phoenix, Postgres, OpenBSD.

------
droidist2
FrontEnd: React, Redux

Backend: KeystoneJS + React, Redux (Universal JS)

------
Entangled
Swift from the metal to the clouds. Everywhere.

------
bronlund
Check out golang!

------
lgas
Elm + Postgres.

~~~
ivanceras
Elm is for client-side, It needs some backend to talk to postgres. I would use
rust or maybe postgrest[0] would do.

[0]
[https://github.com/begriffs/postgrest](https://github.com/begriffs/postgrest)

