I've never understood this "don't obsess about performance at the start" rule.<p>Is it really that much of a problem spending a few extra hours prototyping different solutions and factoring in performance from the start. Why wouldn't I pick Vertx over Play if it 2-3x faster with similar productivity. That's money not spend on VPSs that can be used for marketing.<p>Likewise why wouldn't I look at a binary serialization format if it means my iPhone app starts up 5 seconds quicker. Users decide whether or not your app is worth keeping in those few seconds of starting the app. Why not spend time trying to keep them ?<p>Or as great as PostgreSQL is for single server deployment why wouldn't I look at something easier to manage, trivial to scale and a more agile schema like a DynamoDB, MongoHQ, Cassandra. Especially if I am a single person startup.<p>I understand about premature optimisation but it seems to make a lot more sense to properly consider your architecture from the start rather than deferring it. Or did we all forget Digg v4 ?
<i>When you’ve got an idea, and a team, and you’re raring to get started on hacking for a potential startup, a question that often comes up is, “well, what technology should we use?” (hopefully you’ve answered the necessary, “what problem are we solving and how are going to solve it” questions first).</i><p>And hopefully, long before that, you've answered "Who cares about this?", "How will I make money?", "Is there actually a big enough market?", and so on...
<i>Ultimately, the most important thing to keep in mind is that your “stack” shouldn’t define you.</i><p>While I agree with this advice in general, there are cases in which it is advantageous to allow your stack to define you. For example, Jane Street Capital appears to have established themselves as <i>the</i> place to work if you are interested in both functional programming and finance, greatly aiding their recruiting efforts.<p>Granted, they didn't start out using OCaml; their founders made a switch after the firm had already established itself. However, I wouldn't be surprised if a startup (where the founders have a specific skillset/background) could exploit a similar first-mover advantage.
Technology is not important for your startup. Choose whatever you know. Then go from there and fix it when you scale because you've found a market.<p>About time to market: From my experience (and Reinertsen [1]) time to market is not lost during programming but during the decision phase. Optimize your decision speed (reduce meetings, don't postpone decisions, have a clear decider, know what to decide and what not, ...), not your technology stack if you want to beat others to market.<p>I did have an offer for some years: Anyone beating a Java (the COBOL of the internet world) stack 5x to market, I pay him $1000. No one did take it yet.<p>One of my slide deck on the topic:<p><a href="http://www.slideshare.net/Stephan.Schmidt/what-everyone-should-know-about-time-to-market" rel="nofollow">http://www.slideshare.net/Stephan.Schmidt/what-everyone-shou...</a><p>[1] "Developing Products in Half the Time: New Rules, New Tools" Preston G. Smith, Donald G. Reinertsen
Lots of good advice. One nit:<p>I would change "Don’t obsess about potential performance" to "Don’t obsess about potential performance except for binary roadblocks".<p>What's a "binary roadblock"? Something that, when it doesn't run fast, no amount of "tuning" could fix it. You better be obsessing over things like these or you'll be dead in the water as soon as that nasty roadblock manifests itself. Some examples:<p><pre><code> - 2 proven technologies whose combination is not proven
- bad database structure that doesn't hurt until a query you never planned for
- bad program structure whose memory leaks don't show without an outlying case
- lazy code that blows up as soon as programmer #2 "enhances" it
- shit that works by accident until it doesn't work anymore
- sleepers than appear to run well until you try to scale
- structures aimed at incorrect user assumptions
</code></pre>
Speed to market is important. Careful thought into what can easily become a roadblock is just as important.
points not mentioned...<p>When making decisions for a library, ask yourself:<p>1) "What kind of problem is this library solving?" "Can I solve the same problem in a simpler way with less code, and later adopt the library if necessary?" -- Dependencies don't always make your life easier.<p>2) "Does this library make certain problems simple, and other problems no less hard than before? Or maybe SLIGHTLY harder?" -- Last thing you want is to limit yourself to a subset of solutions. Until you know EXACTLY what the long-term goal is, marrying to something that ties your hands is a bad idea.<p>3) "Is it magic?" -- This is important. In a startup you don't have time time or resources to just sit down and grok a library. If its too magical then its better to avoid it because when something goes wrong, you will have to either sit down and grok it, or rip it out.<p>Other bonus points for good decisions:<p>Break everything, but have the most solid data model possible. Test the shit out of it too.
Most new ventures would do well starting with a mature CMS like Drupal, Joomla, etc. They'll get you well down the road to a complete website with the boring stuff like user registration, a built-in blog, templating, SEO, and so on already built in or readily available as an add-on.