Every once in a while, someone asks "what's your policy on <something or another>?" To be honest, we try not to have a lot of formal policy; our #1 goal is to run an honest business that provides excellent value to achieve maximum customer satisfaction, while earning a fair wage. In a nutshell, that's our policy. Or our philosophy. Or our guiding star, if you prefer.
However, since questions come up once in a while, a few items are formalized (if you can call it that) here. Some of these are questions clients have asked, some answer questions that it seems someone might ask. Our BIG policy is to always be honest and open with clients, even if the news is awkward or uncomfortable. If you have a question that isn't answered here, just ask; you'll likely get an honest & open answer. :)
We bill for time spent working
This includes meetings & phone consultation. Travel less than 100 miles is billed one-way as time. Travel over 100 miles is billed as travel time + expenses + minimum 9 hrs/day for all billable work + client time.
We charge what we feel is a fair rate for the senior level work that we do. Not often, but sometimes, we make mistakes. When this happens, we may decide not to bill you for that work and/or correcting it. While we're happy to hear your input -- especially if you feel you're not getting good value -- the final decision in these cases remains with Manyfriends.com.
The corollary is also true: if we're not working on your project, you won't be billed for that time. I.e., If we have to email you a question about how you want a certain feature, you're not paying us to sit around waiting for the answer. Likely we'll work on some other part of your project or, perhaps, another client's project.
Discretionary non-billed time
In this business, time is money. Often, quick email replies happen off the clock. This is entirely discretionary and done as a good-will gesture; please be courteous with your brief interruptions.
Programming is very focus-oriented work. If interruptions come too frequently, we may turn off email and the phone ringer for a few hours in order to get some productive work done. Your messages will be answered when we reach a good breaking point. Do not be frustrated by the occasional (rare!) lack of instant-response -- just imagine that we were ignoring someone else's interruption while focusing on your project!
Testing & debugging
Testing, debugging and fixing bugs are normal, billable development activities.
The software development process consists mostly of design work (thinking, drawing, talking, brainstorming), programming, testing and fixing bugs. Finding & fixing bugs is a natural part of the process. To be honest, while it may be possible to write entirely bug-free software the first time, doing so would be prohibitively expensive. It's far cheaper to write using best practices, then look for problems (also using well known industry-standard practices), then fix them.
Every app and preview that we deliver has had at least basic-level testing. Many clients choose to save development cost by doing the bulk of testing on their own, and this is encouraged. However, if you'd prefer not to find problems in your deliverables, we can spend extra time testing and only deliver "ready to go" software. Take caution that this is substantially more expensive.
This question comes up often enough with people new to software development that it has its own wiki page.
Previews and Status Reports -- Client obligation
Formal progress reports go out every week, and occasional updates more often, if the situation warrants. These reports are your view into how things are going and your opportunity to make correcting feedback if things aren't all going according to your master-plan. If we don't hear from you that something is not to your liking, we will continue implementing The Plan as earlier agreed.
Similarly, you will receive ad-hoc previews of your app as progress is being made. These are opportunities for you to watch the pieces come together and verify that everything is proceeding as expected, or to offer correcting feedback, if necessary. If we do not hear from you, we will continue along the same path.
The further off track things get, the more expensive it is to do re-work. Everybody who works on your project wants you to succeed and wants your development experience to be a good one but, if you aren't mentally present for the process, we can't help you. It is critical for you to be mindful of your business!
Note that these previews will often be buggy and/or incomplete. Until we get to the final stages right before release, they are not intended represent a finished product but, rather, a chance for you view the direction that things are taking and the progress being made, and offer feedback on either, as necessary.
If something is not right with your app, or you're not satisfied with progress, or you're unhappy with any part of the development process, let us know immediately. We can't work to minimize a problem about which we do not know!
Project/deliverable lead times
We typically keep several projects going at the same time. This allows us to keep working on something else while waiting to hear back on another project. It also allows time to think about something else while the first thing simmers in the back of the brain for a while. For the most part, a given project will get about 10-15 billable hours per week. If you need your project to get less (say, for budgetary reasons), we can work with that. If you require more dedicated time, we can often push one project up to 20hr/wk for short periods, but require a long term commitment before devoting much more than that.
On a typical week, by Thursday, we've already planned out (and often committed) what we will be doing the following week. Hence, if it is critical to you that something be done by a certain time, you must let us know early. On rare occasions, we'll have a break and can squeeze-in your particular thing, but time-critical items should be scheduled early.
For the most part, we plan things in such a way that emergencies don't happen and, throughout our working relationship, will strongly encourage you to plan similarly. However, unexpected issues can arise, so we often allocate a buffer of time for dealing with them. In particular, immediately after you ship a new app, we will leave a buffer of time for responding to any issues that comes up.
Keep in mind, though, that we have many clients, we're a small shop, and we are typically unavailable evenings & weekends! Of course we want your project to succeed, and we want your development process to be a pleasant one, so we will do our best to work with you to resolve all issues, big and small -- just keep in mind that our resources are limited.
Weekends and off-hours
In particular, we tend not to work weekends and odd hours. While you may find that you catch us working an odd-hour (or weekend), we don't schedule this as client time. Normal business hours are 9am to 6pm, Monday through Friday, holidays excepted.
From Thanksgiving until the first business day after New Year's Day -- "The December Shutdown" -- we take a very light work-load, and email/phone response is slightly slower. This is the time we spend doing all of our year-end business, taking care of internal projects, cleaning up all the things throughout the year that were left as "I'll get to that later", etc.
In particular, we do not schedule any new deliverables during this time.
If you have something specific that you will need done during December, please make certain to discuss it with us and have it scheduled before Thanksgiving.
To clarify: while we may have a deliverable scheduled for, say, 12/15, that was scheduled prior to Thanksgiving. The thing we don't do is, on 12/5, take on new "I need you to do this new (previously unscheduled) thing and I need it on [some date in December]" items.