There is an unfortunate trend in our industry in which a developer will work on a project, deliver it to their client once it is fully completed, and then be paid accordingly. While that may work for larger companies, and may be where the trend began, that Model does not work effectively for the founder of a startup, or for the developer they work with.

Understanding the trend, and the alternatives, can set the ground for a better relationship, a greater win-win potential for both sides, and will allow you greater insight as your product evolves.

The payment-at-completion model

The working model that has a Provider paid at the end of a project is exactly that. A contract is set, work begins, and then the founder may not see any actual evidence of work from the provider until the end when the project is delivered. While this kind of delivery gives the provider the opportunity for a grand unveiling—think of the painter revealing the months he has spent creating a masterpiece—it does not really support the evolution or needs of a startup company.

The alternative

An alternative model is based on incremental payment and incremental deliveries, or ongoing access to the source code. Under this model, the developer may be paid a small amount of money to begin the work, and then incremental payments to coincide with milestones to be agreed upon in advance. At each of the milestones, the provider either presents the founder with the most recent deliverable, or can allow them access to the source code along the way.

Which option makes sense may depend on the comfort level of the provider and the interest level of the founder. Again, think of the painter who may prefer someone not looking over their shoulder constantly along the way, and the founder who may have limited technical knowledge and so does not need constant access.

Under this model, it is advisable for the founder to also hold back a small portion of the final amount owing at the end. This will be delivered once testing is complete and ensures the product is what was promised.

The win-win

The more commonly used deliver-and-be-paid model means that this alternative method of development contract requires a shift in mindset on both sides, but it really is a win-win for both parties involved.

From the provider side, it ensures they are paid along the way for work completed. Although we may not like to think about it, the truth is that not every startup is going to succeed. Establishing payment at milestones along the way ensures that the provider is not left holding a product that no one is able to pay for.

On the founder side, it allows them a regular look at the work going on. From the perspective of ensuring the developer is working on the product and that the work is according to the plan, this is beneficial to have.

From both sides, there are additional advantages to this model as well. What if, along the way, the relationship changes and one or both would prefer to part ways? What if, along the way, the plan changes and the work schedule or plan has to be adapted?

If there are issues or a misunderstanding along the way of what is to be done, during the course of work is the best time to sort this out. Many of the conflicts between founders and developers happen when it comes to the grand unveiling at the end, and the founder finds that the product is not as they expected.

Every day, founders and developers work with new technologies to develop new ideas and new products. There is no reason their method of working together should not also reflect new and better ways of doing things.

Have you ever tried to work under this kind of pay-as-you-go model? What excuses have you heard for not moving forward this way?

The post How to convince your provider to share source code from day one appeared first on Out Of Tech.