6 ms·

It is a fair question. The former CTO set the stack and was helping those two along. They're Ruby converts. After the CTO left, I asked if we should switch and

by Curll 12y ago

It is a fair question. The former CTO set the stack and was helping those two along. They're Ruby converts. After the CTO left, I asked if we should switch and they said switching to Ruby was more work than it was worth. The backend is pretty far along in Node right now. And we've got an Angular dashboard that we need to connect.

benologist 12y ago
Can you adjust your v1 to be something they can reach allowing at least some weeks to reach your market and iron out glitches? If that's impossible and you have to wait a year till next season then pull the plug and learn from it.
Iftheshoefits 12y ago
Another lesson that may apply: fad driven development isn't necessarily a good idea. Sometimes "old" (i.e. established, tested, widely used) technologies are better choices than whatever the latest fad offers.
- ams6110 12y ago
  Especially for a pre-investment MVP. Use what you know and are best at. You can later port to Node/Angular or whatever everyone is orgasming about this week.
- mackwic 12y ago
  I think you mean "easy to hire"-technology. One time it was Java, then it was PHP, now it's becoming node.js and angular. Maybe it's a bit soon, but it's far from insane to bet on these technologies nowadays.
  - Iftheshoefits 12y ago
    Yes, that is one very big reason to go "oldschool:" there are more developers who have more experience. It is nuts to follow fad driven development on a tight budget and hard time deadlines without significant understanding of the technologies involved. I'd argue that it is nuts in general to go with fad driven development. Choosing a technology structure based on fads is a dumb idea. One should choose a structure that makes sense for the project and team.
  - mercer 12y ago
    True, but it might not actually be a bad idea to hire based on an 'easy to hire' technology and actually use a technology that the developers are more experienced in. For example, I've worked in a number of environments that hired for node.js, but where the devs were actually recent RoR converts who were moderately proficient in node.js and its ecosystem. In the case of getting an MVP out quick, it might still be better to use RoR.
- jules 12y ago
  And another lesson: the founder(s) of a startup you should probably know at least a little bit about development.
- wpietri 12y ago
  Yes. There is a very high probability that everything that gets written in the early days will be thrown out. If the company fails, then there's no benefit in being in the hip language of the moment. And if the company succeeds, both scaling needs and the vast amount you'll learn about what your audience really wants mean that little of the original code base will likely remain. If today I were putting together an MVP with an eye toward getting funding, I'd only use things that somebody on the team knew very well. Learning new stuff is great, but it means you will be unpleasantly surprised a lot more often. Those WTF delays really add up, and they often come at the worst time.
balabaster 12y ago
The question is not how far along you've come with the existing stack, it's how far you're going to get with the existing stack. Is the development stack the right one to get you to a stage where you can get outside investment? If it is, you need to make a hard choice: Are your current developers the right team to get this product to that stage? If they are, suck it up and get on with it. If not, you need to consider the hard decision of replacing them. I can't speak to your team's competence (like a previous poster suggested) - everyone has their own situation. I'm working with a talented development team on a startup right now and I can tell you something for nothing, we're a few months in still analyzing what needs to be done and which stack is the most appropriate for that. None of us shy away from learning new technologies and all appear to have a knack for it. We've all got full time jobs and families and none of us are betting the farm... yet, we're quietly confident but it's early days. It's okay to be hungry and to believe in your dream, but leaving your family holding the bag to support that dream is not right in my mind. There will be many that will find ways to reframe this statement and disagree, but that's my bottom line. Don't believe that because your previous CTO decided on the stack that you're stuck with it. If you can get something to market quicker and easier by changing stack and you're not sacrificing anything except the skillset and ego of the previous CTO, do it - but don't do it just because you don't have the skillset of the previous CTO. If you've got less than no money and you're living out of your car, but you have food on your metaphorical table, then it seems to me you're not losing that much. Not changing because "it's more work than it's worth" is not good advice because it's subjective - if you gain a product by changing and don't have a product by not changing, then it's worth it. This is your baby, not your developers; make decisions from a business perspective with the technical understanding of a developer. don't make them from a developer's perspective - never lose sight of the big picture. What is your idea worth? $100,000? $1M? $10M? $100M? 100% of nothing is nothing - which is what you're going to get if you give up or let your developers stall your idea from getting to market. You will have incurred debt and the hardship of living out of your car. So you will have actually made a loss. Do what it takes to get your product to market on your terms, not someone else's. If that means changing stacks, change stacks. If that means sticking it out with your current stack and sucking up another couple of months of living in your car, that's okay too. Equally, don't be scared to give up because you've hit your limit. We all have limits and only you can decide what those limits are for yourself. Don't fail because of someone else's suggestion. Fail because you tried every avenue you could see and couldn't find a way to overcome the obstacles on those paths... and then when you "fail", stop, reflect, analyze, figure out where you think you went wrong, figure out how you could have overcome the problems and go at it again with a new perspective. If that means putting the project on hold for a few months while you get a job and dig yourself out of your hole for a few months, do it. If it means cutting back to part time so you have money in your pocket while you build, do it. If the project is worth what you hope and dream it is, don't give up on it. Just find a more sustainable approach to get it out there. This may be your only chance to make your own meaningful contribution to the world. Giving up on that is like giving up on the meaning of life itself... is that more or less scary than being in debt and living in your car?

