Technology stack · Code stack

Technology stack suggestions based on the following business requirements?

Kate Hiscox

January 15th, 2014

Firstly - cheers @Jake Carlson for helping me better frame this question.

Briefly, I've customer tested a concept that monitors IMAP compliance and facilitates the exchange of data between manufacturers and online merchants. The business requirements are;

- User registration (multiple roles and user hierarchy)
- User invitation creating a subset of users attached to the parent
- Notification engine
- Upload data via FTP, API
- Data mapping
- Clone and edit existing data
- Monitor and compare data on external websites with rules set by users
- API with access to data for developers to create apps and services
- User created forms
- User dashboards
- Report engine
- Subscription billing inc. third party billing and commissions

I'm actively seeking a technical co-founder(s) but it would be awesome to get feedback from the community in regard to their ideal tech stack. That will put some batteries in my torch so to speak.

James Bond CTO at SupplyBetter

January 15th, 2014

I'd suggest using a computer programming language running under some operating system ;-)

Seriously -- almost any modern stack could work for these requirements, there's nothing I see here that's technology-specific. Don't let anyone snow you that this stack or that stack would be "better" or "more productive" -- It's really more about what your tech co-founder is most comfortable with, and to a lesser extent, the infrastructure you want to use (though that's become pretty ubiquitous across different stacks as well). Another consideration is availability & cost of contractors -- that varies a lot, with the hottest languages/stacks (currently, I'd say Node.JS and Ruby) commanding the highest, and PHP the lowest.

Kate Hiscox

January 15th, 2014

Wow - thank you for all the incredible advice. Its great to know there are plenty of options. In my experience, .NET and SQL can mean mega $ on licenses and dev costs. I couldn't see the benefit of that combo at all for an agile startup unless there was a very specific use case.

But again - just wow. I really appreciate all your comments! And @Tom - it was, but hugely informative. Thank you!

Tom Maiaroto Full Stack Consultant

January 15th, 2014

Cool. You can use a myriad of technology combinations to reach those goals. I'd next think about the type of developers you would come across in your area and what the salary ranges are. This will help you understand your business, timing, and finances better. As they relate to your technology/app/site/code/tool/dashboard/product. How easy is it to find and replace talent? Expect to replace talent in a startup. People will come and go or you'll be forced to sadly get rid of people. Happens.

So stay flexible. I'm not sure where this PHP hate is coming from and this push for Ruby. I would argue that Ruby is a dying language that's finding it increasingly difficult to differentiate itself (PHP and Node.js are eating into Ruby's distinguishing purposes from opposite directions). While it was an important part of internet history here, the fact of the matter is major companies and early supporters are moving away from it and on to other languages. This means you'll see less Ruby developers in the future and they will likely be more expensive as a result. Not a very wise business decision if you plan to stick around for a while. Again this has absolutely nothing to do with what you can or can't do with Ruby as a language. I'm trying to shed light on how our technology choices affect our business. Stay flexible and open to things.

Of course, if you have a ton of Ruby developers in your neck of the woods, then it may make sense to use it. Just understand why you're choosing a language. It goes so far beyond the technical aspect of things.

Node.js is a lovely suggestion. It's a very progressive language that's gaining a lot of momentum and finding a developer is far easier (and cheaper) because it's essentially JavaScript. Your Node.js developer will only be more expensive (depending on your area) due to demand. It's hot right now. Whereas choosing something like .NET or Java may be more expensive due to larger corporation and "enterprise" culture/mentality. This won't easily change either. Large corporations like to use Java and .NET (and it's also particularly popular in certain regions of the world/country) and they can actually pay more than a smaller startup. So your developers savvy in Java and .NET will be looking for a higher salary because well, they can easily find it. 

I just don't think Java or .NET is agile enough for a startup to be frank. PHP, Node.js, and Ruby are all web languages geared for rapid application development. Java and .NET are geared for the inefficient and slow corporate world that can support teams of 50+ people building a simple web app. Boggles my mind how that happens.

So I'd highly suggest sticking to Node.js or PHP to be honest. Sure Ruby too, I'm not hating on Ruby...But do your research and see what the developer market is like in your area. There's all types of developers all over...But you really may be in a weird pocket that has an abnormal amount of developers who are savvy with a certain language. I'm puzzled how this happens, but it does...Look at job boards.

