StatusPage (YC S13) | San Francisco or Denver | Full-time | ONSITE
StatusPage is building a transparency layer for the internet. Our current product exists as hosted status pages for public facing SaaS companies and groups internal to companies (private status pages)
We're bootstrapped, profitable, and looking to grow the team with people that like learning from each other and take pride in their work.
Current positions:
- Development Lead
- Operations Lead (DevOps in flavor)
- Lead Designer
The risk profile as you seem to be thinking of it is an irrelevant metric when you're only interested in the return profile. They're optimizing for dollars returned, not % of companies sold for greater than money put in.
Consider a "soft landing" (VC gets their money back), vs complete death (VC gets no money back). When put alongside a $3B acquisition they're both completely irrelevant, even if on paper the 1x money back is not considered a "failure".
Check size doesn't appear to matter, the data for YC and for VC that I've seen suggests a similar power-law-ish distribution of returns.
Just looking at YCs returns, the vast majority of the wealth appears to be concentrated into 3 of 600+ starts (Dropbox, AirBnB, and Stripe). Even a Heroku sale for 200M+ is a drop in the bucket compared to $10B private market valuation, say it out loud and it will sound weird. "Dropbox is worth 50 Herokus"
Betting the farm implies that they have no other options, which is not the case with VCs, and it's impossible to know which will be their "super unicorns" when they write the checks, so they write lots of checks.
There's not much reason to believe YC is unlike other angel groups, individuals, or VC firms, and their data should back up that the majority of their returns is 1 or 2 companies every so often with huge wins.
once they're already a customer you're correct. the OP did mention the other major factor of a status page - a sales tool. prospective customers want to see incident history, who was affected, their response modes, metrics like uptime and latency are always good, etc.
This is 100% a tool problem, and a problem we're actively working on for customers of ours that plan on having thousands of customized "views" for what they normally consider a "status page". Per-user functionality is one use case, but it can and will go deeper than that. If they could post an incident such that only you can see it, or such that only you are notified, they most certainly would.
I disagree that posting everything to be globally viewable is the right course of action, as this outage doesn't necessarily implicate fault on DO as a provider, but it also doesn't mean that you as an individual customer shouldn't have access to your specific view of a status page as it relates to exactly what infrastructure you live on.
You'd be surprised how prevalent this issue is, and how much inaction it creates on the provider end.
your first characterization seems incorrect (did you read the story? it wasn't application errors), and your second characterization is hyperbolic at best. calling it a high-level constraint doesn't mean it's common, nor obvious.
calling them "terrible practices" is redundant, all devops horror stories can be characterized as exposing terrible practices if you're simply looking at the post-hoc view. it's a feature, not a bug, to make light of them. they're laughed about, but with the intent that they're not made again.
anecdotally, probably half and half. even personal connections can be slow and are super busy :). the other 10 were cold signups that surprised us, but enjoyed what we were doing.
This is a great writeup. Any time we can bring subconscious "gut feel" into the conscious is a win for everyone, and uncovering these kernels of truth has got to be enjoyable from a CEO standpoint.
Are you asking about us having an outage on our site, or you having an outage on your site? If the latter, you could definitely set up a redirect like the mentioned article to forward all of your traffic to your status page. We'll be doing a similar integration with Heroku for their maintenance and error pages.
Care to comment on your experience with larger code bases? The content of your post seems short-sighted, and there's an exponential function of complexity increase as LOC and developer headcount both go up.
You're right people pay for features, but lagging a little at the beginning to establish good TDD culture pays off in spades later on. Shipping product is something you have to do continuously, and you arguably create more value as time goes on, so ensuring you can continue to ship product in a timely manner is a great thing for organizations.
This doesn't solve any of the issues associated with PCI compliance.
Namely - you still have the liability, you still have the maintenance and upkeep of the system, you still have to pay for certification
The only thing it takes away from you is building the system which, on time and materials basis, is not even close to the real cost of maintaining a PCI compliant system.
on the contrary, i've had a coffee shop owner tell me to come and stay as long as i want for one simple reason. more people at a coffee shop is validation for the passers-by that have no context for the value of said coffee shop. lot of people being there is the only data point they'll get.
I believe the author just has a technical misunderstanding of the way APNS works. In no ways is APNS aware of accounts logged in or logged out of a service - all of this happens on the app developer's server backend. The author's case is properly laid out, but the fault is of the app developer rather than APNS. Developers should take note - this is indeed a valid race condition.
APNS is simply an exchange between a remote service (ex. Twitter) and an application that has registered for remote notifications (ex. Twitter app). APNS knows nothing more than the key that it provided to Twitter to identify this device in a remote push context.
This SOPA support was the straw that broke the camel's back.
Call this anecdotal if you will, but GoDaddy always occupied that "necessary evil" for domain registration in my brain. If others on HN are at all like me, they probably have > 75% of their registered domains sitting and doing nothing. GoDaddy's tasteless ads, horrible UX, shutdowns of domains due to "good faith" complaints...this was just the final incentive to call it quits. Predictably irrational, absolutely - guilty as charged.
https://captainzero.ai