by Curll 12y ago

benologist 12y ago

Can you adjust your v1 to be something they can reach allowing at least some weeks to reach your market and iron out glitches? If that's impossible and you have to wait a year till next season then pull the plug and learn from it.

Iftheshoefits 12y ago

Another lesson that may apply: fad driven development isn't necessarily a good idea. Sometimes "old" (i.e. established, tested, widely used) technologies are better choices than whatever the latest fad offers.

ams6110 12y ago
Especially for a pre-investment MVP. Use what you know and are best at. You can later port to Node/Angular or whatever everyone is orgasming about this week.
mackwic 12y ago
I think you mean "easy to hire"-technology. One time it was Java, then it was PHP, now it's becoming node.js and angular. Maybe it's a bit soon, but it's far from insane to bet on these technologies nowadays.
- Iftheshoefits 12y ago
  Yes, that is one very big reason to go "oldschool:" there are more developers who have more experience. It is nuts to follow fad driven development on a tight budget and hard time deadlines without significant understanding of the technologies involved. I'd argue that it is nuts in general to go with fad driven development. Choosing a technology structure based on fads is a dumb idea. One should choose a structure that makes sense for the project and team.
- mercer 12y ago
  True, but it might not actually be a bad idea to hire based on an 'easy to hire' technology and actually use a technology that the developers are more experienced in. For example, I've worked in a number of environments that hired for node.js, but where the devs were actually recent RoR converts who were moderately proficient in node.js and its ecosystem. In the case of getting an MVP out quick, it might still be better to use RoR.
jules 12y ago
And another lesson: the founder(s) of a startup you should probably know at least a little bit about development.
wpietri 12y ago
Yes. There is a very high probability that everything that gets written in the early days will be thrown out. If the company fails, then there's no benefit in being in the hip language of the moment. And if the company succeeds, both scaling needs and the vast amount you'll learn about what your audience really wants mean that little of the original code base will likely remain. If today I were putting together an MVP with an eye toward getting funding, I'd only use things that somebody on the team knew very well. Learning new stuff is great, but it means you will be unpleasantly surprised a lot more often. Those WTF delays really add up, and they often come at the worst time.

balabaster 12y ago

The question is not how far along you've come with the existing stack, it's how far you're going to get with the existing stack. Is the development stack the right one to get you to a stage where you can get outside investment? If it is, you need to make a hard choice: Are your current developers the right team to get this product to that stage? If they are, suck it up and get on with it. If not, you need to consider the hard decision of replacing them. I can't speak to your team's competence (like a previous poster suggested) - everyone has their own situation. I'm working with a talented development team on a startup right now and I can tell you something for nothing, we're a few months in still analyzing what needs to be done and which stack is the most appropriate for that. None of us shy away from learning new technologies and all appear to have a knack for it. We've all got full time jobs and families and none of us are betting the farm... yet, we're quietly confident but it's early days. It's okay to be hungry and to believe in your dream, but leaving your family holding the bag to support that dream is not right in my mind. There will be many that will find ways to reframe this statement and disagree, but that's my bottom line. Don't believe that because your previous CTO decided on the stack that you're stuck with it. If you can get something to market quicker and easier by changing stack and you're not sacrificing anything except the skillset and ego of the previous CTO, do it - but don't do it just because you don't have the skillset of the previous CTO. If you've got less than no money and you're living out of your car, but you have food on your metaphorical table, then it seems to me you're not losing that much. Not changing because "it's more work than it's worth" is not good advice because it's subjective - if you gain a product by changing and don't have a product by not changing, then it's worth it. This is your baby, not your developers; make decisions from a business perspective with the technical understanding of a developer. don't make them from a developer's perspective - never lose sight of the big picture. What is your idea worth? $100,000? $1M? $10M? $100M? 100% of nothing is nothing - which is what you're going to get if you give up or let your developers stall your idea from getting to market. You will have incurred debt and the hardship of living out of your car. So you will have actually made a loss. Do what it takes to get your product to market on your terms, not someone else's. If that means changing stacks, change stacks. If that means sticking it out with your current stack and sucking up another couple of months of living in your car, that's okay too. Equally, don't be scared to give up because you've hit your limit. We all have limits and only you can decide what those limits are for yourself. Don't fail because of someone else's suggestion. Fail because you tried every avenue you could see and couldn't find a way to overcome the obstacles on those paths... and then when you "fail", stop, reflect, analyze, figure out where you think you went wrong, figure out how you could have overcome the problems and go at it again with a new perspective. If that means putting the project on hold for a few months while you get a job and dig yourself out of your hole for a few months, do it. If it means cutting back to part time so you have money in your pocket while you build, do it. If the project is worth what you hope and dream it is, don't give up on it. Just find a more sustainable approach to get it out there. This may be your only chance to make your own meaningful contribution to the world. Giving up on that is like giving up on the meaning of life itself... is that more or less scary than being in debt and living in your car?