Makes sense. I think outline the benefits besides support would go a long way. Break them out more granular so I understand what I am paying for.
+1 for HIPAA BAAs. I’d absolutely need one for switching over to Fly for my startup
I’m going to state my bias up front. I actually want to pay fly more than I do based on usage.
However, I’m going to advocate strongly for removing a BAA from being tethered to the enterprise plan.
I could give a myriad of reasons but I think the strongest argument is that the 21st Century Cures Act prohibition on information blocking and the rise of the SMART on FHIR app standard make indie dev or small startup SaaS development in the healthcare space viable in the next few years and we should encourage this by removing any disincentive to achieve HIPAA compliance for an MVP.
Happy to provide any additional context desired if this piques interest at fly.
Would be great to have a cheaper email support plan or pay-per-incident support for small projects.
AWS cheapest support plan is $29
Howdy folks! We’ve deployed paid plans. We’re still putting the signup flow through its paces before we announced them more broadly, but they’re available to you all now. Have a look here: Plan Pricing · Fly
@Fred_Turkington The Scale plan includes a BAA. If you subscribe to a scale plan, you can sign the BAA through our UI.
@kaygee right now, the HIPAA BAA is in the $499/mo scale plan. BAAs seem to correlate to higher intensity support, so I think that’s right (for now).
@Elder we’ll be improving support over the next 12-24 months. If it becomes possible to offer cheaper support while still keeping the responses high quality, we will. My experience with cheaper support options (AWS included) is that they’re not actually very good.
@kurt, I would never presume to know as much about your business as you do so I understand you probably have good reasons for linking BAA and increased support together. I can also hypothesize that meeting some of the Technical safeguards of the HIPAA security rule such as the Audit controls, training, or documentation retention periods might have significantly higher cost but I don’t think a BAA causes increased support in isolation.
I’d love the opportunity to plead my case if anyone at Fly is willing to discuss. I know you are all very busy but if you are open to a high bandwidth discussion I would be grateful.
I’m finding the desktop page very confusing compared to the mobile page.
I was trying to figure out how many resources were included in the Pro Plan (or even the differences between the plans) as outlined in your very original post.
The mobile view nailed it. The desktop view had a many examples which made me go to the pricing page and try to figure out what was included. I clicked on the “learn more” button on pro which skipped over the feature comparison table completely. That table is below the fold, so there’s no hint it is even there.
Just some questions (using Scale plan):
- Is the new proxy timeout automatically applied to all apps or do we have to submit a support request for each app?
- For the builders, does it mean 10 concurrent builders of 8 CPU each, or a builder with 8 CPU that can run 10 concurrent builds on the same builder?
- Are the build minutes capped or is there an overage pricing?
- Is the included resources usage shared with the builders?
- Is the included resources usage visible in the dashboard somewhere?
- What is the guaranteed response times for normal support and emergency support?
- How do you differentiate between normal support and emergency support? e.g. different email address, keyword in email topic, etc
- The proxy timeout is not applied automatically. We need to set this for you, just send an email and we’ll get it going.
- Builders are just beefier. We haven’t implemented the concurrency limits within them yet. More concurrency means “more CPUs” right now.
- There will be build minute overage pricing at some point.
- Included resource usage is just a $ amount right now. That will apply to builders, too, when we start charging for overages
- Resource usage is not quite visible in the dashboard, no. You can look at the billing view and make an estimate. We have to build a new billing system to make this more useful.
- Premium support is a 24h response time. We have not shipped emergency support for these two plans.
- See above, if we ship emergency support you’ll have a separate email address to use, or a form in our UI.
@kaygee I wasn’t suggesting that the BAA creates more support load. The customers who ask for the BAA have increased support demands. Does that make sense?
Realistically, we’re charging $250/mo for the plan that includes the BAA and also requiring a minimum $250/mo usage commitment. It’s not very expensive! It’s designed to be a thing people add on at the last possible second.
Is there a class of indie healthcare product I’m thinking about that won’t make money? I would guess most of them will make more than that on day 0.
I’m sure you’ve heard it before, but emergency support sounds super appealing. Maybe you can make it work as a fixed price, but I do recall having remote-hands being billed per call/hour at some places.
While it’s not a major for us as we’ve had great ongoing service for the past 1.5 years, I would suggest updating your Plan Pricing page to indicate that emergency support is not yet available as you are advertising it as available as part of your Scale and Enterprise plans with guaranteed response times and customers can purchase Scale plans immediately.
Oh maybe I’m wrong. I’ll get this clarified today.
@kurt Thanks for taking the time to reply.
I understand that most customers that require BAA will be venture backed businesses or larger companies because healthcare, and by association healthcare tech, is so expensive. An indie healthcare product is not like an indie Mac app because you get what you incentivize. I personally dislike this but I understand it.
By that yardstick the pricing tier is extremely cheap, no doubt. And companies of the size necessary to enter the healthcare tech market will create more support load. They probably won’t stop yammering about ISO-27001. I don’t begrudge them that, and I don’t begrudge you the opportunity to serve those customers. They are demanding but lucrative.
However, there are apps that are custom to a practice. I am a physician and would love to build custom apps for my practice that are still HIPAA compliant because they deal with PHI. My wife runs a direct primary care practice by herself. I would love to build her a series of apps that have a user base of 2 people (physician and virtual assistant), but deal with the PHI of her patient panel. Those apps will never make money directly but they can reduce her expenses because cobbling together the infrastructure to run a direct primary care practice, though achievable in a way that was impossible even 10 years ago, is still not cheap. If you want a HIPAA compliant messaging system or other digital infrastructure you get gouged because no one in healthcare cares one whit about the cost outside of markets like direct primary care.
Not everything in healthcare has to make money. I say let a thousand apps bloom and focus on interoperability instead of oligopoly, but I still want those tiny apps, my apps, to be secure first and foremost, but also legally compliant. And I can’t do that, by the letter of the law, without a BAA.
There would never be a business case for even a suite of apps custom to a practice where the user base is two people if the hosting and infrastructure was $499/month, but I don’t expect your business to cater to my insignificant sliver of the market and my quixotic quest to democratize healthcare tech infrastructure. Thanks again for not dismissing me out of hand. Maybe someday you’ll consider separating the support level from the BAA so I can have a BAA for my tiny, one-off apps, and you can get adequately compensated by the next VC backed healthcare startup out to “fix healthcare” and requiring an SLA from you.
I’m tracking this topic because I ran into a technical issue on fly.io’s side a few weeks back and community support doesn’t seem to solve anything (it hasn’t been fixed/debugged).
In no way do I have a problem paying for a support plan, but it bugs me that even for issues that seem to be on your side, there is no way (that I found) to get in touch with you.
Coupling support with a paid plan is fine, as long as it pertains to configuration tips, application related issues et cetera. As soon as there is a real issue that might be fly.io related, I guess there needs to be a “free” option to contact you. You could bill the customer if in the end it turns out that it was their fault.
I am hesitant to deploy more on fly knowing that things might break and there is no way to contact you without signing up for a paid plan. I feel like I’m already a paying customer (PPU). If your PPU rates are too low to offer technical support (in the sense of technical/fly.io issues), maybe you should increase those rates.
I’m currently spending a few thousand a month on hosting with other providers, so it’s not that I don’t want to spend the $99/month, but the simple thought that that’s what it takes to get technical issues solved, is upsetting.
That’s fair, and I’ve definitely felt the same way when I’ve spent money places. You’re stuck in a weird tweener spot that we can’t handle very well yet.
Right now, we can’t keep up with support outside of paid plans. It’s not that we don’t want to, it’s more that we’re 10x bigger than we were 6 months ago and it takes time to build a support function.
It’s not exactly a money problem, we’re a very new company doing very new things. Building out support is a blend of documentation that we’re behind on and hiring subject matter experts that only happens so fast.
High quality support for paid plans is something we can do right now. For organizations that need it, I think the pricing is low enough to make that ok. I understand the hesitation, though, so it’s possible we’re just not a mature enough company for what you need.