71–80 of 95 posts
Congratulations on your launch! Please take this constructively, but I can't help but think that the prevalence of GraphQL in your messaging is a huge distraction. It seems like the real value in Scaphold is letting people build applications faster, with less effort. In fact, in your post's description of the problem you're solving, you don't mention GraphQL at all (until you start talking about solutions). Right now…
Congratulations on your launch! Please take this constructively, but I can't help but think that the prevalence of GraphQL in your messaging is a huge distraction. It seems like the real value in Scaphold is letting people build applications faster, with less effort. In fact, in your post's description of the problem you're solving, you don't mention GraphQL at all (until you start talking about solutions). Right now…
as a data point, i had no idea what GraphQL was.
Earlier quoted context omitted.
as a data point, i had no idea what GraphQL was.
And how much of the "rapid app development" messaging were you able to glean away from checking out our site? Was it confusing for you not having known what GraphQL was upon reaching our page?
If we were to build an app, how portable is this application if we were to self-host it later or move to a similar provider?
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.ht...
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…
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."
My only words of advice are focus on the business and finances just as much as the coding. Unfortunately the best engineers and technology don't always win (see RethinkDB). I'll be tinkering around tomorrow with Scaphold, might work out well for a side project of mine. Best of luck!