exposing methods for the purpose of testing is bad design, whether or not you are only doing it in a test environment. if you have a method that is sufficiently complex and warrants its own testing, put it in it's own module file and test that module file on it's own - no need to break your design and modify your runtime module exports based on runtime environment checks
I'm serving files from Amazon S3. This gives me the benefit of world class storage and streaming, without having to own / run the servers myself. Bandwidth from them is "cheap" at $0.12/GB... but with an average podcast of 30 minutes being 25meg file, an episode with 1,000 downloads is 2.5GB of bandwidth.
i have a customer that averages 20,000 downloads per episode, and a bunch of others with close to 1,000 downloads per episode. it adds up fast.
Right, but if you go with a "budget" dedicated supplier of dedicated servers for cheap (probably based out of EU such as Hetzner/OVH) or out of the US (through someone who provides "unlimited" bandwidth), have everything through s3 as a backup incase the server has any issues, you will be able to save money.
25 meg downloads don't last very long, so the very worst is that your gigabit pipe gets caught for a bit - hell even a company like Linode does 2GB out for $160/m :).
S3 is very expensive for what you are doing, saying you don't need to own/run servers for things like a podcast is just pissing money into the wind.
"saying you don't need to own/run servers for things like a podcast is just pissing money into the wind." - that's probably true. i may end up doing something like your suggesting in the future. right now, the streaming side of things is not something i want to concern myself with. i have other things that need my attention.
linode's $160/mo plan would cover me for a while. i'm transfering around 4TB a month right now, and that would cover 16TB.
thanks for the feedback and suggestions! this is something i'll need to keep in mind in the near future.
This is strictly an opinion, but I think your pricing is way off.
The Pro account should be $9 or $10. You should move to dedicated server hosting, or to perhaps Linode, and drastically reduce your cost basis and dramatically improve your value proposition. 250mb of storage is nothing for $19 / month. The numbers just seem out of whack. Shouldn't customers easily be able to store a huge number of podcasts, given how cheap storage is? Store and forget. You want their content on your servers, all of it. For $99 / month I better get a terabyte of storage these days.
Slash your costs to the ground. Boost your value proposition to the sky. Dramatically increase how many podcasts customers can store on your service. You want them to stream your brains out, and you want it all to happen with bandwidth rates around $0.01 or $0.02 / gb.
With scale, and lots of usage, expand what services you offer to customers. Storage & streaming are commodities, so treat them accordingly, and instead focus on building a customer base with modest margins on the core, with an eye on what you can do with all those customers over time.
By going with the easy AWS solution, you're pinning yourself into a very tight corner on costs.
Also, while I 100% agree on lowering costs, I think the idea of lowering pricing is foolish. I don't think cutting price in half is going to more than double sales. In fact, with as small as his sales likely are, it's very likely that he could stand to double the lower end plans. Something more like $25/$50/$100 might be more appropriate.
Podcast hosting is a very small niche. It's not wordpress hosting where there are millions of potential sites. You're talking about potentially thousands of customers total in the marketplace. Now, even at 10% of 1,000 potential customers you're talking about 100 potential customers. At $9 a month that's $900 a month, which is not a lot frankly. At $25 a month you're at $2,500 a month which still isn't great but it's somewhat interesting and something you can at least reinvest in customer acquisition.
At even the top end plan $100/month is going to need 100 customers to get to $10,000 which is probably salary replacement level after taxes for one developer, depending on where they live. Realistically, if the average customer pays $20, that means you need 500 customers to get to the same outcome.
If the company gets 10 sales a month and has 0 churn it is going to take approximately 4+ years to get to 500 customers. Figuring on a reasonable churn rate, it's more like 5 or more years at $20/month to get to $10,000 a month.
Now, if you are starting a podcast hosting company on the side, do you want it to take you 5 years to get to income replacement? I wouldn't.
As a comparison, it took the fairly successful time tracking app freckle 5 years to get to approximately $38,000 MRR with much better pricing. I estimate they have around 500 customers based on their $79/mo. plan. http://unicornfree.com/2013/5-years-of-saas-growth-every-mon...
So, unless this guy becomes a lot better at running his app than other SAAS operators have historically been, it could take 5 years to get to 500 customers paying $20/month. And the outcome would be about 1/4 of the revenue of freckle.
The math behind lowering your price rarely works out in terms of getting you enough extra customers to cover the revenue/profit difference.
Without exploring what you do too deeply, is there a way for you to monetize the freemium/free trial accounts? Can you apply some advertising to them automatically unless/until they upgrade?
I know Cloud is appealing for the scaling side of things, but you could save a lot of money using dedicated servers from other providers. Something to consider anyway.
thanks! :) i totally get the need to move things in house, too. i'm pretty happy that i can get the right experience for my users without having to do that, at this point. IaaS is definitely amazing! "oh, i need more servers? (fiddles with a knob) DONE!" :D
definitely things that need to be considered - vendor lock in being the worst, IME. i'm less worried about API call integration, as i tend to isolate 3rd party APIs from my code... but that doesn't prevent all vendor lock-in.
for me, being able to focus on features is more important than these concerns, right now. i expect that over time i will take some of these tasks in and write the code myself, but at the moment i'm more concerned with feature growth.
My point is that even if you isolate 3rd party APIs from your code there might be things that can't be "translated". Obviously both EC2 and DigitalOcean give you the same basic product, virtualisation (the greatest common divisor), but the "quirks" each one of them have are the ones you should be exploiting to get maximum efficiency, and this is generally non-portable.
But yeah, I think SaaS is a great way to scaffold or MVP your ideas. You can have a hugely complex infrastructure up and running in just a few clicks, but I don't think it's a great long-term solution.
good points that need to be considered in building your startup! it's a balancing act, i think, and that balance will change over time. for me, with an early stage of my service, being able to focus on my system's features and functionality is more important than the performance and customization that i would get out of writing some of these services myself. i imagine that later on in the lifecycle of this system, i will remove some of the 3rd party services in favor of my own code. but right now, being able to get features done quickly is more important than the monthly subscription costs. i don't expect everyone's situation to be the same, but i think it's a good place to start when you are bootstrapping your own apps / services
http://lostechies.com/derickbailey/2014/01/03/semantics-modu...