|
|
|
|
|
|
by MalcolmDiggs
4332 days ago
|
|
|
Most startups I've been a part of have done a combination of both. It really depends on which parts of the stack the lead devs are most comfortable with. If you've got a front-end ninja leading the charge you'll most likely end up with standard frameworks / generally-recognized-best-practices for the back end, while on the front-end they'll want to push the envelope. And visa versa if you have a backend person leading the team. A little bleeding-edge is a good thing. I wouldn't shy away from it on premise, but it does require that you trust your CTO 100%; and that they do their homework. Embracing a non-standard framework is great, as long as you truly understand what you're passing up. If your solution is better (and you can talk coherently about why) then more power to you. As far as onboarding new team members and/or supporting the system once it's built: in my opinion: thorough documentation and test-coverage are the crucial parts there. It'd be rare for a senior developer to be scared away just because you weren't using framework XYZ... but if your choice of framework is undocumented and untested that might make other devs say "screw it, either we're rebuilding this thing with best-practices or I'm walking away" ...not a situation you want. All that being said: at the end of the day, this person is the CTO... at this phase in your startup the MOST important thing is that you two get to a point where you can talk this kind of stuff out. This is one of the easiest/least-stressful decisions you'll be trusting them with; if you cant get to a point where you feel good with their explanation/decisions, then there might be bigger problems at play here. |
|
|