

Ask HN: Tailored vs. Assembled tech - gcost

My current understanding of launching a new consumer startup involves going as fast as possible with a product&#x27;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&#x27;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.
======
MalcolmDiggs
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.

~~~
gcost
very helpful comment, thanks a lot. I do trust him 100%, and we do talk a lot,
but having second opinions is always very helpful.

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

~~~
gcost
Thanks, that's what I thought.

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

~~~
gcost
you're correct that he loves building in general, and for that project in
particular. Now getting an external person to give an opinion will be great
but I have to make sure it's easy to swallow for the CTO.

~~~
gault8121
Yeah it's not going to be easy. It depends on how the project is being
financed, but you'll need to make it clear that the goal is to invent as
little as possible, and re-use as much as possible. The CTO could open source
the library and work on its as a side project.

~~~
gcost
I agree with you. Thanks for helping.

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

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

------
gcost
Do startups build their own tools at all? At what stage do they usually start
building custom tools?

~~~
wmf
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_.

