Most businesses outside major corporations didn't start commissioning custom software until the rise of the commercial use of the internet in the late '90s, when all kinds of small and medium sized businesses wanted their own website. Websites were relatively simple back then, and the people willing and able to make them cheap. Hell, even though I was already a professional programmer for years, back in 1994 the idea that someone would pay a few hundred bucks me to make a "homepage" was just cool enough in itself.
Websites became more complicated applications, no longer something hobbyists could do on the side, and became more diverse, including apps for specific platforms like iOS. The cost of having an online presence has multiplied many times in less than a decade because of the sheer amount of work involved, and the level of professionalism required these days.
But most businesses don't commission software ever few months, or even every few years. So every time they want a new app, or a refresh of their website, they are suddenly faced with a shockingly high price tag compared to the last time they wanted something similar (or at least similar from their perspective).
And we're only just getting started. The shortage of decent developers has only begun to translate itself into higher costs. Most employers are still rather conservative in the current economic climate, and developers are notoriously bad at selling themselves.
The second being many times custom development shops don't weigh customer needs with COTS. For example in our shop we many times have customers that come in looking for a web presence. When we analyze their needs, it is apparent that Wordpress and a template will fit the bill and get them to market the quickest. I am not a huge fan of PHP on a personal level, but if Wordpress fits the bill I would be doing my client a disservice to not steer them down that path. I think for quite a few custom development shops everything looks like a custom development problem. I think if they would take the time to learn some of the cheaper solutions that will work for lower budget clients, then they can offer a product portfolio that matches the budgets of the client.
Plus, these often turn out to be not particularly desirable clients that take up a lot of time, and there isn't sufficient margin on simple WordPress jobs to give such clients the same amount of attention as on major custom projects. It's very hard to make these clients happy with off-the-shelf solutions yet still make a bit of profit.
COTS helps, but it doesn't cover the gap between client expectations and reality. It's more of a "better-than-nothing" solution.
And don't even get me started on the cost of maintenance and upgrades. You don't want to have a few dozen outdated leaky WordPress sites in your portfolio, let alone a hacked site associated with your name.
Even friends and family of mine will still ask me, "can you come over and fix our computer?" It sounds like a simple request -- partially driven be a general phobia of trying things out themselves -- but it's really not okay. I'm really busy. Maybe I can do something that they can't, but they could also pay someone to do it. Unfortunately, they usually think the price is "too high;" however, if I asked them to come over and mow my lawn because I think the landscaper's price is too high, they would obviously balk.
I'm not sure what the solution is, except you shouldn't low ball -- ever. For a while, I thought I had found the answer by immediately saying something like, "I expect $120 per hour on this software project." I thought it filtered out a lot of clients who didn't "get" that I was doing something valuable...
...then I realized they then try to manage the price by claiming -- ignorantly -- that their requirements do not justify X hours.
I've been a Cocoa/iOS and web developer for the better part of the last decade, and what you mentioned is one of the biggest reasons I started my company, Blueprint (http://www.blueprint.io). It's an online tool for building native iPhone Apps - no programming necessary - and it is able to neatly sidestep most of the process of redevelopment and republishing to the App Store that people have to go through when they want to release an App.
1) how much did it cost other people to build similar apps (comparative analysis) 2) that you are able to build the product successfully (reducing technical risk) 3) that the price is low enough that the estimated Rev will produce a return (ROI)
- If you can present those points clearly you will be in a much better position to make more money with less frustration
If you think of development as using technology to scale down cost or scale up revenues there is plenty you can add as a developer to the ROI discussion.
And yes, building iOS apps is still hard and time consuming compared to webapps, business owners should know that:)
_____________
I am seeking a telephony app. builder that can deliver a PhoneGap lie ( non-native) inexpensive app. for a telephony project.
pay is:
$350 + 1% equity stake in a newly formed Delaware Corp. and 2.5% on all residuals. possible board seat (future paid projects)
if you can deliver an additional investor, you can get 5% of the transaction on the capital raised through you contact.
http://nationaljobs.washingtonpost.com/a/all-jobs/list/q-fre...
http://www.youtube.com/watch?v=dQx_pJyyyxc
"Unpaid iPad Intern wanted to build a facebook killer."
Emphasis on "phony"
First, too many stories along the lines of "I built this app for $1,000 in India and it is making me $50K per month".
Second, kids who don't know how to value their time who'll work like slaves for $2,000.
Third, bad programmers who deliver product cheaply enough, however, the underlying code is an absolute mess. They charge nothing, throw it together and move on.
Fourth, people tend to come up with an idea of what it is that they want to pay for something and try to fit that something to that number. When it comes to software that's like the square-peg -> round-hole problem. I've been to countless meetings where the other side says things like "We'd like to do this for no more than $10K" ... and then they describe an intense six-month, four-person job.
You can always try to educate. Sometimes that works. It can be painful. What you don't want to do is be the educator and have someone else walk away with the work for less (even if it is 1%) than what you would charge. So, don't invest any time unless you know that there's a really good probability of getting the deal.
Same thing I think happens with programming. "I have this idea, and I know (somehow) that $500 is a fair price, in spite of the fact that they are neither technical people or... ever commissioned custom development before".
So, it's not just software development...
That's not always the case - if you manage to work $2000 /8h/day/month in my country , you're already being paid in the top .. 10% programmers.
Money has a different value based on location.
If you have to outsource the entire cost of development, and you want a good looking, well functioning app, it's very expensive. And then there are the inevitable upgrades, improvements etc.
What was the cost of having the art assets and server side functionality done in house?
Adding that to the $15k seems to be the actual cost of the app.
Also how much time was spent designing the app before art assets were made or server side programming started?
I did the server side work, my co-founder did the artwork, both at a > 0 opportunity cost I'm sure.
We designed the app ourselves, again, at some non-zero opportunity cost.
The problem is that so much of what we buy is mass-produced that we forget just how expensive person-time is, especially creative person-time, since for most modern products this gets amortised over hundreds or thousands or millions of units. Even user-facing software has this issue, since the programmers do their work once and then the marginal cost of each additional copy is pennies or less. But custom work? There the cost is borne entirely by the one commissioning the work, and if it's an individual, or a small business or startup that has never had to purchase enterprise or custom software, they simply have no analogous experience, with software or anything else, of bearing the entire cost of everything.
"With websites, you can simply add one more page, then create a link to that page when you needed. However, you can’t do that with iOS app, everything has to be set in the beginning, any changes might result in significant other changes that you might not be able to understand why."
Isn't this what the Navigation Controller is for? You just push a view controller onto the stack, and pop it when you're done.
Regarding the UITabBar: "if you want colors icons instead of the blueish tint, the change in code is substantial!"
I have been using this method, which is not really complicated: http://sugartin.info/2011/07/01/customizing-tab-bar/
You need to make images for the bar in both orientations (if you need it). The only time-consumer is the "more" button, for which you'll have to create a custom UITableView -- and still not have the handy "edit" command to rearrange the tab bar buttons.
...unless this is the wrong method to use, in which case I would love to see an example of the right way to do it.
It still doesn't make sense as you can use tools such as Interface Builder. The only thing that applies, you could still be building the view programmatically or need custom animations. That needs coding. And of course a facebook button needs to handle things such as authentication than an emailing one does not.
About the UITabBar, you can always use the black one. Or use this little trick for greater effect which is less demanding on custom images: http://stackoverflow.com/questions/571028/changing-tint-back...
I also do apps for a living and it is true that business has unreasonable expectations on time and cost. Not to speak of the myriad of people that want a whatsapp clone for 500$
I was bitten by this on my first major contract iOS app, so I think I know what he means. Interface Builder will get you most of the way fairly quickly, which is deceptive.
Then you start refining to try and match the photoshop mock-up for visual design, and find the built-in UI classes don't handle this. Buttons not supporting labels below an image by default, or multiple buttons next to each other on the navigation bar, or a background that moves with a table view, etc. etc. [1]
You get to work on custom subclasses (or adapting some open source ones). Interface Builder doesn't let you set properties of custom views, so your view controller starts being filled up with all sorts of stuff that really should be in the nib file.
Then you find out that actually, various labels and text views need to support multiple lines of text. This messes up your beautiful layout from IB. Struts & Springs are now useless for half your screen elements, and you put custom layouting code in a custom container view's layoutSubviews method or your view controller just to push stuff down the screen and resize your scroll view's contentSize. The complexity of this layout code grows for every supported orientation and device type.
Your NIB files are now a mere shadow of their existance at the beginning of the project, so at this point, making a change to move some views to a different screen (is that only on iPhone/iTouch or iPad too?) is no longer a trivial exercise at all.
Yes, it's all manageable. But there's a whole range of sudden complexity bumps at "80% done" where the existing tools leave you stranded. If you originally quoted for functionality covered by IB but then need to customise it, that will take a lot of time, and you'd better have budgeted for it.
[1] The situation has improved somewhat with iOS5, which makes supporting iOS4 (let alone 3) devices the IE of iOS development.
Enterprises want to move fast, if they can, but they can't because of the mistakes they've done in the past were covered with more processes to make sure that 1) it didn't happen again and 2) if it happened, we can blame the process.
Sometime engineers don't understand 2 facts:
1) You will get fired if you made mistakes
2) You will make mistakes
So people tend to hide and blame "processes" to avoid firing.
CEOs are cold blooded firing squad. Just like "Businesses". What matters are profits.
Business people will wear a very thick layer of skin and try to pull unimaginably stupid statements to push the price down ranging from "I thought Facebook was done in a weekend" to "It shouldn't take a day or two to fix a 'simple' Database issue. You just go there and change the data"
I have heard stories of how very large financial institutions never ever delete a database column from a table, they just keep adding columns. They will not delete a data column for the very real fear that mission critical applications will stop working properly or fail silently.
On the other hand, think of what you could accomplish with a weekend of work in 1992 and compare that to 2012. Our abilities as developers/designers/etc are vastly improved due to improved infrastructure, tools, communications, resources, etc.
You could build a distributed photo hosting and viewing application back in 1992. But you'd probably be writing it in C++ and it might take you a long time to get something that even works, much less looks reasonably okay and attracts an audience.
Now in 2012, you could hack that together in a weekend. To make it a real project may take a few weeks or months, of course, but the pace at which we can build things is indeed speeding up.
You can now throw together a photo-hosting and viewing application in a couple of days. But that doesn't necessarily yield a site that runs itself. Teaching the customer to use the code still takes about the same amount of time. Editing the theme over and over again, iterating a design cycle that incorporates emails and meetings between you and the customer and the designer, still takes about the same amount of time. The process of moderating the uploaded photos to screen out the spam and porn still takes about the same amount of time. Usability testing still takes the same amount of time.
(And even in the enlightened year of 2012 there are still standard things that all sites could use, like proper reverse-proxy caching and solid backups, that over half the Wordpress blogs on earth seem to be lacking. Apparently we're not even done automating the things that could be automated.)
The other problem is that if the customer steps off the well-worn path they will fall into a very deep pit lined with invoices. If Wordpress does it out of the box, it's cheap. If Wordpress almost does it out of the box but it requires even the smallest amount of custom coding, it's expensive. And knowing what things are expensive and what are standard requires skills that customers don't have, so they have to pay a programmer to advise them, and that is itself inefficient and expensive...
There is 1992's distributed photo sharing app, built in ~5 minutes without any c++ and you had the whole rest of the weekend to get into flame wars about how ugly someone's cat was.
Sure you can get a lot more done now with advanced tools and infrastructure, but really expectations and requirements have grown much faster. You could definitely launch a median web or win32 app in '94 faster than you can now.
C is still necessary for a lot of people at scale.
In 1992 I could bang out some really effective CUI applications in no time at all. People really hadn't transitioned to Windows at that point. Now, I have to write a web app, or a mobile app, and it takes hours upon hours to learn the ins and outs of each new API, weeks to figure out how to customize the flashy UI to what the client wants, etc. So, yeah, programmer tools have gotten vastly better, but expectations and complexity have risen faster.
I think this is backwards. Programming is cheaper than ever. As outsourcing tools because better (vWorker is what I have experience with) this is only going to get better. Programmers have to realize that there are hungry, capable people around the world who can do much of what you can for far cheaper. I'm not taking anything away from anyone, but that's the reality of globalization. I've been able to get projects (mostly simple web development) done at less than half the price through outsourcing.
Which is a shame, but understandable. Why should the good Indian programmers work on the kind of projects people are willing to sell?
Consider a pickup truck. A “cheap” new truck in Canada is an amazingly high-quality product. It doesn’t fall apart while driving down the street, it doesn’t require hand cranking to run. You can put a load of plywood and your tools in the back and they don’t fall out on the highway.
When a businessperson says they want it cheap and fast and are prepared to cut some corners to get it, they mean cheap like a pickup truck is cheap, they do not mean buggy or difficult to use. As such, what you or I might call “crappy” software rarely meets a businessperson’s needs.
And that's the problem right there. The developer is not being paid to do that, they are paid to finish the app that was asked for as quickly and cheaply as possible, at least from the client's perspective. Of course they want a high quality app, but are not willing to pay the price, so most development ends up being shovelware. But it is work, just not the most glamorous work that one can dream of.
The iOS and Cocoa Touch APIs are really robust, and with libraries like RESTKit, it's not that big of a deal to whip up an app that works well. Indeed, I've done it a few times myself.
The problem is that no one is ever satisfied with the UI kit that Apple provides. Browsing Navigation views of Tables, and doing simple CRUD to a simple backend (e.g., Rails on Heroku), is a weekend project, IMO.
I think OP is really talking about how unrealistic people's expectations/requirements are – not how difficult it is to make a working iOS app.
A quick example, I implemented a very good looking custom badge system for an app. The result looked just liked design, could be generated programmatically, and worked like a charm. It also took me a couple of days to implement the whole thing in quartz. If I were doing this as consulting, that's a $2-3000 feature. These things add up very quickly, particularly if someone wants to "try a few out."
Tightly integrated code: With websites, you can simply add one more page, then create a link to that page when you needed. However, you can’t do that with iOS app, everything has to be set in the beginning, any changes might result in significant other changes that you might not be able to understand why. The way iOS codes are structured is like a breadboard, everything is hard-wired, you still can change a few things here and there, but if you change the wrong wire, the whole board might stop working. Even extremely well structured code does not increase the flexibility by a lot. Adding an additional email button to ‘About’ screen might only be worth a few more lines of code, but adding a Facebook Like button on the same page is a different story, don’t expect that to be done in a few hours.
> The way iOS codes are structured is like a breadboard, everything is hard-wired, you still can change a few things here and there, but if you change the wrong wire, the whole board might stop working
Seems very wrong. It sounds like something that someone that doesn't really understand Objective-C would write. It's a very dynamic language, using features like first-class classes should help prevent that C++-esque nightmare.
A Facebook like button is not a fair comparison at all. In a web app, you can just paste it in. If you had to implement the button yourself it would take just as long as implementing it from scratch on iOS.
Instead, consider a data type. If we're writing a Facebook clone, let's say we only have status messages and now we want to add photos. On the web, you'll need to write the template to generate HTML for that in the news feed. On iOS, you need to write a cell class. It's true that the iOS one will probably take longer, but that doesn't make it less flexible. It's just the nature of declaring your interface in code instead of in markup.
Take a list of things for example -- let's say a list of contacts. On the web that's probably a styled <ul>. On iOS, it's a UITableView.
So, let's say late in the game you're asked to sort contacts by first name, and put a little section indicator in for each letter.
On the web that's easy, sort the array, then as you're iterating over it and rendering, insert your section header when the first letter changes. If the list changes, ajax the changes in and use an id on each item to update. Done.
On iOS, first you'll need to set up a collation on your table view. Decompose your array of contacts into section arrays. For efficiency, you'll probably want to keep a pointer to that list. Change your section and row count delegates so they match the new structure. Now when you're rendering the cells, you'll need to locate the contact by section and row, and if a cell is tapped you'll need to change that too. If you support editing (delete, etc), there are several other places where you'll need to make similar changes. Speaking of which, what if the user deletes the last contact in a section? You can't delete the last row in a section without deleting the section as well, so you'll need to detect that and react appropriately. Can updates arrive while the list is displayed? You could just reload the whole list, but that will probably result in an annoying UI pause. Better to just update the cells that need to change, so you'll want to find each changed row in your collated lists and update it, being sure to watch for any sections you need to insert/delete...
...And on and on. None of this is rocket science, but the point is that there can be a lot of complexity behind a minor changes that someone with a web perspective would think of as trivial.
You could create your own layout engine, but most developers choose not to, especially since the consistency of iOS hardware means they can predict screen sizes easily. Your other option is to make your app a thin wrapper around a Webkit view, but that tends to produce poor results (see the Netflix iOS app for an example).
I'm not sure that is strictly true. The autoresize model[1] will cover a lot of cases. The place where it does break down, and where HTML does shine, is with variable sized data such as paragraphs of text. However, that is starting to encroach on document territory anyway – meaning you'll probably want to use something like UIWebView to display that data.
Anyway, not trying to point out the obvious. I've just noticed that not all iOS devs are even aware of the autoresize functionality, so I figured it was worth noting.
[1] http://developer.apple.com/library/mac/#documentation/Cocoa/...
I disagree. Yes, it's nice to have everything in hand when you start, but I've built multiple apps concurrently with the backend development. The trick is to isolate your networking in the model layer (a good practice regardless of whether or not the API is already done). This allows you to stub or use dummy data until things come online.
I'll go you one further. It's better to work without a functioning API. With stubs and dummies, you can tightly control inputs and test way more effectively. If you're developing against an active api, you add a whole level of complexity that makes it that much harder to debug. I don't know how many hours I've wasted trying to find bugs that turned out to be outside the scope of what I was working on.
WRONG. Mobile applications supplement existing solutions, which means they generally are a subset of features tailored to a handheld device. Enterprises generally don't adapt a lean methodology. For example they just assume that the current Facebook app you see today was birthed in a weekend...as Facebook itself was. Which, as we know all know here, is simply not true.
It's not their responsibility to know the market they're trying to consume; it's yours. Be prepared to quote market rates for varying levels of experience, and have examples to explain why your time is priced in whatever tier you consider yourself to be in.
Of course, the reality is usually exactly opposite.
I found out that it's not worth it to mingle with offline-small business. Their budget is usually $1,000-$2,000. That's barely enough to buy a stock template, a couple of plug-ins, setup WordPress and customize it a little.
The problem is not with small or medium businesses. You need businesses that works on the web. Their web presences is everything they are. They know how web dev. is hard and expensive and they also value it. Highly.
If you are a freelancer, find a few of them. Make a good relation. That's it. They'll make you a good salary.
For me, on average, the same type of UI / interaction in iOS takes about 3-5x more to develop versus web.
Like creating quality TV/Film content, crafting mobile applications takes time, talent, and money and one day this will be better understood by the mainstream.
The idea that you can whip up a very complex iPhone app "in a weekend or two" is naive and, dare I say, bubblethink.
(1) Big infrastructure needed: Seriously, if the client is not picky, you should be able to build a working basic infrastructure for the back end in a week. And that's generous.
(2) You need a way to communicate: The claim that there is no standard way to do it is just plain wrong. There is absolutely a standard way, its how everyone with a brain does it these days, and its easily supported through every device SDK - you use HTTP
(3) Design the API: No, design the app. Then determine what question it needs to ask the server, and figure out how to make the server answer them. Designing the API first is a very engineer thing to do - if you're the only user for the API its just a flat-out wrong approach
(4) Pay for it: Sure, but I'll pay for the amount of time it should take to do this. Which is a week. Engineers that want me to pay for them to sit and write 200 page requirements specifications need not apply. I want to work with the people that want to build something on day 1, and then keep tweaking it.
I judge books by their covers. In fact, I don't know anyone who doesn't outside of trying very hard to convince others they do not.
The layout of the blog draws my attention to your picture and subsequently your "download my resume" link. I clicked since I was interested in learning a little about the author, his background, and what may have caused him to write such an article.
As soon as that link opened, I knew I would not read the blog post because the resume layout rendered the content difficult to read. Why does that bother me so much? The answer is simple: it ruined your brand for me before I even had a positive impression. Right off the bat, I'd give 2 suggestions to clean up your resume a little:
1) Do something about the half bar headers you are using as it currently divides the page when viewed, this wouldn't be an issue if you actually had a 2 column design which lined up, but it doesn't.
2) Never and I mean NEVER use justified alignment unless you're publishing a newspaper.
Sorry if I seem a bit harsh, but being that you're fairly young and these are very simple mistakes to correct, I thought I'd point them out.
Best of luck!
The problem is that you are generalizing way too much. Does every app need to communicate with a server? Nope. In fact, you don't even need to host the app download or transaction as it's done for you via itunes.
Additionally, even if client / server communication is necessary, what's to say the server doesn't already exist? Who's to say there's currently no communication with the server through web clients? If that's the case, you simply have to implement or expand the current interface...
Summary: Don't generalize....
Hard way to learn to value my own work more.
For example, my company focuses on building media-based apps. We have a platform and internal SDK that allows us to build these apps quickly and afford-ably (and not just on iOS -- we can release simultaneously on Android, Blackberry, WP7 and others too).
There are other services that make developing apps for mobile smartphones cheaper as well.
It's a fresh market and the consumers in this market don't know the options. Not every app is a unique, bespoke snowflake that requires a massive budget and a team of highly-specialized engineers. Once they do though I think we'll see a lot of these budgets come back down a bit.
Is there really enough money made from apps, to justify this cost?
it's just an 'if' statement
If it was malevolence, they'll refuse to budge and you'll know to run. Fast.
That's the price of a demo.
Once you start having to send data in the opposite direction and keep it in sync, however, you'll quickly find yourself spending far longer than 150 hours.
Agreed, if they're just consuming some data from a source and presenting it to the user through a very simple set of page views. But those types of apps have a very short shelf-life coupled with ever increasing competition as the different data sources become standardized and the app itself is nothing but a me-first attempt in the market. In other words, I won't need to download an app for each and every data set, just one good one that can feed them all.
But then what happens when I want that data to be multi-directional or actually useful to me, the consumer, as something I can store, manipulate and further share? You're no longer talking that simple app that someone slapped together for a nice $10K. And what happens when that data feed changes protocols or simply stops working? People delete your app and find something better.
If a low-level business type is looking to get their foot in the door with a quick app, then by all means, make hay while the sun is shining. Just keep in mind that the majority of your work will have been obsoleted in a relatively short timeframe and you may not have much to show for it a couple of years down the road.
As a bonus, wave both hands if some time late you hear said potential client has been screwed by said competitor, either by failing to deliver, delivering useless crap or ending up charging at least double that for "extra work".
