3 ms·
Love the idea, it was head-smackingly obvious when I saw your Show HN. Handling this is a PITA in an app and I’d much rather pay for a 3rd party service to hand
by kareemm 8y ago
Love the idea, it was head-smackingly obvious when I saw your Show HN. Handling this is a PITA in an app and I’d much rather pay for a 3rd party service to handle it.
Some feedback:
- the main benefit is that I don’t need to write or maintain code around storing, retrieving, and hopefully visualizing time series data
- pricing looks fine. Maybe even a little low for Business. But I’d have to try it out to understand if the usage thresholds are too high / low. May want to have a plan between 75 and 450 - that’s a big, painful jump
- May want to think about spending some time editing your copy so it’s crisper. A lot of it can be put into an eg FAQ (why not to use a temp email, for example).
- some examples in other languages would be useful (Ruby, Python, JS, etc)
- I like that I can create an account with just a curl POST. Good stuff.
- one concern is how fast is retrieval? If I’m retrieving data in a request thread I want it to be FAST. One factor here is server performance. If you’re using eg AWS to host that would give me some confidence that you can scale up beyond a hamster wheel if necessary
- no way to try this out on mobile, which is I suspect where a lot of people will first see this. How can you remind them to come back when they’re at a desktop? Collect an email and remind them maybe?
Haven’t tried the service yet but assuming it works as advertised it’s a good start.
Congratulations!
- rlonn 8y agoThis is fantastic feedback - thanks! The thresholds are pretty much guesswork - they're probably a bit off but I'll adjust them when I know more about how people use the service. One thing that might not be immediately obvious is the amount of data you can store at the different price points. The number of time series and the number of points per series go up, which means a lot more potential data storage each time you go up a level. More storage means more transfers, and so I set the levels and pricing based on worst-case calculations for AWS bandwidth usage costs. And yes, it's hosted on AWS at the moment. Virginia. It should be reasonable fast for US-based users, but if it turns out to be viable I might look at distributing it more. As for scalability it is designed to be scalable, but currently there is a bottleneck in the form of a lookup database that is hit for each request for timeseries data. If I add caching of those lookups, it should scale well horizontally - I just add more API servers and timeseries databases I'll definitely be adding code examples. Perhaps also documentation/howtos for interfacing via IFTTT, Zapier etc? Oh, and the copy etc - I wanted to minimize the number of pages, so I put all the most useful info on the front page :) I definitely agree that e.g. an FAQ section would be nice. Thanks again for some solid feedback!