First, it was Craigslist, next it's Zapier(kamerontanseli.ghost.io) |
First, it was Craigslist, next it's Zapier(kamerontanseli.ghost.io) |
"This is what we did at <linktomynewsaas>".
Is this what guerilla marketing and HN have become?
Heres a few I picked up from searching for "Zapier" and looking at the top related queries:
- zapier salesforce - airtable - trello - zapier email parser - calendly - sms
Craigslist is misspelled (there is an "s" in it).
Giving me a photo credit would be courteous as the author of that image. https://thegongshow.tumblr.com/post/345941486/the-spawn-of-c...
> One of my favorite business model suggestions for entrepreneurs is, find an old UNIX command that hasn't yet been implemented on the web, and fix that. talk and finger became ICQ, LISTSERV became Yahoo! Groups, ls became (the original) Yahoo!, find and grep became Google, rn became Bloglines, pine became Gmail, mount is becoming S3, and bash is becoming Yahoo! Pipes. I didn't get until tonight that Twitter is wall for the web. I love that.
— Marc Hedlund (2007)
https://web.archive.org/web/20070329031201/http://radar.orei...
Funny that he mentions Yahoo! Pipes, since that was sort of the same idea behind Zapier, et al., though (I guess) too far ahead of its time.
An alternate business model is to look at Yahoo product launches from 5-10 years ago, and build what they did but shut down, its time may have come. Google did this pretty well for a while. You can probably do it for Google now, too.
Yahoo! Pipes a strong argument for building your own tool/buying a paid product, in that if one relies too heavily on a service and it went away, then that [business] process went away as well. The demise of Pipes! caused us a bit of anxiety and made us hustle to find other solutions in a compressed time frame.
The rather quick demise of Yahoo! Groups was also disruptive. Heck, even Hacker News could have worked as a Yahoo! Group. Fortunately, it is not. When Groups went away, so did a lot of discussion groups and even when those groups moved, they lost many members. Groups.io is a nice alternative, but there too much of their platform is free.
There is always a danger when you build critical things on someone else's land, particularly if they allow you on their property for free. Even if they charge you but are not profitable, there is a risk of waking up to read that the service is closing.
We use Zapier in our small business, but work to build out tools for those Zaps! that become mission critical.
Here is a sample: https://benward.uk/blog/using-yahoo-pipes-to-feed-facebook
Not only is the UX more complex to get the job done, stuff like what we're doing (ex: personal->work calendar sync) is more complex than you think and simple "if this then that" types of workflows start to break down.
We have nothing against Zapier (heck I'm a user for some stuff). But there are definitely things it is ill-suited for, despite having an amazing marketing engine that can capture a very long tail of search terms due to the NxM nature of their product.
"Fun" fact: one of our users recently found us after screwing up his calendar sync Zap and, on a random Sunday morning, ended up inviting thousands of his coworkers to dozens of duplicate meetings, all from his personal Gmail account. It was his fault (his Zap had several errors in it), but in the end he was much better served by a dedicated solution.
I think the author's advice is spot on: there are opportunities in making better solutions for popular Zaps. Just please don't do anything in the calendar space ;)
It started out as a Medium post[2] describing how to set this up with Zapier. Seeing how much traffic it got even years after publishing it, I decided it was worth turning into a standalone service.
While the post helped me validate there was demand for such a service. I didn’t validate people were willing to pay for it. So user growth has been good [3], revenue not so much. (less than $1k MRR)
Something to keep in mind when you go this route. Be sure to validate people are willing to pay for a solution. Building something aimed at businesses is probably a good idea.
[2] https://medium.com/@marckohlbrugge/a-better-way-to-post-your...
https://developers.google.com/apps-script/reference/url-fetc...
[1] https://developers.google.com/apps-script/guides/services/qu...
Looking at the page again, I saw this, which I missed:
> Hi there! We're currently being verified by Google. So just click "Advanced" when signing up to continue :)
I tried clicking advanced, and yep, it wants access to all my spreadsheets =) I said no, but I don't want a google sheets to RSS converter right now anyway.
This is one advantage Zapier has over unbundled apps - I'm more likely to want to give Zapier permissions to my APIs because it's an established company and it can help with a bunch of different things, than to give access to a new single function tool.
That's the read-only scope that's required to query a single spreadsheet on the user's account. The API doesn't allow listing queries unless you also ask for drive permissions (which I don't).
See more info here: https://developers.google.com/sheets/api/guides/authorizing
Another way to go is to use a service account, and have the user share their sheet with your service account's email address.
Zapier is a great starting tool but quickly breaks down for anything more complex.
If you’re a SaaS app that has complex “use cases” then sending users to Zapier to have them figure it out doesn’t work. Instead, you can build your usecase on a tool like Integry.io (yes, founder here), embed the integration in your SaaS and have a clean UX.
Ultimately, you don’t want your users figuring out what triggers, actions, steps, mappings, transforms, validations are. People don’t buy integrations, they just want their tools to work together and tools like Zapier and tray can still be too complex.
I have to admit that a lot of times (especially when building side-projects/toy startups), I second guess myself when it comes to these kinds of product decisions -- "Is this product too simple? Too bare-bones; too much of a one-trick-pony? Would anyone pay for this?"
Eventually we want stuff that works, without looking at them.
On twitter people were asking what is clean code? My answer to that is that the cleanest code is the code you never have to open in an ide to figure or tweak.
Ignoring platforms like Salesforce, some of the "product" apps that we see adopting native integrations instead of directing users to Zapier include apps that require:
1) synchronous interactive integrations and not just background automation. e.g. a user pulling a lead from Salesforce into a marketing app.
2) complex/multi-step integrations that offer way better UX and much lower support costs to just build natively for users.
3) integrations as a competitive differentiator, or without requiring users to pay for third-party tools.
4) integrations without an API of their own to integrate to.
That said, there are always a long tail of apps and use cases so I'm certain we'll see more specialized tooling pop up to handle specific complex workflows.
AskReddit => Quora
MillionaireMakers => PoolTogether
Deals/Free/DiscountedProducts => SlickDeals, HotUKDeals
SideProject => Product Hunt
BuyForLife => goodcheapandfast.com
These are what I could remember top of my head. I'm sure there are others.
I think /r/mealtimevideos could be an independent service on its own.
This "unbundling" is the exact approach we're taking with Saasify. There's a lot to be said for focused, niche SaaS products that do one thing and do it well.
* alert threshold
* comparison operator
* expected datapoint interval (in units of time)
* whether to consider missing data breaching (boolean)
* if missing data is breaching, margin of skew allowed (in units of time)
(assume the tool magically has access to metric source, that’s not important)
I’m not sure whether the concept was named prior to this tool [0], but this tool’s name has become a colloquial term: a “Dead Man’s Snitch” style of alert. Once familiar with the idea, I found an exception-monitoring vendor [1] that I was already using at the time had built this feature in. I quickly found use cases and was broadly able to eliminate large volumes of “cronspam” and email filters in favor of the much more elegant construct — because it was so easy to implement and maintain, it was viable for a whole long tail of second class system metrics that otherwise didn’t deserve proper instrumentation.
CloudWatch on the other hand is lower level and more flexible (naturally with higher learning curve). It fundamentally provides similar value by offloading alerting state and logic to a trusted managed system, but is distinctly inferior for my use case:
* It treats missing metrics as literally breaching the threshold and makes no semantic distinction, which spikes the whole abstraction. You can (only partially) workaround this by splitting the alert into two distinct alerts.
* It doesn’t have a “permitted skew in units of time parameter”; you need to do the arithmetic and translate it into their parameters. This spikes the abstraction and makes the alert logic opaque to my team members and future self.
[0] https://deadmanssnitch.com/ [1] https://www.honeybadger.io/
However, as soon as you try to do more than couple of things in one zap and have multi zaps routing/transforming data between the same apps, it becomes very easy to fuck it all up (duplicate, trigger wrong things, etc) and Zappier (or other solutions like tray.io for that matter) doesn't provide you any help and the whole things becomes quickly difficult to maintain or manage.
A great analalogy would be it's a beautiful gun but makes it way too easy to shoot yourself in foot after the first shot
I'm looking for more unbundling and "micro apps" that solve the maintainability of it too.
Turn popular Zaps on Zapier into simple, single-purpose apps.
Disclaimer: I work for Tray.io
I wrote about this more in-depth here: https://docs.saasify.sh/#/resources?id=saas-idea-resources
CL is a consumer facing product that offers a good-enough experience for most categories. The category specific vertical companies mentioned greatly improve the experience / feature set. They are expansive by nature.
Zapier is a b2b tool that ties together systems / data sources and reduces it to a common interface for most scenarios. Being reductive and reusable is the chief value. I do not want another integration tool if I can help it.
Isn’t the point of the article that if one company provides a good enough experience for many things that doing one of those things better may be a good business opportunity? It may be particularly attractive to the subset of people who rely on that one thing.
The point doesn’t seem to be that you need more integration tools. It’s that if one integration is very important to you, you might want a dedicated tool that provides better experience and value.
Essentially Zapier would technically cover all integrations. So any sort of data transformation from one app to another.
Perhaps I'm human or crazy. I'm willing to be corrected.
> 31. Simplicity does not precede complexity, but follows it.
> 58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
All that said, I've definitely seen cases where trying to insulate the user from the reality of what's happening behind the scenes often dramatically increases complexity. When it's done poorly, in increases complexity not only for the designer and programmer, but the user as well. One well-known example is the progress bar. After 30 years of lying to users about how long that file copy, download, or compile would take, many recent designs simply exclude it and include an animated spinner instead.
In order for something to get clean, something else needs to get dirty.
I think taming complexity might be closer to getting something clean.
But I also think -- counter to the "conservation of complexity" thing -- you can get make a mess and get EVERYTHING dirty.
They go hand-in-hand as you reach the endgame. Once you’ve reached a level of irreducible complexity this law comes into play.
Maybe it only comes into play if you try to decrease over all complexity of a system. After a certain point complexity can't be reduced but can only be redistributed.
Once simplified, you still have the option to move the essential operations to one side of the equation or the other.
A program in 1985 likely wrote its own routines for memory management, math, graphics, and so on. Those add complexity. A program in 2020 almost certainly doesn't. The complexity is hidden behind nice interfaces, and more importantly, it's shared among 1000 different programs on my computer.
We traded inline complexity in 1000 places for complexity in <math.h>. That's not the fair trade that "conservation" implies.
Let's say you have some physics problems to solve. Doesn't knowing Maxwell's Equations decrease overall complexity? I don't think anyone would claim you should only learn first principles, and any other formulation only uselessly pushes the complexity around.
It is literally looking at json schemas and API specs and the connecting fields together. A date-time field is connected to another API's date-time.
{N} file(s) copied.
match N with
| 0 -> "No files copied"
| 1 -> "1 file copied"
| _ -> "{N} files copied"
My team at FAANG uses reclaim.ai pretty heavily to protect our calendars from corporate bs. We find it easy to maximize our time for working and being in the zone. Other FAANG or startup engineers would find this product useful to auto optimize their schedules. Especially if they find their calendars sprinkled with meetings with small gaps of free time in the day. I like to block off my afternoons as personal dev/work time.
Reclaim Assistant is free through January 2021, give it a shot. Reign in those Zoom calls that break your concentration throughout the day.
Definitely taking a serious look at Reclaim.
Everyone should block off 1-2 hours a day for themselves. Consistently blocking your entire day could slow down the organization, if meetings are a place for reaching consensus and decision-making.
Quite the opposite in fact: we built this for manager-types who have many meetings and for the very reason you cited need to appear available.
It purposely makes the slots of time that we book “free” until the day is too full, and only then changes it to busy.
The result is that my calendar, for example, appears free from 11am to 2pm, but if suddenly that time starts filling up, some time (30-60 mins by default) gets held for lunch.
In other words: it does exactly as you prescribe (blocks off 1-2 hours), except without the rigidity of fixed events, making it easier for people like you to call (hopefully good) meetings.
Give it a try!
KIDDING!! 100% spot on your analysis though and a real-world anecdote of the unbundling concept.
It's code that I now hate returning to because I don't understand it at first glance. (Granted this was years ago. I don't code that way anymore and haven't for quite some time).
I've learned my lesson.
Also, my day job, we may need to help schedule very busy surgeons.
If you're interested, please email me: alan AT_SYMBOL expertopinion PERIOD md
nohup yes >/dev/null
Google Reader I remember sold itself as being an "inbox for the web". I think Reddit and Facebook are the big competitors for that idea… not RSS clients. But maybe the time is right for a new take on that idea, one that works more closely like Reader.
The experience is even more frictionless than Amazon's, especially on a mobile device that supports mobile payments. With Apple Pay, the checkout process is literally just clicking the checkout button, then scanning your face/thumbprint, and done. No account creation, no credit card number is sent (token), address/email etc. are filled out transparently.
Kind of similar to the HotelTonight experience where you're able to book a hotel in less than 3 minutes.
Sorry I couldn't help it
https://blog.reclaim.ai/posts/2020-03-30-dear-hr-are-your-te...
The lunch use case animation might be a simpler way of conceptually explaining the product, just my 2 cents. Thanks for clarifying there.
Corner case: let's continue the idea of a flex lunch of 30 minutes between 11:30 and 2pm. If my work calendar has no events, and someone schedules a meeting from exactly 11:30 to 2pm, does it automatically reject? The person scheduling that meeting would've thought my schedule was free because the time was marked free, since the flex lunch time is only "claimed" once I'm down to 30 minutes of unscheduled time between 11:30 and 2pm.
My personal intent of blocking this 30 minute slot is never publicly visible on the work calendar, since it has no concept of that.
It sounds like Google Calendar (or whatever meeting software companies use) needs to build in these sort of features, since there's no way to do so. Reclaim helps, but if I'm booking my meeting within Google Calendar, and some of my meeting participants use Reclaim, I can't see the sorts of constraints participants are setting on their time.
Re: your other comments, you are right that the core platform (mostly dictated by the iCal standard) cause some of the limits on these workflows. But we designed Reclaim to do most (all?) of what you’d expect both for you (a Reclaim user) and others (non-Reclaim users who just stick on the core platform).
Try it out :)
Essentially, you are implying that enabling no-code integration with thousands of 3rd party services is easy.
Classic case of: https://danluu.com/sounds-easy/
APIs are unreliable. Schemas change with no warning. Data you expect might be missing and data you don’t expect might show up. You would be surprised how often things don’t work as you’d expect them to.
Zapier sounds like theyre maintaining these integrations so that they are tested and they work? That alone is a lot of work.
These days though, many more are maintained by the API providers themselves, since it benefits them to provide a no-code solution for their users to link their API to thousands of others - a service provider can only build and maintain so many direct integrations themselves. https://zapier.com/platform
If the API provider is already maintaining the integration, it's a matter of automation providers moving towards a standard for how to express integrations as the ecosystem matures.