Hacker News Reader

Comment by gte910h | Hacker News Reader

>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.

View on HN

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.

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!

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.

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

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.

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.

Reply on news.ycombinator.com