Another benefit of a full JavaScript stack is now your back-end developers are also front-end developers...Again business decision. I can't stress this enough. The way many CTOs go about choosing technology is often from a Lord of the Rings perspective. It's their "precious." Who knows. It's this weird loyalty thing. But it often doesn't have a thing to do with business and real world, practical, needs.

I would suggest MongoDB for a lot of your data, but when you get to billing - if you aren't using something like Stripe's service you will likely want a transactional database. No reason you can't use multiple databases!

As far as your report engine, MongoDB is a fine fit there. Should you have heavy duty aggregation needs and the aggregation framework within MongoDB is not enough, nothing is barring you from Hadoop. You can also migrate to some Amazon Web Services for your data warehousing and aggregation needs just fine from MongoDB. I'd also suggest looking into Elastic Search for your reporting. It's a search engine and so much more.

On the front-end think JavaScript of course and when you're dealing with dashboards and reporting, D3.js is a great library (NVD3 is a great graph/chart library using D3). I'd suggest combining that with AngularJS for a very modular dashboard that allows a front-end developer to work in tandem with a front-end designer and not worry about touching the same files. You can separate the templates from the JavaScript code that's powering the visualizations for your dashboard. Ember and Backbone are also good alternatives here. I just think AngularJS makes things awesome with it's directives. If you have a lot of front-end design and UX work to be done.

One last reason I suggest AngularJS is because you may also want to use Elastic Search. Throwing your data set into that can do wonders for you and your database costs. And... Kibana to the rescue: http://www.elasticsearch.org/overview/kibana/

The real time reporting dashboard that Elastic Search and Kibana bring you, especially for the amount of setup time, is just sexy sex.

This open source modular reporting tool can really help save you time. Best of all, it's written with AngularJS. So you're compatible now with anything else you may having going on with AngularJS and your JavaScript developers will be ready to extend the functionality of Kibana by building their own directives.

Again, this is just one approach out of many possible approaches. For what it's worth, I build many custom CMS' and dashboard tools with visualizations and work with big data. A lot.

Anonymous

January 15th, 2014

Guys, let's not make this a "this stack versus that stack" discussion as it's really not worth it for this situation. Again, nothing here screams Ruby, .NET/SQL, or Java. They're all tools and all of them can help solve Kate's problems. At the end of the day, the thing Kate really has to worry about is who ends up writing the code ... for example, .NET with C# could be considered "mature", but in the wrong hands, you can easily end up with terrible software. I currently write a lot of Ruby (with Rails) at work, but it doesn't mean it's the best tool for every job, and sometimes you CAN go wrong with Ruby (with or without Rails). We all have favorites and biases, but none of that will help Kate.

@Kate Hiscox:

Do yourself a favor and focus less on the stack and more on who ends up building your stack. Nothing in the requirements you listed here screams any particular tech stack. A good engineer should be able to take lead and keep you from worrying about most of this stuff anyway.

Keiran Betteley

January 15th, 2014

Just to throw in my two-penneth, having run teams on a few different technologies. (Scala, .net, java and rails) I'm a fan of rails, though not a fanboy (it has it's irritations and limitations). The advantage I've found when developing with Rails is that it does have an awful lot of things you can just 'plug-in' and work pretty much out of the box, a whole world of gems which deal with almost everything you're proposing here. People write things with rails to help other people who use rails. It's sort of part of the point of it. That means that you don't need to solve every problem yourself at the start. In my experience this is certainly just less true of other frameworks, though it may be partially true of some. I've also found, because of this, and this is just my experience, that it's easier for a rails dev to pick up someone else's project than it seems to be in any other language or framework. i.e. you're not stuck with the first guy you pick. I think this is again related to the attitude towards sticking to convention or doing things 'the rails way' referred to above. Now, in terms of building a perfect platform from the ground up that will scale beautifully and remain with you until your dying day, that might not be what you want and you might want to build everything bespoke. If that's the case, then rails won't be your best bet, but that's not what it sounds like you want. I'd lean towards saying get yourself off the ground with rails as it will inevitably get you somewhere like where you want to go quicker and easier for the basic stuff.

Keiran Betteley

January 16th, 2014

Just so we are all aware.... At polite gatherings such as these...

Jake Carlson Software Development Manager at Oracle

January 16th, 2014

