There are so many lines in the post series that don't make very much sense if you understand the YC program.
> We'd aim to have 4 to 6 developers on the project within the first few weeks, and had a substantial budget to achieve this.
What budget?
> The hiring process began immediately with advertisements going up on social media
As the CTO, would you not be able to contribute more to this project?
> One of the huge benefits of the YC program is the ability to experiment with scaling ideas.
Talking about looking into scaling before having anything usable or users? Time would have been spent better actually building a prototype to prove the concept.
> As the first Demo Day approached, despite being a director and CTO, I was instructed not to attend due to not being part of the initial interview process.
I kind of suspect at this point in the post series, that the author wasn't really a "director" or "CTO".
After reading the lessons in the third post, sounds like the author just jumped at the chance to be part of YC without much knowledge of what he would actually have to contribute.
I have my GitHub profile, but it doesn't have much on it except a few random open sourced projects and some random open source contributions. A lot of other work is for past/current employers which I can't exactly show off easily.
If you built an app knowing it NEEDS push notifications on a platform where it's optional for the user to enable/disable, you failed as a developer. The application should be able to function either way. Users deny getting their location? Ask them to input a location instead.
"The commands will trigger a webhook call to your server, where the actual deployment/testing/whatever command you need takes place."
The end user still needs to run something on their servers to actually do anything for their custom commands, which is essentially what hubot scripts do, which is what my book is teaching people about.
So you came here to advertise your own product in a post about mine?
You're basically deploying a thing that'll send http requests to another server which then executes specific tasks. So you've essentially replaced hubot with a web application on the end users servers.
I'm trying to understand which part of my book you're trying to 'avoid'. Because from what I understand it's just the deploying bit? Which my hubot-factory already did, and it is being improved for a new version with the help of a great company. You've also essentially made script writing even harder than it is for hubot.
I recently added a HTTP route to hubot `/hubot/help` that you can visit if you enable the HTTP support to view the help on a page rather than flood channels.