Although potential customers may understand a developer’s hourly work rate, they also know that the final cost relates to the developer’s productivity multiplied by that rate. A programmer who offers a low hourly rate but is inexperienced, works slowly, and makes mistakes will ultimately cost his customers more money than a more productive programmer at a higher per-hour rate. Therefore, it’s necessary to realize that customers have this kind of concern and to assure them that a low hourly rate also means low overall project cost, based on a high level of work productivity and quality.

Customers will expect to be able to communicate with developers during a project just as they would with local developers. They do not want the fact that the developer is remote in another country to be a problem. Therefore, developers should ease customers’ concerns by providing email and instant messaging communications, as a minimum. Other forms of communications, such as telephone or NetMeeting conferences, may be appropriate in some cases. If the offshore developer doesn’t use the English language well, they should enlist the help of someone who does. Customers will feel much more comfortable knowing that they are being understood and that they are able to accurately communicate their needs.

How do I exchange documents, source code, programs, and web pages with offshore developers?
Customers need to be assured that they will be able to exchange the work products as efficiently and reliably as possible. Again, the objective is that the large distance between customer and developer must not be a disadvantage. Therefore, developers should be capable of online information exchange with customers using email attachments, FTP, or posting to a project web site. If you use Microsoft Excel, Word, or other project-related software, make sure your customer has similar software if you plan to use these formats for exchange.

Some customers will need to disclose confidential information to developers in order to communicate their requirements. This might be, for example, a new business concept that the customer doesn’t want revealed to competitors. Non-Disclosure Agreement (NDA) forms are the usual way in which this is done. The agreement simply states that the developer must keep the specified information confidential before any work can be done. Both parties sign the agreement. In some cases, the customer will have his own form. In other cases, he may expect you to have your own standard form.

Customers in the U.S. are accustomed to paying for products and services by checks drawn on local or national banks. However, this might not be convenient for offshore developers, and customers can be expected to understand this.

Developers should settle on payments methods that are as convenient as possible for both parties. Multiple payment methods that give the customer choices are always good. Cashiers checks, demand drafts, bank transfers, wire transfer, SWIFT.

Some U.S. customers might have concerns about the legal ownership of the code that is produced under the terms of the contract.

One method, common in the U.S., is for the developer to retain ownership and license the use of the software to the user. This method might be used if the developer wishes to market the product to other customers.

Otherwise, the source code belongs to the customer to do with as he wishes, even to resell it as his own product. Typically, work-for-hire contracts operate this way.

Again, customers in the U.S. will understandably have concerns that language differences and long-distance separation will create potential misunderstandings regarding their requirements. They want to know that they have accurately communicated what they want the developer to do and what they expect the final product to be.

Therefore, offshore developers should clearly define the process they will use to satisfy customers’ concerns.

Details may differ, but the general process should be one that initially produces a detailed requirements specification document describing the developer’s understanding of exactly what is to be developed and how it will work. This document should then be sent to the customer for approval.

Next, a detailed user interface document or prototype should be produced to be reviewed and approved by the customer. This document or visual model should allow the customer to see how the product will appear to its users.

Finally, the customer should be provided an estimate of the cost of the job or project with a full explanation of how the cost was derived (tasks, hours, cost per hour) and a schedule of events or milestones, including a final delivery date.

If support is required after product delivery, the details of how this support will be provided should also be supplied to the customer.

It’s very common for customers to want new features added to their software or web site after the initial work has been done. Developers must realize this will occur and have a process for dealing with it.

Many developers simply treat requests for additional features as a new project. This leads to far fewer misunderstandings than attempting to somehow add the additional work and cost to the original project.

How do I keep track of progress? How do I know if all is well with my project?

Customers will want to know the status of their project at various stages. Some customers will be more demanding than others and will want more frequent or more detailed information.

Therefore, developers should plan to provide the customer with project updates when tasks or milestones are completed. This can be done in the form of email reports, intermediate code, or web site postings.

Any changes to the original plan, schedule, or cost should be made known to the customer immediately. Be sure the customer is being updated as frequently as he requires. Ask for his feedback and suggestions for improving status reporting.

U.S. customers are accustomed to paying for programming or development work on a schedule basis, almost never as a single up-front payment. Partial payments are made at various agreed-to points in the project. For a relatively small job, for example, half the total payment might be made at the beginning before implementation begins, and the other half at successful project completion.

Developers should be flexible with payment terms to meet the varying needs of customers.

Give us a call now or email us at to find out how we can address all these concerns and more.