10 ms·
Picking tech for your startup
- webjay 13y agoopbeat.com is one of the coolest startups in Cph for the moment
- swombat 13y agoWhen 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). 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...
- bennyg 13y agoMeh - I'd rather make something that's awesome for myself, then figure out marketing it so other people can benefit as well. I believe that thinking about a market and how to make money first is the wrong avenue to go down if you actually want to care about a product you make. If I want it for myself, I'll make it. If I think other people will want it, I'll find a way to get it there - either by selling or giving it away. Maybe that makes me a bad entrepreneur, but it means I have more fun in the things I build.
- acangiano 13y agoYou just described the difference between a project and a business. All businesses are projects, but not all projects are businesses. There is nothing wrong with creating projects for the sake of creating projects. But if you are trying to create a business, market and marketing come first and you should consider them way before writing your first line of code.
- bennyg 13y agoI still disagree. Just because something isn't business viable doesn't mean you shouldn't do it. You should pretty much always do it - then decide if there's a market/think about how to market for it. A business for the sake of just making a business feels wrong. A business for the sake of making an awesome product feels right.
- janardanyri 13y agoYou seem to be implicitly thinking of 'marketing' as pejorative. I'd suggest instead that identifying an audience for a potential product is actually part of making an awesome product. There's a pretty wide stretch of territory between not caring whether something is business viable and only caring about building a successful business.
- white_devil 13y agoHe meant that if your goal is to make money with a business, then you should start with businessy stuff like figuring out if there's a market for what you want to build. You're free to start a business by building the product of your dreams, but no matter how much you personally like it, there's no guarantee people will pay for it. In other words, if you want money, but start with building a product, you're likely to have a bad time. But if you just want to build an awesome product, and don't care about whether you make any money with it, then there's no problem.
- taude 13y agoMeh - there's a lot of people out there scratching itches that are nothing more than minor inconveniences.
- ryporter 13y agoUltimately, the most important thing to keep in mind is that your “stack” shouldn’t define you. 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 the place to work if you are interested in both functional programming and finance, greatly aiding their recruiting efforts. 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.
- gluczywo 13y agoAgree. I wouldn't treat it as a rule. Normally it's the right thing to start with solving user problem, but I see many successful businesses built on trying to find application to the "new cool stuff". Github is one more example of the company driven by technology choice first.
- voidlogic 13y agoNot to mention that without a lot of ACTIVE effort to make the stack NOT define you it will. The stack will strongly influence who you hire and who you hire will easily come to define you. A bunch of C/C++/Java/Rust/Go folks are going to have a different value set than a bunch of PHP/Ruby/Perl guys. Not to say their isn't overlap in people or ideas, but people who are attracted to similar technologies are often more self-similar compared to people attracted to other technologies. Depending on the problem space a given technology and the mind-sets that come with it by default may be or less helpful.
- deleted 13y ago[deleted]
- threeseed 13y agoI've never understood this "don't obsess about performance at the start" rule. 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. 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 ? 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. 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 ?
- prawks 13y ago"don't obsess" is much different than "don't consider". It's dangerous to prematurely over-optimize, as the OP says, but it's never a bad thing to think about optimization. Otherwise you'll end up with crap.
- psycr 13y agoSimply because it's never a case of spending "a few extra hours" when learning and evaluating a new tool. There are many "unseen" hours in troubleshooting, monkey patching, and re-evaluation. These are real costs that can be avoided by defaulting to known best practices (at the expense of ultimate performance).
- simondlr 13y agoWorked with friend on a new idea (while also trying new tech across the board), ended up in this: http://simondlr.com/post/26360955465/dynamodb-is-awesome-but http://simondlr.com/post/26360955465/dynamodb-is-awesome-but When we got traction, we wanted to change databases, but because it was just a weekend hack no one wanted to spend time doing it and eventually killed the app. It was our own doing of course (choosing new tech to work with). But yes. Work with what you know when testing ideas, unless you also want to play with new tech.
- edw519 13y agoLots of good advice. One nit: I would change "Don’t obsess about potential performance" to "Don’t obsess about potential performance except for binary roadblocks". 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: - 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 Speed to market is important. Careful thought into what can easily become a roadblock is just as important.
- lojack 13y agoAs I like to put it, having the ability to optimize isn't considered premature optimization (IMO). Picking a technology because its fast might be a poor decision early on; picking a technology because it has the flexibility to allow you to make it fast might be a great decision.
- bhauer 13y agoTo a degree, this common desire to know the amount of headroom available for optimization was an impetus for our web frameworks benchmark project [1]. Some readers of the results have asked why the tests are so trivial (although the multiple query test is anything but; and we are adding more computationally intensive tests for later rounds). We chose to start with trivial request types to establish the high-water mark that the platform and framework set. Any given web application built on the framework can only expect to perform with higher latency and fewer requests per second than the high-water mark. In turn, the higher-complexity request types provide some insight into the converge-to-zero point along the complexity axis. Prior to seeing the data, I think some of us intuitively assume the converge-to-zero point is lower than it actually is, using the all too popular refrains such as "well, the app is always waiting on the database anyway." Yes and no. Certainly database queries are generally expensive. But some frameworks can run twenty trivial queries on a gigabit-connected database and serialize the resulting list to JSON faster than others can serialize a single trivial object to JSON. Choosing a framework that provides headroom for custom application logic--and having a rough idea of how the platform will perform with your custom logic as demonstrated by representative tests--is a good idea. And it doesn't take a whole lot of effort to do that kind of research now. It's easy to avoid premature scale pain. [1] http://www.techempower.com/benchmarks/#section=motivation http://www.techempower.com/benchmarks/#section=motivation
- Uchikoma 13y agoTechnology 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. 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. 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. One of my slide deck on the topic: http://www.slideshare.net/Stephan.Schmidt/what-everyone-should-know-about-time-to-market http://www.slideshare.net/Stephan.Schmidt/what-everyone-shou... [1] "Developing Products in Half the Time: New Rules, New Tools" Preston G. Smith, Donald G. Reinertsen
- taude 13y agoI had similar thoughts seven years ago when Ruby on Rails was being sold as 10x faster to develop in....I wondered why no one would build my website for 1/10th the price.
- taude 13y agoI'd add one thing, though about an optimized stack for a startup with a lot of unknowns. I've attended a couple hackathons and such and seeing how much traction and how quick small teams are able to piece stuff together with a JavaScript/Node.JS/MongoDB stack is pretty staggering. Not sure if it scales far down the road or what issues people will run into, but having a single language across the entire stack seems to have some productivity benefits. Especially when you have a developer that has to work in two or three of the layers (UI/Server/DB) all at once... There was some VC around here who talked about the advantage that startups have because they can choose some of these tools to quickly develop in and such...
- Uchikoma 13y agoNot sure how Nodejs helps, I agree that Mongo helps, schemaless is easier to evolve from my experience than MySQL e.g.
- chromaton 13y agoMost 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.
- pekk 13y agoI don't think it is so obvious that almost everyone should choose to base their projects on PHP. The only time it should be an obvious choice is if you have lots of PHP talent.
- Justsignedup 13y agopoints not mentioned... When making decisions for a library, ask yourself: 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. 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. 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. Other bonus points for good decisions: Break everything, but have the most solid data model possible. Test the shit out of it too.