This reads like yet another autocratic, micro-managing HR document. "Have a room with a door that shuts." Seriously?
How about this: hire smart people you trust, give them whatever tools and support they need to do their jobs most productively, then get out of the way.
Definitely. From a technical standpoint, it's Rails app on Heroku (using unicorn), using Sidekiq. I've got a ton of background with Rails and scaling on this platform, though not a lot with Sidekiq. I'm very excited about the possibilities with this though, and I've used redis quite a bit. On our backlog is to do some serious load testing. I'm also quite aware of the recent RapGenius/random routing stuff.
I'm planning to do a series of blog posts about how we built the site and some cool lessons we learned.
From a marketing perspective, the plan is to make an absolutely killer product that developers will enjoy using, and will tell anyone within earshot of it. We also have a couple of cool features that haven't been tried before with push notifications that I think will be intriguing enough to land us some general tech press. I don't have terribly specific scaling plans around marketing yet, as I don't want to put the cart before the horse (i.e. I want to prove there's a product-market fit first, then spend more effort on getting the word out.
Cool! We're going to be putting in coupon codes in a day or two. I'd be happy to give you an extended discount if you'd like to give us feedback on the service. Shoot us an email (info -at- pushlayer.com) and I'll hook you up.
That's great advice, and perhaps that's really the answer. Based on what I've been directly observing, most of the "marketing" that I do is pretty mechanical: A/B testing, posting updates to our existing users and soliciting feedback, adwords experimenting, and writing blog posts and other content.
In terms of prioritization, spending my time improving the product and offloading this mechanical work just seems like the right thing to do.
What I'm concerned about is that, as we work through the backlog of features, we also want to grow the users simultaneously. This will help us avoid a "bias of small numbers", in that our small group of initial users keep us focused most specifically on their needs, potentially taking us away from building features others might find compelling.
Hockeystick growth is for later, when we've achieved product-market fit. For now, I just want slow, linear growth to make sure we're consistently filling our backlog with compelling features that users actually want.
It's an API you use to send push notifications to iOS devices that have your app installed.
More specifically: it (a) makes debugging missing notifications easier, as it often feels like a notification just disappears into the ether, (b) it's priced based on actual usage, and (c) it saves you a ton of time from having to deal with Apple's APNS, which in my experience can get quite hairy.
Based on our split testing and other feedback, one of the next items on our list is to rewrite the about page. Thanks for the feedback!
I spent a lot of time trying to come up with a stable installation of EB for a Rails 3.2 app using RDS and just couldn't get it to a state where I'd ever deploy it as production. Here's where I decided to pull the plug:
Quite a few people still report a myriad of issues with Rails applications. I really want EB to work well with Rails, but just didn't have confidence in it.
Since we target iOS developers, do you think it would be too soon to start charging once they've released their app to the App Store (but leave the service completely free and unrestricted for as long as they are in development mode)? Or do you think we should be strictly resource-metered, in that they only need to pay once they've hit some level of activity?
I created a Programming Music playlist and started out with very mellow, non-lyrical music from Tycho. From there, I kept following the Related Artists feature (I'm using rdio) and added a number of other artists including Ulrich Schnauss, Isan, and others. It's taken some time, but I'm able to concentrate on my work without being distracted, while the music tends to keep me upbeat and focused.
The service is our attempt at making sending push notifications to iOS devices easier. The biggest complaint I've always had as an iOS developer is debugging notifications that don't go through. We've built the site to show every notification you send, along with a status and (soon) extended information from Apple.
A couple of questions:
1. Does the per-notification pricing make sense? I always felt something like "active device tokens" was confusing, whereas this is paying for actual usage.
2. Is the documentation clear enough to get started with?
This is our MVP. We're working on server-side libraries to make sending notifications easier along with further debugging tools. Thanks for any and all feedback!
So, what would a "small, sharp" monitoring tool look like that's compelling to customers? Just an agent, and the customer supplies their own notification and trend-reporting services?
Wondering what the HN community thought of a startup I'm working on. Tentatively I'm calling it DesignFiles.io, and it's a combination desktop and web app that lets designers check in/out projects they're working on. Designers can save comments with a revision and control access to their projects.
There are tons of so-called "digital asset management" tools out there that combine some form of versioning with reviews and other features, all of which are too heavyweight for many of the teams I've worked on. The sweetspot appears to be somewhere between Dropbox and these enterprise tools.
In terms of implementation, I have about half of the product built. The desktop app saves files to S3 (using temporary credentials via a token vending machine). The web app then monitors the usage. A client can have an unlimited number of projects and team members for a tiered monthly fee.
Exactly. I imagine this breaks down when you have a designer that prefers to work starting at 3pm, and a developer who's in at 7am. Do you allow the deadline to slip, or ask the designer to come in earlier (or the developer to stay later)?
I'm much more a fan of "core hours": i.e. a company that says everyone should plan to be available between, say, 12 - 2pm either in person or online. Then everyone can set their own hours around that.