Next-generation Deploy Previews, plus Netlify acquires FeaturePeek (YC S19)
netlify.comA year or so ago I was working on a similar product as FeaturePeek - a platform agnostic deploy preview and collaboration tool. I decided not enough people would want that outside of their hosting platform and shelved it.
Clearly I was wrong and clearly why you should talk to more potential customers before you make decisions. Congrats to Netlify and FeaturePeek.
Given that this is an acquisition of a 2yo startup by a hosting platform company, looks like you were right on the money.
To be fair to yourself this is probably a lot more than a year's work, but also... just because it exists doesn't mean that another shouldn't version shouldn't exist either!
Unless you have inside information on the terms of the acquisition, I wouldn't beat yourself up about what might have been. There's a very broad spectrum of options here between "we like the team and have agreed to put them on payroll because it's cheaper and faster than using recruiters" to "F$%@ you money for the founders". We've no way to know which it is.
GitLab has a similar feature: https://docs.gitlab.com/ee/ci/review_apps/#visual-reviews
It does require a bit more work to set up (which is unfortunate, since they already use the URL could they use that to map back to the PR?) but seems basically the same if not quite as polished.
> but seems basically the same if not quite as polished.
That describes many of GitLab's features.
We're exploring how to reduce or remove this set up work with https://gitlab.com/gitlab-org/gitlab/-/issues/35322
Collaborative Deploy Previews are fully enabled on every Netlify account today! Anyone with a Netlify account can use the reviewer tool.
This is why I love Netlify.
They put together an incredibly powerful tool, and then released it to ALL of their customers. No, not a "Hey, we created this really cool tool! And for only an extra $3.99/mo you can utilize it!" I have several accounts, both free and paid and all of them have the Deploy Preview feature available.
There's so many things Netlify could've monetized and they haven't. They truly are a customer centric company - which is rare these days.
Eric here from FeaturePeek, we are thrilled to be part of Netlify!
Congratulations! Good work!
thank you!
What are you congratulating?
question if you will entertain it - what was your original YC pitch like? i'd love to see the evolution of this idea :)
Congratulations! Exciting news :)
This is awesome! I love that everyone can now give feedback. Developers, designers, people who write copy, etc.
And that the feedback is piped into a single source of truth: GitHub (of course, if you use GitHub). It's so easy to loose track of these things when they're not near the code.
> About five years ago, Netlify pioneered the concept of Deploy Previews.
Doesn’t Heroku’s “Review Apps” predates this?
https://blog.heroku.com/heroku_review_apps_beta
(funnily enough, it’s been exactly 6 years ago today based on the beta’s blog post above)
I think even Heroku is not the first company offering this to public. There was an app called Teatro.io which did the same in 2014. It's down now, but I've found https://web.archive.org/web/20140614011544/http://teatro.io/.
I remember using ephemeral Heroku deploys in the dev pipeline well before I knew Netlify was a thing. That was pretty much the last major innovation I saw from Heroku, before Salesforce decided they'd grown fat enough to milk.
But...there were also pipelines. A deploy preview is essentially a staging or pre-prod environment. Or going from draft to published.
There was a company called Runnable that had a product offering, but if I recall correctly was acquired by MuleSoft and shut down.
Their first round was in 2012, and even though I believe they had a different product originally, their preview environment offering predated Heroku’s.
They were in fairly wide "unofficial" customer usage for a year before that too I think.
source: my last day at Heroku was a year prior to that post, and I recall using them.
This replaces a multi-step manual process that we've been doing in our team. Well done!
I'm still optimistic for Python Netlify functions: https://answers.netlify.com/t/python-lambda-functions/3423/1...
If they were JavaSript only I wouldn't hold much hope, but they've been both JavaScript and Go for ages now - and I would expect Python to have a much larger user-base than Go for this.
If anyone is interested in a (semi!) working version of feature previews that is open source, I threw together https://gitlab.com/Rodeoclash/StageHand
It takes a branch in GitHub and use a config file to bootstrap the application inside a K8's cluster using a "docker in docker" model. If you could describe your infrastructure as a docker-compose.yml then you can launch it as a preview.
I'm not really a marketing person so it never went any further than a proof of concept. However, if someone is interested in working with it then I'm happy to support getting it running.
I can think of 101 ways this can help large teams become more productive
We have a deploy preview system at work and it is so valuable. I see less value in the collaboration tools built on top of these previews, but it’s cool nonetheless.
The first time I saw CloudFlare Pages do a preview it was a little magical. Really impressive stuff.
For preview URLs how are y'all handling SSO? No SSO provider supports wildcard redirect URIs. Looking for ideas...
Auth0 does, thankfully! I set my redirect uri to `https://deploy-preview-*--my-cool-netlify-app-staging.netlif...` just the other day. :)
They have a few rather specific rules about it, but it works for deploy previews anyway: https://auth0.com/docs/applications/wildcards-for-subdomains
Auth0 does, but IIRC it does not support multiple or not-last wildcards. Ie “app.*.preview.<domain>” does not work.
If your application itself has subdomains, Auth0 doesn’t solve this easily
I ran into this issue when setting up UI previews for a GitHub OAuth app.
My solution is to have a single callback server that looks in the OAuth state to determine where to redirect. This isn't secure, so when building the UI, I sign the UI's preview URL with a secret and send that in the OAuth state. The callback server checks the signature and redirects that way.
It's hacky and I wouldn't trust it for a production app, but for a test environment it seems okay.
Excellent idea, thanks!
This looks great and all but the new drawer icon covers up a key button on our app.. ironically the person who noticed took a regular screenshot and shared it in slack