
Launch HN: Scaphold.io (YC W17) – GraphQL Backend as a Service - mparis
Hi, we&#x27;re the founders of Scaphold.io (<a href="https:&#x2F;&#x2F;scaphold.io" rel="nofollow">https:&#x2F;&#x2F;scaphold.io</a>) in the YC W17 batch. Scaphold is a GraphQL backend-as-a-service platform that helps you build apps fast. We built Scaphold because we were app developers and we were frustrated by how long it took. We started building apps together back in college, and every time we started a new project we found that we spent a lot of time doing the same things. Whether it was setting up the infrastructure, integrating APIs, managing REST endpoints, or even implementing something as simple as pagination it took a lot of time. BaaS platforms have existed before but we were disillusioned by the lack of flexibility they provided. This all changed the day we first found GraphQL in an article posted here about a year and half ago (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10217887" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10217887</a>).<p>At the time, we were working at Microsoft and started hacking on what eventually became Scaphold at night and on weekends. We were driven by this vision to be the foundation for people&#x27;s apps, the scaffolding of their masterpieces. We were lucky to get accepted into the YC Fellowship program last April and launched our first version of Scaphold last May. We learned a lot. The Fellowship program helped us gain initial traction and after several months of focusing on product and strong growth, we reapplied to the YC Core program and were fortunate enough to be given an opportunity to join the winter batch and to continue the dream.<p>Since then we have been hard at work improving the platform and have reconstructed it from the ground up. Today, Scaphold powers thousands of apps and we think it solves a lot of the problems of BaaS platforms that came before it. We&#x27;re really excited about what we have built and would love for you to try it out. It&#x27;s free to sign up and development tier stays free forever so you can get straight to building apps.<p>We&#x27;d love to hear your feedback and are happy to answer any questions. Thanks!
======
tschellenbach
I just don't believe in the 1 backend to rule them all approach. Services like
Stripe, Algolia, Datadog, Pusher, Mapbox, Imgix etc all make a lot of sense.
It's easy to plug them in to your existing backend and extend your app's
functionality. Using someone else's backend for your app is a terrible
decision though, the lock-in is just too large.

For this to succeed they'll need to add a lower level interface to the mix.
Something like AWS' Lambda.

Question for the founders, will there be an extension platform, something like
Parse cloud or the Heroku app store?

~~~
AznHisoka
"Services like Stripe, Algolia, Datadog, Pusher, Mapbox, Imgix etc all make a
lot of sense"

Yep, and that's because they solve a really really challenging problem you can
almost never solve yourself, whether it's payment processing or search.

Creating a simple barebones back-end may be tedious (though I'll argue it's
trivial), but it will never be an unsolvable problem for many. Maybe for pet
projects, but never for any critical production applications.

~~~
mparis
Thanks for the comment!

It is true that companies can often build their own backends but it is often
extremely time consuming and expensive. It takes time to develop these systems
and build them to scale and often they run into a problem where early
assumptions change while the underlying system is hesitant to.

One of the core value props of a platform like ours is the speed at which you
can iterate and develop something while also being given the tools to pivot
when you need to. We are focused on building features that allow you to extend
the platform to make it achieve what you need so that you can spend more
resources developing the value that is important to your customers instead of
the pipes underneath.

Of course our solution cannot work for everyone but the companies that we have
worked with thus far have told us that increased their application throughput
by 8x compared to when they built backend themselves with frameworks like
rails/django/node.

------
runako
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, the (gorgeous) site feels similar to if Shopify had
launched with messaging focused on its use of Rails on the backend.

It feels like you could also be targeting the type of less-sophisticated
business programmers for whom VBA is often a weapon of choice. However, when I
read your site, the fact that I don't use GraphQL makes me want to move on.

Anyhow, best wishes again on your launch!

~~~
mparis
Thank you for that note. I think there is a lot of room for improvement in our
messaging and we will take this to heart. I'm glad you were able to understand
the value prop from our description and you are exactly right that our core
value is rapid application development. We are solely focused on a building a
platform that is both easy to start and that is capable of growing with your
business. Thanks again.

