Jake PetersStartup CEO, Developer, Marketer
Bio

Currently CEO at Contentacle (contentacle.com), a startup making content planning easier for inbound marketers.

Former CEO/CTO at multiple startups, specialising in development and inbound marketing.


Recent Answers


I've built a load of apps over the years and tried out many of the major providers. Currently I'm the CEO of a startup making advanced email technology, which is incredibly server intensive, so I feel I'm in a good position to advise!

I'm not sure from your question if you're looking to host the backend or frontend of your mobile app, but what I have to say applies to both really.

I'm going to assume that you're not a systems administrator, and have no desire to be, so I think that rules out self-hosting and colocation. That's when you buy servers to run yourself or rent server space in a shared facility. You'd need to spend a lot of time maintaining these servers, fixing bugs, etc. and it's basically a full time job.

Next up we have the option of renting space on shared servers. You can get instances on Amazon EC2 or Rackspace fairly cheaply, and you'll be able to start out with a default configuration that has an operating system loaded for you already. You'll still have to maintain these though, and the way I look at it, do you really want to be responsible for installing updates and 0-days on a server if you're at an important event, or in the middle of something? I sure don't.

Then we get down to PaaS (Platform as a Service) offerings like Amazon Elastic Beanstalk and Heroku. You'll rent small amounts of scalable space from them which you can increase or decrease at any time. So if you get a spike in traffic, you're covered. You'll get more transparent pricing, more support, and you're not responsible for updates and server maintenance. You get less control of the stack this way (for instance, it's more difficult to install custom packages) but it's far less admin than any of the previous options.

This is where I think you're at, and having used the two I think you'd be best off with Heroku. They have good and bad points (doesn't everyone) but I've been using them for some time now and haven't had any major problems. Deploying code is a couple of lines in a terminal - it's super easy. And maintenance is all taken care of for you.

Some companies have taken PaaS to the next level and just provide you with an API and a nice web interface to interact with them, like Parse. You can host Javascript on Parse, but not PHP, so it's not a good fit for you.

There's other cheaper options too, like shared hosting. As you're using PHP you could host on the majority of web hosts (1and1, Hostgator, etc.). This is a terrible idea, and you shouldn't do it. You'll hit memory limits and other nasties really quickly, and you'll not get the developer support you need.

There's a ton of other hosting companies out there that I didn't mention, and it's a massive topic. You'll also need to think about databases and storage, and who's going to manage the deployment of code.

I'd love to talk to you more about this. Schedule a call if you have any other questions, or if I can explain anything more thoroughly for you.


I've founded a few startups over the years, and as a glutton for punishment I'm doing it again now. I've not trademarked anything for any of them though, and here's why.

As you doubtless already know, startups are really hard. If you're just going into beta you will have more than enough work on your hands just managing your test, and when you do get free time you should be spending that on new tech and features for your site.

All this assumes that you're a small bootstrapping team of hackers of course. If you have enough time and money, it might be an avenue worth considering, but even then over 90% of startups fail, so you'll be trademarking something that might not even exist in 12 months.

At the end of the day your logo and name really don't matter as much as your product, which really doesn't matter as much as your passion. Focus on quality and traction and you'll build a successful business.

I'd be happy to schedule a call and talk more through it - just let me know.


We just finished a small beta with 200 people on TestFlight, so I'd be happy to share my experience! I've run 5 TestFlights now totalling many hundreds of users so I'm somewhat qualified to help you out.

My main advice here would be to roll out to users as slow as you can afford to, but obviously there's a load of factors to consider, notably how much testing you've done so far.

The issue with large scale rollouts is twofold. Firstly, there's a massive hit to your servers all at once, which could cause availability issues and highlight any bugs. Secondly, the more people you get involved early on the more people will SEE those availability problems and bugs. If you control the rollout you'll be able to see how your systems react to the increased load and scale accordingly.

That goes for platforms too. What's powering your iOS app? Do you have a web app? Secondary services that add on to your main platform? If there's anything that it's possible to hold off on offering, you should think about it. It's best to start out with something that's really great and reliable - you don't get a second chance at making a first impression.

Most of this stems from the rather uncomfortable truth that people don't actually understand what betas consist of. You're probably hoping for 100 people that really want to help you improve your product, but what you may actually have is 100 people that really want early access to something that's already finished.

It's best to manage their expectations up front. Just be clear about the feedback you're expecting, the level of contact you'll have, your update schedule, how you'll be communicating with them, how often, etc.

There's other factors to consider here too like the reliability of TestFlight (Apple are usually great, but TestFlight has its own unique issues with sending out invites and invalidating them). You'll also need to think about the drain that handling feedback will have on your team's ability to iterate quickly. It sounds like you're doing a great job at the moment, so you need to consider how much impact it will have dealing with support requests for non-technical issues.

I'd love to help you more. Sounds like you're working on a really interesting product, and betas are right in my area of expertise. Let me know if you'd like to schedule a call.


Contact on Clarity

$ 3.33/ min

N/A Rating
Schedule a Call

Send Message

Stats

3

Answers

0

Calls


Access Startup Experts

Connect with over 20,000 Startup Experts to answer your questions.

Learn More

Copyright © 2024 Startups.com LLC. All rights reserved.