Is there such thing as a Startup Technology Stack?

Lately I've been talking and reading a lot about startups and product development, and two independent discussions have caught my attention. First, talking with an analyst working for a VC, he told me they don't "usually invest in Java company", because they feel Ruby, Python, C++ or (even!) .Net are more interesting for seed-stage startups. You can understand I wasn't that happy about his words, since we are fundamentally a Java company... but anybody is entitled of his own opinion.

The second interesting discussion started around "Why your startup should be using MongoDB", on the merits of NoSQL database used in startups.

So I went back to our technology choices. Our stack is currently composed by

• HTML/JSP + JS (mainly JQuery) for the frontend
• Java Web Application (our own REST framework + Guice + Hibernate)
• Jetty Web Server
• Apache Solr
• MySQL
• some minor scripting in Python

That's a pretty typical enterprise Java application architecture, derived by our multi-year experience in consulting and contracting for banks, telcos and IT companies.

Now I don't think I have to prove our stacks works, scales and performs well; there are plenty of enterprises out there running with similar systems, plenty of success stories, and I have seen my share of good and bad projects.The real question is: is it the right stack for a startup? To avoid the usual "it depends" answer, let's talk about the requirements of a startup (Pareto law apply here)

1. Release early and often.
2. Keep pumping out features
3. Do customer development from day 1
4. Refactor the business model as often you refactor the code (ok, a bit less frequently)

In other words, it seems like the startup scenario is quite different from the usual enterprise software scenario. At least, that's what I discovered in my experience.

So how our stack copes with this situations?

Having a REST framework really is the best choice we did. It draws a clean and definite line between the frontend and the backend, and give us the possibility, if we want, to migrate the backend to a different implementation or technology, one URL at a time.

I've been developing Java application for the past ten years. I know I'm very productive with it, especially when I keep it simple (KISS) and don't overindulge with frameworks and overdesigned solutions. I know it would take a long time to be equally productive with another language.

However, I also recognize that sometimes dynamic languages can be, guess what, ...more dynamic. More compact code, faster to write and to maintain when the domain is small. I'm learning more of Python every day, and I'm not blind to its potential when it comes to rapid development.

I definitely don't see us migrating to it (or to Ruby, for what that matters) anytime soon, but I can foresee we might want to write some parts of the application with it soon. The REST approach will make this transition easy.

As Paul Graham suggests, we try to pump out features and bugfixes as fast as we can. That means changing the DB schema. That means migrations. Ugh

We cannot honestly do otherwise. The times of startups raising 5M$, developing in-house the product and finally releasing after 18 months are gone for good; besides that, the last time I checked nobody had given us 5M$, so we don't have this opportunity! We deployed a production version after less then 3 months of part time development (it was ugly, thanks for asking!). We went to customers and investors, we got feedback, we added features. And then again, and again.

Our data layer is what slows us down. We try to concentrate all the changes in the data model (and therefore in the DB schema) in a unique release, so that we don't migrate so often. And we postpone big data layer refactorings because they will cost us a lot.

In this case, using a schema-less database (like mongodb, but that's not the only option) would save us a lot of time. I'm currently prototyping with mongodb and redis, and the flexibility they give to developers is huge. (And notice I'm not talking about performances because it wouldn't be fair to relational database which offer many more functionalities).

My impression so far is that there're some fundamental differences between enterprise technology stacks and startup technology stacks. The former are targeted to build applications whose scope and mission are somewhat clear (of course there are a lot of change requests also in enterprise software development, but the final goal is clear); the latter are targeted to build applications that "explore" new features, new concepts and new business models.

The former are targeted to write code that will last 3-5 years; the latter to write code what will most probably not survive more than a year (because the company will fail, will pivot, or will rewrite it once successful).

Broadly, a Startup Technology Stack (tailored to my needs and skill) is currently composed by

• HTML + JS in the fronted
• Java Web Application (and/or Python) in the backend, using a REST architecture
• Document-based, schema less database

What's your take on this? Do you have a Startup Technology Stack?