Support duration?

Hi,

What sort of policies do (contract/free-lance) folks follow for post-release support?

As a matter of policy, I fix bugs (errors in an implementation,

*not* a specification!) for free "indefinitely".

I also make myself available for enhancements/modifications (for pay at "current rates") for "some time" after initial release. In the past, that was 5 years. Then, 2 years. Nowadays this seems like an eternity...

I'm now thinking about cutting that to "0 years" (i.e., to cut my future commitments) and bug fixes to ~1 year (still free).

Note that I provide complete documentation for my projects (schematics, artwork, specifications, source code, etc.) so I *shouldn't* be "needed" in any of these cases.

I'm just a bit concerned as to how clients will receive this policy change on my part...

Thx,

--don

Reply to
Don Y
Loading thread data ...

How about making your "retainer period" a separate, negotiable part of your contract? If a customer does not perceive any value in keeping you available then they can opt to strike out that part of the contract. If they see value in retaining you then they will pay. Either way, you will both know where you stand.

--------------------------------------- Posted through

formatting link

Reply to
srl100

Sorry, perhaps I wasn't clear. :<

I *intend* to change the terms to: "... fix bugs, at no cost, for 1 year from release date; no commitment to future development."

My question is: "How typical/atypical is this (for other developers)?" and "How much resistance is it likely to meet among clients?" I.e., my current policies are considerably more generous than this.

E.g., if others routinely fix bugs on a T&M basis, then my terms are more generous wrt bug fixes. Similarly, if other developers routinely agree to be available for N years after release, then my terms, in that regard, would be *less* generous.

Given my own experiences, the bug fix clause is rarely an issue (I don't release buggy software. Of course, being good at writing specifications loads the dice in my favor!). The "ongoing support" clause could be alarming to some clients (I have some designs that are in production for more than a decade; people seem to like the reassurance that they *can* come back for "enhancements" long after the original contract is completed).

Reply to
Don Y

I do just about everything on a per-hour basis. If my client comes back later and wants more work done, whether its fixes or extensions, it's per hour. I do try to give them priority in the queue, when that is possible.

If I did work per-job then I'd have to consider warranty repairs. But so far that hasn't cropped up as an issue.

--
www.wescottdesign.com
Reply to
Tim Wescott

Consider offering a 'coupon' (or 2 or 3) for any support after some initial warranty period. Say, 90 days warranty after implementation and ,after that a coupon that expires in 90 days, one the expires in

180 days, and one the expires in a year. That way, the customer can really only bug you for minor things in the beginning. Of course, regular rates would come into play after a year.

You can alter the times - just an idea. And if they use all 3 coupons quickly - that's their decision.

Reply to
1 Lucky Texan

So, you don't deal with complete projects but, rather, work on "whatever", "whenever" and "for as long as" they want? I.e., not goal driven.

I guess we're in different situations (since there doesn't appear to be a logical "end" to your task(s)) -- but, there may be some parallels. I.e., how would your clients take to the idea that you were "too busy" (or simply "not interested") in doing more work -- on a project that you were "lead" on, previously?

Would they feel abandoned, betrayed, etc.? Or, simply inconvenienced? ("Oh, well... we'll have to find someone else to maintain this product... BUT, we *have* everything we need to do so, just need the

*person*!")

I see warranty as not just related to per job vs. per diem work. I.e., if you wrote a piece of code to do "X" and a bug was later discovered in that code, would you *fix* it? Or, do you have

*no* specific "deliverables" -- other than "attendance"?
Reply to
Don Y

I'm not worried about "warranty" -- if I screwed up, *I* fix it. I cap the time that I allow you to find and report problems to me -- simply so I don't get a call 26 years from now saying, "There's a bug in your *date* handler...".

Note that modifications, extensions, etc. are NOT part of the warranty. We agree as to what the project will entail. We formalize that in a specification. I then implement that specification, faithfully. You sign off that I have satisfied my contractual requirements -- the product does what it was intended to do (insofar as one can test it at sign-off).

If you, now, want to change some aspect of the design or add some feature or start work on Version II, then that's a separate project. *Not* covered by the warranty's terms (i.e., I won't "fix it for free")

What I'm more concerned with is making it pretty obvious to clients that "I reserve the right to NOT do followup work for you". (Note that this is implicit in most relationships but my previous contracts have explicitly *stated* that I would be available "for some period of time" for followup work -- though the terms of that work would be negotiated separately!)

I'm afraid that this can scare clients: "What if we want to make some little change? We'll have to *find* someone to do the work for us (which is a "search cost" that they will have to incur),

*hope* that the person we find is able to pick up where you left off (always a crapshoot bringing on new talent!) *and* hope the changes that we want are consistent -- in that new developer's eyes -- with the implementation you have given us!"

Realistically, there is nothing different, here, than how things have been all along -- except that in those cases where I have a *choice* regarding my labor offerings, that I would *consent* to their needs. OTOH, if I got hit by a truck, laid up with a prolonged illness, etc. they'd still find themselves SoL (the risk of hiring contractors)

Reply to
Don Y

Different goals. Most of what I do is algorithms and software bits for implementing control loops or signal processing into their software base

-- so it's not so much "not goal driven" as not a complete shrink-wrapped package.

That's a dilemma -- how would my current clients feel if I suddenly said "oh, sorry, some old work cropped up and I need to drop you for a while". I try to be as fair as possible, given the circumstances.

If a bug as discovered I'd certainly feel that I should make myself available. Depending on just how stupid I felt about the bug, and how thoroughly the customer tested when they passed the software in the first place, I would charge for more or less of the work.

I guess the difference is that I have no set policy -- I take things on a case by case basis. And, for the algorithmic stuff, it's rare that a real _bug_ will make it through initial testing. All I can think of is if the algorithm didn't take care of some corner case, and it was one that I didn't warn the client about in advance (because, with nonlinear control, you pretty much cannot take care of _all_ corner cases -- you can only identify the space within which your algorithm will be valid, and advise on how to stay within that space).

--
www.wescottdesign.com
Reply to
Tim Wescott

But, if (for example) you didn't put a clamp on the integrator and it was eventually deployed in a situation where it not only "wound up" but actually *overflowed* (consider a process where the setpoint is beyond the practical range of the process... setting a furnace to

1200C but the gas supply is sized such that it will never attain that!). You could argue that this is a bug or a "misapplication".

Regardless. Who pays to have it fixed?

[Flip side: current clients, some months from now, have production *stalled* because of an issue that has come up with your design (hardware or software). How will they feel if you *don't* "drop everything" and attend to their needs? This is how I differentiate between "repairs" and "new, though related, work"]

Note that, in my case, the scenario is more like: "Wow! I'm thrilled that Model I has been so successful for you! But, no, I won't be designing Model II for you..."

Fair enough. I don't want to get into a "who's-fault-is-it" argument with clients. That's why specifications are so important to me! If it's in the spec, my design has to meet it. OTOH, if it is NOT specified, I can do whatever I want -- intentionally or UNintentionally.

[When developing a spec with a client, any time they respond to one of my "What If's" with "I don't care", I say, sotto voce, "When , the device can erase all memory and burst into flames...". After the second time I make this comment, clients are aware that they *should* care about these issues. If they *really* don't think they will ever happen, then they can be comfortable with the "burst into flames" scenario. After all, it will probably SAVE them development dollars!]
Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.