My current understanding of launching a new consumer startup involves going as fast as possible with a product's bare minimum that should make you uncomfortable launching.<p>I am launching a new mobile web app (ecommerce), we have competitors and know that the idea works (i.e. it is something people want). We are just adding a different angle to it.
To be able to launch fast I assume one would most likely assemble existing technologies and use existing frameworks, but I need confirmation.<p>My CTO is very much building everything from scratch, including every tool my team needs, and customising every little things (like the scroll, things like that). We are building our app based on his own Javascript framework (built before this startup).<p>Now I am concerned this might not be the right approach as it implies delay, and unnecessary customisation. We are going to take ~6 months to build this platform from scratch before launching it (already 4 into it).<p>Do you think that's reasonable? Should I require my team to use only existing tech to build upon, and customise things as necessary only after launch? (depending on feedback, time, priorities).<p>Experience + feedback much appreciated.
Most startups I've been a part of have done a combination of both.<p>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.<p>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 <i>why</i>) then more power to you.<p>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.<p>All that being said: at the end of the day, this person is the CTO... at this phase in your startup the <i>MOST</i> 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.
Yeah, you're pretty much doomed. If your framework is so great then it should be its own company; conversely if the framework isn't good enough to be its own company then you shouldn't be using it.
Creating your own tools will only add more friction into the process. One thing to be careful of is that a developer may invest time into a project because the developer loves building that project. That doesn't necessarily mean that it is good for the company. You might need to get an outside opinion on this, as the CTO is going to be attached to the project.