~~~
le-mark
So many great questions and well wishes in this thread, allowing them to
explain and _market_ their product in detail. Am I alone in finding this
attention to be totally contrived? Other products are launched and get zero
attention. Or is it a benefit of being in the YC machine that you get so much
FREE support?

------
e1g
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.ht...](http://www.defstartup.org/2017/01/18/why-rethinkdb-failed.html)

~~~
vning93
Hi 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."

------
hiraki9
How did you find your first customers, and how did you get them to trust you
enough to build their apps on your infrastructure?

~~~
mparis
Hey that is a great question. Our very first customers were actually some of
our friends. We promised them free service for their trust which helped us
identify pain points and iterate before we initially launched last May. Since
then we have seen a lot of our users find us through tutorials and other
educational content that we've written. In terms of how we got users to trust
us, Slack has been an invaluable tool. We have a really friendly community of
developers that we speak to every day and I think that has gone a long way to
developing trust. It wasn't always smooth sailing and the platform has grown a
lot but we try to be as transparent as possible and address problems as soon
as they arise. We've dedicated a lot of time to building out our architecture,
security, and scalability and I'm happy to discuss that with those interested.
We are really passionate about what we are building and we hope that our
customers see that and can rest easy knowing that we are working around the
clock to make sure their applications run smoothly.

~~~
vning93
Feel free to join our Slack as well if you haven't already. You can invite
yourself here: [http://slack.scaphold.io/](http://slack.scaphold.io/)

------
williamtaormina
My team and I have a medium sized dev shop from Southern California. We've
been using Scaphold in production now for several months, and have been
absolutely blown away by how much more efficient we've become. All projects in
the pipeline will be using Scaphold going forward. Take my money.

~~~
vning93
Amazing! It's one of the most heartwarming things to hear someone like
yourself talk about how Scaphold truly helps you in your job with real
production workloads. And it sounds like many of them as well! Happy to chat
more with you on Slack about your future apps
([http://slack.scaphold.io](http://slack.scaphold.io))

------
bthornbury
Congrats! The website looks great!

Forgive me if I am simply uninitiated, but what are the general advantages of
graphQL over a typical backend powered by a SQL database?

~~~
mparis
Hey thats a great question! These things are actually not mutually exclusive.
You can think of GraphQL as REST 2.0. GraphQL provides a type system and
standardized query language that make it much easier to consume APIs from the
perspective of the client application. For example, the GraphQL language
itself is very powerful and essentially eliminates the need of SDKs making
GraphQL a great choice for any platform including embedded systems, VR, and
more. GraphQL does not make any assumptions about where your data lives
however. In fact, we run multiple databases (including SQL) each of which
serves a specific purpose and we are able to expose all them to you via
GraphQL. This is also how we are able to pull in things like Stripe, Algolia,
Push Notifications and more into the same API that powers the rest of your
application.

One of the biggest promises of GraphQL is in its ability to consolidate
disparate data and this I think is how we are going to stand out from the BaaS
platforms that have come before us. This is just the beginning. The GraphQL
type system opens up so many possibilities in the types of developer tools
that people can build. Apollo
([http://www.apollodata.com/](http://www.apollodata.com/)) is already building
amazing tools and expect to see more from many more companies.

------
orliesaurus
If you code while working for another company dont they own that IP? Unless
specifically stated on your employment contract? Just curious! Thanks

~~~
girthpigeon
not if you code outside of working hours with your own equipment

~~~
Communitivity
My apologies for contradicting you, but this is too simplistic an answer. The
answer depends on the laws in your state, whether it was coded on your own
time, whether it was coded with any resources of their company, whether ideas
in your product can be shown to possibly have come from the work you did for
the company, and what your NDA/employment letter/employee agreement states.
Unless you run that document by a lawyer and get specific set asides carved
out, they might very well be able to take you to court. Some states are really
good for you though, like CA. FWIW, I am not a lawyer, and this does not
constitute legal advice.

------
mfts0
The new website looks pretty cool but I wasn’t blown away by the product. The
API feels very weird when actually building an app and unfortunately most
integrations didn’t work for me.

We’ve tried all available GraphQL BaaS and now use Graphcool which doesn’t
have all the features Scaphold provides but the ones they have are very stable
and mature. Also their API seemed by far the best one we’ve tried yet (e.g.
they are providing an extra endpoint for Apollo client).

~~~
vning93
Those are great points you make and we'll take it to heart to assuage your
concerns. If I may ask, what in particular was weird about the API? We're
built to the Relay spec, which has become the open standard for GraphQL APIs.

To your point about the extra endpoint, I know they have different ones for
simple, Relay, files, and from what you're saying not Apollo Client. To me
personally, it seems a bit counterintuitive that they offer so many different
endpoints when one of the premises of GraphQL was to have a single endpoint
that was decoupled from the client. Open to your thoughts here to see how we
can improve your experience as a developer from the client perspective!

------
sapeien
I don't buy into the GraphQL hype. Actually it is a rehash of older
technologies like RDF & SparQL, but marketed to a newer generation who didn't
know that old things exist. I'd wager that the 20-something "engineers" who
designed it didn't give a shit about prior art either.

I'm sure that Facebook employees think it solves a lot of problems for them.
But I'm not convinced that a single vendor technology is going to be viable on
the web. Web standards come about through standardization processes, with
multiple stakeholders reviewing and revising drafts. Facebook one day puts up
the GraphQL spec out of nowhere and defines the "standard" by themselves,
based on their own implementation.

A little history: Facebook tried to subvert HTML with FBML, a proprietary
markup language designed for use within the Facebook ecosystem. Long story
short, it didn't work out. The various SDKs and APIs by Facebook have been
notoriously unstable.

People tend to excel at short-term thinking, kudos to Facebook for that, and
lack the foresight for long-term thinking, except for a few visionaries. The
architecture of the web has lasted a few decades already, it will outlast a
single vendor specification.

~~~
geoffschmidt
The GraphQL ecosystem has grown amazingly quickly over the last year. It's
definitely not a single-vendor technology at this point. Check out this list
of GraphQL libraries, tools, and implementations:
[https://github.com/chentsulin/awesome-
graphql](https://github.com/chentsulin/awesome-graphql)

The majority of people who are using GraphQL are using an implementation from
someone other than Facebook (on either the client or the server, or in many
cases both).

(And for what it's worth, I did see a "Why not RDF" slide in one of Lee
Byron's decks, and those of us at Meteor who are working on GraphQL are
definitely aware of the RDF/SparQL roots. I think what's driving GraphQL's
growth is, first, it addresses a very timely problem - fetching all of the
data for a screen in a mobile app in a single round trip without coupling your
backend to your UI - and second, the focus on tooling and developer experience
which has been a weakness for SparQL.)

~~~
sapeien
I didn't say that Facebook's reference implementation is the only one (it is
in fact the most popular based on downloads), everyone else is performing free
labor for Facebook. The point is that they can make any change they want to
the spec for themselves and imposing their will, bypassing standards processes
because there are none.

>fetching all of the data for a screen in a mobile app in a single round trip
without coupling your backend to your UI - and second, the focus on tooling
and developer experience

There is no reason why one can't do this with existing web technologies as an
additional feature. There was no reason to ignore what already exists and
works for the web at large.

I think you should disclose that you are founder of Meteor and have a vested
interest in GraphQL. So when is the Facebook acquisition?

~~~
ruslan_talpa
While I also have a vested interest in GraphQL (competing in the same space as
Scaphold) I agree partially with what you stated above but it's not all that
bad as you seem to imply.

Yes, FB does have the power (now) to change the spec over night but so far it
was mostly stable and whatever changes were added were only for the better. No
new technology comes to life as a standard, it needs someone inventing it,
maintaining it, promoting it up to the point where people can get behind it
and form a group and make it a standard. Let's give FB a chance, so far it has
done an excellent job with the GraphQL standard. On the other hand, graphql-js
and Relay are not that stable yet and their interfaces are changing very fast
and probably for people that use them it's a bit frustrating but it's only
been a year and i bet they will get to a stable interface in 2017 enough for
people to be able to really depend on them.

>There was no reason to ignore what already exists and works for the web at
large.

GraphQL came to life (and a lot of people adopted it practically over night)
precisely because the things that "already existed" did not work really well
(REST for SPA/Mobile). When a lot of your business logic (whatever that means
:)) moves to the frontend (browser/mobile), the backend API tend to become
very complex in order to support the frontend and REST can not express very
well that complexity. Whenever people "sell/promote" GraphQL, they bring up 2
main benefits, fetching the data you need in a single request and integrating
multiple backends/microservices. If you look at GraphQL only form this
perspective i would agree with you that it brings nothing radically new to the
table. You can have a REST api flexible enough to be able to get only the data
you need in one request (see [http://postgrest.com](http://postgrest.com)) and
you can integrate multiple microservices behind it, we've also seen in the
past "typed" schemas (WSDL and things like that).

Imo what makes GraphQL so nice is the the simplicity (Rich Hickey's
definition), how you immediately get what a query does, how it relates to JSON
and the shape of the response you get back. Making something "simple" is very
hard work and i think FB nailed it.

------
nodesocket
Congratulations on launching Scaphold. I tried my hand at founding a Node.js
PaaS startup (NodeSocket)[1] in 2011, and while promising in terms of
attention, silicon valley media, VC meetings, there was never a path to a
sustainable PaaS business. Howerver, things have changed. Technology and
mindsets have evolved, and Firebase, Parse, and Serverless.com have shown
there is perhaps a future in BaaS.

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!

[1]
[http://venturebeat.com/2011/08/10/nodesocket/](http://venturebeat.com/2011/08/10/nodesocket/)

~~~
mparis
Thanks for those words of advice! We'd love to talk more about this and hear
more about your experience with nodesocket. If you're interested please feel
free to email me at michael@scaphold.io and we can setup a call!

------
chacham15
How do you solve the problem of different clients needing different
permissions (i.e. one user shouldnt be able to query for a different users
data)? Took a quick look through the website and didnt see anything about
that, sorry if I missed it. That aside, it looks pretty cool! Good job!

~~~
vning93
Great question. We have a variety of ways to implement permissioning. You can
get pretty granular with how you wish to implement your rules whether they be
role-based or relational. Feel free to poke around our docs here to learn more
about the use cases for each with examples:
[https://scaphold.io/docs/#permissions-
authorization](https://scaphold.io/docs/#permissions-authorization)

------
bahramb
This is exactly what I've been looking for to backend some of my projects -
awesome service guys!

~~~
vning93
Thanks! Really appreciate the support. Feel free to test drive the service and
let us know what you think.

------
djmashko2
Congrats on the launch, the new website looks really nice!

I think the focus on integrating with a variety of services really plays to
the strengths of GraphQL, and addresses some of the concerns people usually
have with backend as a service platforms!

~~~
vning93
Thanks for the support! Agree with your sentiment, we talked to many users
about how best they like to extend their API, and found that the modular
approach was best for popular services like Stripe, Auth0, and so on. And for
the rest of the custom workflows, we've provided the ability to extend your
API with your own custom logic through synchronous and asynchronous hooks that
can call out to any web service that you may have hosted anywhere, whether it
be on AWS Lambda, Azure Functions, Webtask, or even self-hosted. If you're in
the portal, you can check it out under the "Logic" tab.

------
Jmetz1
I spent some time with the founders and they are really great. Without parse
and google owning fire base they way has been paved for a new IAAS/PAAS. I
hope Michael and Vince can lead the way.

~~~
vning93
Thanks for the support! Really appreciate it. It's an amazing time to be in
this space right now with all the opportunities and directions to take the
product.

------
kohanz
This looks really interesting. Thanks for sharing! I checked out the Projects
page, but they look mostly like tutorial or hackathon types - is anyone
running scaffold.io in production?

~~~
mparis
Hey! Yes we have an number of larger production apps on the platform. We
actually power 4 National Geographic domains in Europe as well as some cool
new startups like [http://cheddr.com/](http://cheddr.com/). We are working on
getting more in depth customer profiles that will go on the community page
soon!

------
zdne
Big fan of what you are doing! But can you elaborate a bit on TAM? Isn't the
possible market too small?
[https://github.com/coffeemug/defstartup/blob/master/_posts/2...](https://github.com/coffeemug/defstartup/blob/master/_posts/2017-01-18-why-
rethinkdb-failed.md#what-about-the-cloud)

~~~
mrpoller
At a glance it does sound like a very small potential market which makes me
curious as to why YC would fund them. Perhaps there's a belief that the market
will grow as these tools lower the barriers to entry (facilitated by GraphQL)
for building applications?

~~~
vning93
The fast-growing cloud service market at large is one we're trying to tackle,
and you're correct in that GraphQL does indeed provide a lot of value in
helping us get there.

------
samblr
Have been trying BaaS lately - few questions.

What databases are supported - like can I use oracle database with Scaphold.

Is there support for websockets.

Why Scaphold ? I see there are many companies in this space since last few
years - what unique selling points will help a customer choose Scaphold.

Dont you think rise of PaaS will make BaaS redundant easily going ahead. Since
BaaS is now a very small layer on top of PaaS.

~~~
vning93
Hey those are great questions. To answer them in list order:

1) You currently can't use Oracle DB with Scaphold. We have a hosted database
that comes along with each app right from the get-go.

2) There is support for websockets through GraphQL Subscriptions. Each new
type that you create in your schema will expose the ability to subscribe to
events of that type.

3) There are a bunch of PaaS services that exist out there, but the speed at
which you build apps on Scaphold is undoubtedly faster. We give you the
ability to think about your data in a modular way by appending large pieces of
functionality to your app without having to write any server-side code. But
you also get the flexibility to bind your custom logic to the same API through
your own hosted microservices. Out of any BaaS platform on the market, we
provide the most feature-rich platform that can actually help you launch into
production and scale to large workflows. So far we already have a few large
customers aboard and growing fast.

If you're interested to hear more about our feature set, I'd love to chat with
you more directly about your specific use cases and see how we can address
those. Feel free to join our Slack and PM me directly
([http://slack.scaphold.io](http://slack.scaphold.io)). I'm @vince

~~~
ruslan_talpa
Hi Vince

You said each app comes with a hosted DB, do developers get direct access to
this db or is it a big shared one? Are you planning on providing this direct
access in the future? Can you disclose the exact DB
(MySql/PostgreSQL/MongoDB)?

Congratulations on the launch, you are doing a good job education developers
in regard to this new way of building APIs which helps everyone competing in
this space (myself included) and the YC backing helps with credibility to this
domain. Keep up the good work.

~~~
vning93
Hi there, great questions. Developers currently do not get direct access to
this db, and we are thinking about ways to allow you to do so in some fashion
in the future.

The db that we use is Amazon Aurora MySQL db.

Thanks for the support!

------
koolba
Is the name pronounced "scaffold"?

Also, is this a special type of post to allow links in top level story
description? Regular Ask/Show posts don't get [http://](http://) links auto
formatted into links.

~~~
mparis
Yes the name is pronounced "scaffold" with the "ph" for GraphQL. When we first
started the project we liked the image of scaffolding going up around a
building. In our case the buildings were your apps and we wanted to create the
foundation upon which you build them.

------
josephcooney
I initially parsed the name as 'scaphoid', one of the carpal bones. I thought
they were making a joke about reducing typing...turns out I just can't read
properly.

~~~
mparis
We fight with the scaphoid bone on google every day ;). The name comes from
the original vision to build a foundation upon which others can rapidly build.
We saw the platform as a sort of scaffolding. One that helps you build your
application and then melts away so you can focus on what is valuable to your
customer.

------
stevens32
I was just looking for something like this, great timing!

~~~
mparis
Awesome! Let me know if there is anyway I can help!

------
koolba
I think the "Customer stories" section needs to be updated. The bio picture
and link for the Nat Geo reference points to Bonnier.

~~~
vning93
Thanks for the feedback. We didn't want to be misleading though since we
actually run several of Nat Geo's domains in Europe through Bonnier. They own
the licenses to them in that particular region. Here's a piece that explains
their relationship: [http://en.bonnierpublications.com/national-
geographic-0](http://en.bonnierpublications.com/national-geographic-0)

------
foolinaround
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?

~~~
mparis
One of the nice things about GraphQL is that it is the same everywhere. This
reduces vender lock-in significantly over previous BaaS platforms. We also
adhere our API to the relay spec so it will look familiar to most GraphQL
users. That is to say that if you grow so large that you want to move to a
self hosted solution then we can help you with that. of course you will lose
our admin features, integrations, analytics and logic but if you're building
it yourself things must be going well and we won't prevent you from growing!

------
bhenry92
Nice work. Excited to give it a spin in prod

~~~
vning93
Glad to hear it. Appreciate any and all feedback after you've checked it out!

------
roko1968
Have been following you guys for a while, really excited to see what's next
for Scaphold

~~~
vning93
Thanks for the support!

------
mrpoller
Congratulations on the new website and launch!

The new custom logic feature is looking great but what if I want to implement
a custom query or mutation that isn't necessarily tied to a `Node`?

For example, what if I wanted to add a query that ran a ranking algorithm and
returned a feed?

~~~
mparis
Hey thanks for the kind words! That is coming soon. You will be able to use
the same Logic infrastructure to create you own custom queries and mutations!

~~~
mrpoller
Thanks for the prompt reply! I'm currently refactoring our GraphQL API and if
you guys had this feature I would've gone off our infrastructure and used
Scaphold. Will definitely keep an eye out for when you guys add this.

------
arranf
Do you fancy an intern this Summer?

~~~
mparis
Hey! We're preparing to start hiring so very possibly! You can reach out to me
@michael on our slack (slack.scaphold.io) and I'll keep you in the loop!

------
przeor
when do you plan to start the referral program?

~~~
mparis
Referrals should already work. You can find them here:
[https://scaphold.io/referral](https://scaphold.io/referral). Let me know if
you have any problems.

------
bh13731
I've been using a similar service
[https://www.graph.cool](https://www.graph.cool) for a while and it's been
amazing. Good luck guys.

~~~
sorenbs
Thank’s for the support bh13731! If anybody has tried both Graphcool and
Scaphold I would love to se an objective comparison between the two services.

~~~
k__
The UI of graph.cool is a bit clunky.

But the generated Schema is nice if you don't use Relay.

------
dang
Edit: on reflection, I reversed this and put the original comment back
([https://news.ycombinator.com/item?id=13476120](https://news.ycombinator.com/item?id=13476120)).

I don't think it's in very good taste to promote your thing in someone else's
launch thread.

We detached this comment from
[https://news.ycombinator.com/item?id=13474424](https://news.ycombinator.com/item?id=13474424)
and marked it off-topic.

~~~
k__
I think it's bad taste to do this kind of moderation.

We want to get the best information from HN and not advertisements.

~~~
dang
On reflection, you're right—that was a mistake on my part. Sorry! I've put the
comment back.

------
tbirrell
"Launch HN"? That's new.

~~~
dang
Yes, it's something we're trying out for YC W17.

[https://news.ycombinator.com/item?id=13366964](https://news.ycombinator.com/item?id=13366964)
was the first one, and this is the second one, so far.

~~~
tptacek
So, it's preferential access to the front page in the same way as YC job ads,
but no special comment moderation?

~~~
dang
Yes, assuming I'm reading you correctly. We'll make it so there isn't a launch
post and a job ad on the front page at the same time, once I get time to write
some code—that way there won't be any more slots reserved for YC than before
(i.e. one at a time). Since launches are more broadly interesting than job
ads, this feels like a win-win.

They'll still have voting and commenting like regular stories.

Edit (2020): in the end, I didn't get around to writing that code and users
didn't turn out to mind the occasional case where a launch ad and a job ad are
on the front page at the same time. If it becomes an issue at some point, we
can still implement that bit.

~~~
tptacek
Yep this makes total sense. Thanks!

