Comment by dotBen | Hacker News Reader

Comment by dotBen | Hacker News Reader

Too many variables to be able to suggest a total rate (depends on how much work there is, in addition to the other factors listed).

You are probably looking at the equivalent of $100-200/hr for good development, with the higher end for people located in SF.

If you are going to out-source development, and you have a design/product background, I would build out a product spec and even a draft list of stories into Pivotal Tracker. It will help you define with your contractor what you want but also help to estimate total job time -- and that will help you arrive at a budget, based on the above hourly rate.

[If you don't have a design/product background (or are not a developer yourself) then the success of outsourced is probably going to be mixed]

I also tend to shy away from fixed bid because it doesn't work with an agile approach. You may not know completely what you want and as you get building and can get a better picture, being able to add extra components into the mix will cause friction with a fixed bid contract.

Better to agree a budget so that everyone is clear what the limits and goal posts are.

>I also tend to shy away from fixed bid because it doesn't work with an agile approach. You may not know completely what you want and as you get building and can get a better picture, being able to add extra components into the mix will cause friction with a fixed bid contract.

Fixed bid works just fine with an agile approach. You just start with a very small core project, then iterate upwards with follow on projects.

This is especially important for the Apple App Store because there is no other way to know if your app will be approved.

Fixed bid is sometimes more expensive due to the "risk eating" the developers are taking off your hands, but agility isn't usually the issue with developers who are otherwise good.

We counsel clients to start with a small fixed bid project then use hourly or follow on projects to change the program to a particular place they want to go.

I like this advice. Usually developers are wary of fixed-bid, because the client tends to want to tack on a bunch of "oh, and"s, and they end up spending a lot of hours working for free. People commissioning software, on the other hand, are worried about whether or not 0 to working prototype will take more hours than they are willing to pay for.

Your system seems to keep everyone in their comfort zone. No uncertainty for either party. (Except the usual, "will they pay my invoice?" and "why isn't he replying to my email!?" that is implicit in any business transaction.)

I talk a lot about how we do business here in my HN comments if you're more interested in the hows.

This is especially important for the Apple App Store because there is no other way to know if your app will be approved.

This is HUGE! Do you believe a company can flourish just as an App store app. or is that just too risky. Would love to hear your personal opinion.

I'm working on an enterprise solution, and it's reliance is completely on Apple's code-of-conduct.

I think if your whole business is based on one iPhone app, you are at high risk. Even if you get approved today, there is no guarantee that Apple doesn't change their mind tomorrow.

My email is in my profile if you want to talk.

The long and the short of it: You can flourish, but you can also get dragged along and then watch your app get shot like a dog after 6 months of being dragged through "maybe if you did this it would be okay" from the developer liaison people.

If you'd like, I can call one of them and go "Hey, is this in any shaky territory you can think off of the top of your head" if you want me to. I talk a lot about the environment in my HN comments if you want to read about it.

They're totally non-committal, but hey, they'll point out anything that sticks out.

Then again, we're starting android development here too.... :OD.

Check mail. Thanks!

If it's an enterprise solution, it doesn't have necessary have to go through App store, no?

The native functionality is tied into the form factor. thats the biggest advantage to having a native app.

In an ideal situation, i'll be giving out the iPad free, shipped with my App. already installed. the value proposition can be so huge that would offset the device cost.

Something like this would fit our slogan iPad was made for our X, all the other goodies are just extra :P

According to apple, that's a NO NO. As in, there was an implied threat of pulling the dev account of someone who did that when I asked for a discount on iPodTouches.

The enterprise solution is only for internal. The only other distribution channel is the App store. You're not allowed to distribute an app any other way.

Sure, you can give them the iPad, but Apple's lawyers will be on your back the second they found out about your practice. And as soon as they sync it to their own account, the app will disappear.

You could probably do your thing with ad-hoc distribution on the first 100 iPads. (Actually I think that probably violates the agreement. Don't do that.)

For the iPad in particular, there has to be a way for such apps to get on, or you're never going to see anything resembling enterprise adoption, so i'd expect this to change.

For the good of the discussion, you can only get an iPhone enterprise developer certificate if you have 500+ people in your company and a Dunn & Bradstreet number. Then getting a certificate is fairly easy. This allows you to, as others have said, distribute iPhone apps over a tether.

Yesterday in iPhone 4.0, Apple announced they were now enabling over-the-air install of in-house apps. My current understanding is that this relates to opening specific APIs relating to OTA apps. (full disclosure: I work for a company called Ondeego that delivers in-house iPhone app distribution as a service.)

1> This violates the agreement

2> The installs expire after 3 months (adhoc that is)

3> I think this model isn't going to get around apple. They're famous for defeating workarounds.

If you have an internal app that's only used by people who work for you, you can use the enterprise deployment kit to deploy internally.

This is designed for people who say, buy 100 ipads to replace clip boards in their hospital.

You cannot however, do distribution through any mechanism other than the app store (I had one perspective client who wanted to buy $30k of iPodTouches and give them out to clients, Apple flipped a shit when I asked for a discount on them and said you're wholly unallowed to do anything of the kind. Each person must download all their apps through their account on the app store. Anything else is forbidden.

So you are saying that if someone sells an app (which might be sold with minimal modifications to other hospitals) for the 100 ipads to a hospital as an enterprise solution (let's assume we can get the hospital to buy the iPad directly), the app still has to be put up on the App store? Doesn't that confuse the hell out for users that don't work in the hospital?

I develop iPhone apps selling on the app store, but have never explored the enterprise distribution side of it. With the iPad, it's becoming interesting.

Damn, I guess I need to move to San Francisco.

I don't have heaps of experience (a few apps in the store) but folks out here have balked at the $50-60/hour I've been charging.

A lot of people who aren't in tech will balk at hourly fees but not at fixed rates -- they like to know the total cost beforehand. Try drawing up a contract saying it will cost x dollars, up to y hours, and beyond that $z/hr.

2 tips: Learn to do fixed fee. Learn to do fixed fee and not get screwed.

Reply on news.ycombinator.com