Chris, out of the 400 hundred interviews you've done, how many of them were for a senior PHP position? It's begging the question to conduct interviews for a non-PHP position and then turn around and decry the lack of senior-level engineers who prefer PHP. Surely the job description was not for a 'Senior Engineer' with no mention of specific technologies?

I don't know how you're defining 'senior', but many of those technologies can't have practitioners that have too many years of experience with it because they are fairly new. Also, I've found that language preference is largely a function of the circles you travel in. In certain circles certain technologies have very little uptake. Anecdotal claims about a single person's experience should not be generalized with the statistics to back it up.

Let's not forget that PHP is by far still the most popular server-side language for the web. Yes, it has a low barrier of entry, and yes, because of that there are more low-quality PHP developers than in some other languages, but you just can't argue with the numbers. If it enjoys magnitudes greater usage than other technologies, then surely there are going to be quite a few developers that know what they're doing with it. It defies logic to claim otherwise. I'm saying nothing about the merits of the language itself, I'm just talking about sheer statistical probability.

Mike Stankavich

January 15th, 2014

Where's the Python love?? :) Python + Flask or Django + Postgres or MongoDB would also work fine for this app. But like most have said, developer availability and your technical co-founder's background should be your primary drivers.  And I'll also second the notion of sticking with the scripting type languages for better agility. You want to get the app built and operational first, then worry about scaling where needed. A lot of the heavy hitter startups went way down the road with PHP, Python, or Ruby.

Jake Carlson Software Development Manager at Oracle

January 16th, 2014

Can of worms: opened.

Kate, I agree with other folks here who are saying that you should focus on getting that technical co-founder and let him/her drive the technology decisions rather than deciding on a technology stack without him/her and limiting your pool of potential candidates based on that [somewhat arbitrary] decision. 

If you had an existing codebase to maintain, that would be one thing, and it would totally make sense to go out and find someone with experience with that stack. But if you're starting from scratch, find the person first. Get someone you trust and has demonstrated technical proficiency on a project of similar scale to yours (regardless of the stack). The person should be able to talk intelligently about what issues need to be considered, but I would be wary of a co-founder that thinks there is only one way to skin a cat.

I know it's tempting to come up with some criteria to focus your search for a co-founder (I do that sort of thing all the time), but please please please don't decide on the technology stack before you've decided on the person that's going to implement it. As a technical co-founder, nothing would annoy me more than my business co-founder deciding they know more about the technical implementation than I do, just as I'm sure you wouldn't be too happy if your technical co-founder stepped on your toes with regards to how you run your business.

Tom Maiaroto Full Stack Consultant

January 15th, 2014

Jonathan, of course things can go either way. When you drill down into each language in more detail you'll have varied experiences. Like you said, scale issues with Ruby on Rails. I wasn't so much speaking to issues of scale though. As you know, WordPress and Drupal and older PHP frameworks can have issues with scale as well, right?

So your milage will vary. What I was trying to communicate was broader themes and scenarios we often seen in the industry. It isn't to say you can't be successful if you use x, y or z. Facebook uses PHP. Mass Relevance uses Ruby. So there's two major companies right there in the data space that can sorta complete the picture.

It isn't about what's "possible" and what isn't. It's about being able to navigate what's best for you, your project needs, your timeline, your budget constraints, and your geographic area.

Just trying to bring the conversation away from the nitty gritty of programming.

The syntax familiarity of JavaScript is good for bot Node.js and front-end JavaScript needs. It is far easier to get a front-end JavaScript developer to help out on the back-end if it's Node.js vs. practically any other language. Typically it goes that way too. Rare is it that you find Node.js developers who aren't good with front-end JavaScript... Though it's possible and they too would pick up the front-end far faster than any other programmer who is more familiar with other back-end languages. I said nothing about browser API issues or CSS. Both of which can be a nightmare problem to even the most skilled front-end developer anyway. So it's not as if a front-end developer is somehow immune to those issues whereas it might plague a back-end developer. Let's face it...We all suffer when it comes to lunacy like IE6 =)

I also wasn't trying to suggest Elastic Search works better with Angular... I'm suggesting the Elastic Search team favors Angular. Look up Kibana.

If I didn't make it clear in my response. You have a myriad of options.

Hope that clears it up. I totally agree with what you're saying. I was just trying to make broad strokes because diving in deeper can be done by one's technical co-founder...And I already wrote enough? =)