How to evaluate codebase

Question

I have built a bespoke CRM for a client. It was his idea and he has paid for it in full. In the proposal I wrote that I retain the rights to the codebase. He now wishes to negotiate buying the rights so that if he ever wants to take it to another developer he can do.

Firstly, how could I go about pricing it in a way that is both fair and reasonable? (There are still updates/changes being made which are being charged per hour.)

Secondly, was this the right thing to do in the first place? He mentioned that not giving the client control is very dated, and that it is all about flexibility and allowing the client to leave whenever they want. Is this correct? In future should I always give the client the rights from the start?

Answer 1

I have built several systems for clients. In my experience, it is very rare to be able to sell such a system to multiple clients. (I haven't done it once in 30 years.)

However, there are parts of the code base that can be reused between clients.

My approach is to say that "the specific application and design belong to the client. I retain the rights to code modules and the client has a non-exclusive, non-restrictive license to those code modules and may use them in any future derivative applications." In that way, the client can take the code to another developer should I get "hit by a bus" and I can use parts for other clients.

To be able to sell a system to multiple clients, I needed to design something that would be easily modified for each client. I was able to do that only after having multiple prospects ask about a type of system. Building a base that can be easily modified is a lot of work, but if you have multiple prospects for such a system, it can pay off.

Answer 2

Don't sell it outright. License it. Non-exclusive, non-transferable, non-redistributable. You did good to set things up as you did. See more here in software engineering stack exchange.

Answer 3

I have a deal with one of my clients like this. Basically, I own the code, but they have the right to use the code as they wish provided they do not transfer or sell the software without my express authority.

I retain all rights to the codebase and may sell the software to others as I see fit.

Another clause in all my contracts is that if I should ever go out of business, each customer will receive a copy of the code and the database for maintenance purposes.

In your case I would consider a couple of different things.

1. Are you interested in selling to others? If so make sure you retain those rights, and give them rights to the code for maintenance purposes only.

2. If they are only interested in what happens if you go out of business, then you can make an addendum to the original contract that states that they will receive the code when you are no longer providing services.

3. Make sure when you sell the code you also get a maintenance contract for a decent term, like 5 yrs and then renews automatically each year that they do not decide to terminate the contract after that. Make sure also to add in an x% increase in maintenance fees, or some other way to increase the fees. I also put a cap on the number of hours for adding new features with a $/hr for anything that goes over that.

4. If you sell, make sure you get a good price for it. Something in the neighborhood of what you charged to create it would be a good starting point.

5. Get a lawyer involved, you can mock up the initial draft with something like rocketlaw.com, but have a lawyer go over it before presenting it to the client. I guarantee they will have their lawyer go over it. It's expensive so keep it in mind when you are negotiating the price.

6. You might want to put in some kind of clause that allows you to use portions of the code that are not business specific in other projects. I.E. if you created a really good drop down box you want to be able to use it in other projects, or maybe the security system etc.

7. Make sure any open source code you have hasn't already legally made the code public. Some of those licenses look like it's ok to use but there are clauses that make any code you add have to follow the same license (gpl, lgpl, creative commons etc) and release the code if asked.

Remember right now you have a lot of leverage, if he doesn't like the clauses, you can continue as is. You aren't trying to sell the code, he's trying to buy it. Each clause he takes out, increases the price you have to charge. For example if you can't use the security system, then the price increases by at least as much as it would take you to build another one from scratch.

It's going to cost a lot to buy and retrain their staff on a new system. And depending on how the original contract is written they may not even have rights to their data, or the format it's in. My contracts usually state that the data is the property of the client, but it does not state the format of that data, so if I want to produce it as a giant denormalized csv file, I can.

Some ideas anyway.

Answer 4

If you specify to your client that 'this code is limited to your usage for XYZ operations, and when so used, and only when so used do you own the rights to the code". "We retain the rights to the code for all other applications." Example: a brand name or trademark may be same words, but when used for very different applications so there is no misunderstanding of brand & its use. Note; there is a big difference between a 'trademark' & a "Registered Trademark". The "Registered Trademark" is a mark listed on a specific countries list or registered marks with application to a specific field of commerce or article. A 'trademark' is just a brand identification but must not clash with a Registered Trademark

Answer 5

re: "In future should I always give the client the rights from the start?" -

The case of not giving them rights happens all the time. If you buy commercial software, you don't get the code. Places I've worked have sold things with embedded software custom for the client, and they never gave their clients rights to it. That being said, the risk of a solitary developer going bye bye has to be acknowledged. The moment the developer and client part ways is a common source of conflict and should be thought through.

As it is, the choice is up to the market, right? Your own client agreed to it and they paid you, and now you're in a situation where they are offering to pay you a little more. Sounds like a win.

I suspect the unspoken reality, is that you retaining exclusive rights gave them a chance to get something a little cheaper than they might've gotten otherwise. Something for something. Personally I'm in favor of the arrangement in David R's answer above. But some larger businesses can have issues with it.