I wrote my previous post about building a web app from my current mindset of a freelance developer. Although it worked for the information provided, it was missing some key points that would be helpful to those of you wanting to build a web application without prior experience in web design or development.
1. Do you know what the application should do?
People sometimes think it is a good idea to go to a developer and ask for ‘part of Facebook mixed with some YouTube and a little Wikipedia thrown in.’ You will want to put more effort into preparation than that unless you enjoy throwing wads of money at a project (as you will see in section 2).
To start, take the time to run through your desired application in your head. Write out the basic functionality you need, in a way that makes sense to you, and that will help you describe the concept to a developer.
Here is a very basic billiards tournament application as an example:
A Brief Description:
A single elimination tournament application that allows multiple tournaments to be entered into a system, players to sign up, tournament supervisors to keep track of wins and losses and visitors to see the current match-ups and standings
Access:
Tournament supervisors will be required to sign up for access to the core tournament functionality
Players will be required to sign up for access to the core player functionality
Visitors should be able to browse the site and tournament/player info without signing in
The Data:
Tournament supervisors will need a way to store and edit basic tournament info (date/location/cost)
Tournament supervisors will need a way to store and edit tournament wins and losses
Players will need a way to store and edit their profile information
Players will need a way to sign up for tournaments
The Visuals:
Each tournament will have a basic single-elimination chart showing who will move forward, as well as the date/time the match will be held
Each player will have stats for wins/losses on their profile
If you were to take the above breakdown to a developer, they would have a pretty good idea of what they were going to build and know that you have a good idea of what you really want.
2. How much is this going to cost?
The short answer: Custom Software is Not Cheap. Prepare to spend at least a few thousand for something simple, to upwards of hundreds of thousands and beyond for something huge.
The long answer: It depends on…
Urgency
Are you rushing to get this app out the door? If so, you will pay a premium for extra work-hours being pushed to your project over the others in the developer’s queue or for more developers being placed on your project
Language
The proper language for a given app is a topic worthy of a book, so I’ll keep this focused on the economic argument.
Does the software have to be built in a certain programming language? If you are sure that it does, this is a non-issue. If you are concerned about money, you better be sure. Building an application in a language like Java will take more than triple the time of building it in Ruby on Rails (what I program in – full disclosure) if both developers are qualified.
I prefer languages that allow clients to get their app out the door as inexpensively and quickly as possible. This will allow you to see if it is a viable application, and if/when it starts bringing in money or large quantities of users, you can always make changes to continuously improve performance.
Functionality
What does the application need? You should ask yourself that question throughout the planning process and during the building process. Developing the core functionality first and tacking on the extras as users request them, or as ways of trying to attract more users later is my preferred method. Adding flashy visuals/functionality (AJAX and Javascript) is a way to get a wow response from users, but I wouldn’t make everything extremely fancy from the start unless your wallet feels too full.
Estimates
Developers will occasionally give you estimates on each piece of functionality once you are in serious talks about the application. Remember that estimates are by no means a guarantee of how long it will actually take to build any given piece of functionality. If they give you a high/low range, budget for and expect the high and be pleasantly surprised if you receive the low.
Rates
Rates vary greatly depending on what you are looking for in a developer/designer. If you go to a development/design shop, you will almost assuredly pay more than for a freelancer. I have talked to people starting out that charge $20/hour, and I have seen companies charge rates as high as $240/hour (I’m sure someone out there charges more, I just haven’t seen it yet).
The rate is not a guarantee of quality. I have paid $40/hour for great design work and I’ve paid $90/hour for horrible development work.
3. How do I find a good shop or freelancer?
As with any service, the only way to really know if someone is good at what they do before you hire them is to get recommendations from people you trust who have used them.
Since that may be easier said than done, the main alternative I recommend is to find a freelancer or company with values you respect and a work style you like and get to know them for a while. If you have seen how they work with their other clients and feel like they would be a good fit for you, see if they’ll let you sign on for a one month part-time contract. Some shops or freelancers won’t work with you like this, but it never hurts to ask.
You can find groups of developers and designers to join and meet with. Sites like meetup.com and upcoming.yahoo.com can help you find events to expand your network.
4. What should I prepare for the developer(s)?
Once again, it depends. Do they prefer more of an agile style or more of a waterfall style? I prefer the agile approach, but I’ll include what you may run into for both.
Agile
My quick explanation of agile: it’s like the name says; you are able to adjust any time you want, developing and designing in bite sized iterations rather than locking in a course for the whole project before you have played with any of the functionality.
For a new build, an agile developer would most likely need a basic outline of each piece of functionality at the start of the project to get an idea of how everything interrelates. When they start building, you will need to be more granular for the piece they are working on. This helps ensure you get what you want as the project rolls forward, but you can easily change your mind on the future pieces of the project because you have not set them ahead of time.
From the earlier example:
In the beginning -
Tournament supervisors will be required to sign up for access to the core tournament functionality
A few days before work starts on this piece of functionality -
Supervisors will need to enter the following info during signup: Name, Address, Company…
Supervisors will need to be able to edit all signup info
Upon signup, supervisors will receive an email asking them to confirm their email address; the account will not be active until this is confirmed
Waterfall
My quick explanation of waterfall: you build a huge requirements document that shows how everything in the application is going to work and set the developers and designers in motion; they eventually return with the finished project.
For a new build, a full requirements document would need to be created to ensure no piece of functionality is left out of the final application. Every detail of the app would be in the document. Any changes to the document would have to be made ahead of time in order to ensure no stops in the workflow.
There is a spectrum of agile and waterfall, just like any work ideology. Some agile developers may be less agile than others, and some waterfall developers may follow a more rigid structure than others.
5. What should I prepare for the designer(s)?
Every designer will answer this question differently, much like developers would answer question 3 differently. I am more developer than designer, so I’ll keep this brief.
If you have an idea of the look and feel you want for the application, bring anything you can to help describe it to the designer. If there is a color scheme, font style, basic layout, or anything else you know you want in the app, make sure the designer has it when you meet. They may run through prototypes with you, do some simple sketches, or come up with a few different layouts/overarching designs for you to choose from.
A good designer will make your site look good. A great designer will make your site look good and work to ensure the end user will have an easy time using it.
I recommend having the designer work directly with the developer once the base functionality is created. This allows the designer full reign when it comes to moving around pieces of the page that contain code because the developer is there to help. It also makes it easy to perform quick modifications to the functionality to match the requirements of the design or vice versa.
6. What happens when the core functionality is finished?
The software is not necessarily complete when the initial development is finished. There may be issues that arise in either the design or the functionality that only appear with use. A page may look great with a small amount of data on it, but what happens when a user adds a ton of information? The page may look broken and require an adjustment to the design, or you may decide to put the data on multiple pages. Either way, if you liked the team that worked on your site initially, you may need to reenlist their services. If you didn’t, updates are a great time to try a new freelancer or company for a limited engagement.
The above is not meant to scare you away from following through with your goal of a web application (especially since I make a living building and modifying them) but it is always good to do research before making a major purchase.