Ask HN: Tailored vs. Assembled tech

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.

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.

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).

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).

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).

Experience + feedback much appreciated.

What happens when the company grows? Who will maintain the app that's built on his custom framework?

CTO is currently very sceptical in hiring new people, even though he's getting his framework better and better documented. Bottom line is it will be difficult to train new guys, and we only want the very best (i.e. not a normal engineer).

Almost all good tools were built for in-house use first. Rails is a classic example and there's a front-page article today about the history of Cassandra. But you should only build a tool if that's less work than learning/adapting an existing one, which is almost never. Either existing stuff has to be really bad/nonexistent or youhave to have an idea(+execution) for how to make something 10x better and a need for 10x better.

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.