3 ms·
As a developer, and the lead for our GraphQL efforts since the day the JS codebase was released, I applaud your efforts. To us, GraphQL offers a smarter way to
by e1g 10y ago
As a developer, and the lead for our GraphQL efforts since the day the JS codebase was released, I applaud your efforts. To us, GraphQL offers a smarter way to frame API contracts and gives a significant competitive edge by increasing our dev agility. Spread the joy around!
As a businessman, I am concerned at the commercial realities of building persistence-level products for developers. There is a 'Death Valley' in pricing: you have to be very good at $0/mo (i.e. usable in production), and virtually infallible at $1,000/mo (and even then the first CTO's task will be to replace you). Being that good costs a lot of expensive engineering cycles. You guys a clearly smart, or you wouldn't get Scaphold to this impressive point so quickly nor get YC to support you. Yet other brilliant teams had crashed and burned in this 'Death Valley', with the most recent one being RethinkDB - also backed by YC, and among the most impressive ones for me. I wish you all the tailwinds in the industry, and encourage you to read the RethinkDB post-mortem to harness those winds better -> http://www.defstartup.org/2017/01/18/why-rethinkdb-failed.html http://www.defstartup.org/2017/01/18/why-rethinkdb-failed.ht...
- vning93 10y agoHi there, thanks for the support and feedback! I believe someone earlier on this thread raised the same concern and as a matter of fact, linked the same resource about RethinkDB :) The question was framed slightly differently in that that person asked about TAM, so this is what I responded below and I think it's still a valid explanation to repost here: "Great question, that's something that we've been thinking about for a while and I want to start out by defining what our market is. Given the various categories of offerings in the market today amongst managed hosting, DBaaS, and PaaS, Scaphold falls under the PaaS side of things. We do offer plenty of value-added features that attempt to make server-side development a lot more hands-off. However, at second glance, you could argue that Scaphold actually creates a new take on PaaS. Previous services have faltered at trying to do too much in one platform by essentially wrapping and containing all the services you need underneath one shell. So we're treading in unfamiliar territory where we think there's actually a lot more value in providing an interface for all your data across the web, as opposed to a complete wrapper around it in a self-contained manner. This way, developers can actually get the best of both worlds: 1) Having the benefits of using a backend as a service platform that offers value-added services like hosting, performance monitoring, tooling, app management, etc. And... 2) Flexibility in picking and choosing what services you need (like Auth0 or Stripe), tying in your own custom logic (through a provider like AWS Lambda), and even perhaps the database layer as well. Essentially, the vision is to allow developers to think as if they were rolling their own backend, while stripping out the time-consuming aspect of connecting these pieces manually. It's a much more modular approach where we sit as the hub of all your data across the web. To bring this back to the original point about TAM, this would ultimately open the door for us to a much larger market that includes any cloud service customer since they're not married to Scaphold as a backend. Scaphold essentially becomes an extremely versatile way to tie in your data that's hosted just about anywhere and combine it with the existing services you already use. That also reduces the pieces that we have to manage as well. My answer is by no means supposed to be a definitive way of thinking about TAM, but merely one way that we're evaluating it. If you or anyone reading this has any thoughts on this, we'd love to talk more privately about this and the direction we're taking Scaphold."