Forgot your password?
typodupeerror
Software Technology

Ask Slashdot: How Long Should Devs Support Software Written For Clients? 384

Posted by Soulskill
from the just-until-the-next-venus-transit dept.
lucky4udanny writes "My client says any software/website we develop for them should be supported with bug fixes forever, with no further compensation. We have generally supported our work for two months, to give the client adequate time for real-world testing, after which we charge by the hour for all support. How long should a company fix bugs without compensation in software they developed? What is the industry convention?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Long Should Devs Support Software Written For Clients?

Comments Filter:
  • by jmorris42 (1458) * <`jmorris' `at' `beau.org'> on Wednesday June 06, 2012 @06:05PM (#40237829)

    Dude! The support details are something that you should have had in writing before you even started working on detailed requirements.

    Both sides agree in writing on the scope of work, acceptance procedure, support, training, documentation, code disposition (work for hire, GPL, third party libraries, possibly even escrow), all of that stuff. Anything else just shows a total lack of professionalism.

    If you are now in a position of being asked to support it forever without anything in writing you have to decide which will be worse, cutting your losses now and writing off that client and everyone they will bad mouth (with some justification but they are equally guilty of not insisting on getting anything in writing) you to or digging yourself into a hole providing free support until they eventually toss that codebase. Which one you choose depends on far too many factors you haven't provided.

    • by Anonymous Coward on Wednesday June 06, 2012 @06:15PM (#40237955)

      It's probably a good idea to check with a lawyer if there is a legally required support duration and what is covered under it. In this case, he should be happy if there is, because then he tells the client that he'll provide support as legally required and any additional support would have to be negotiated. Don't leave the client hanging if he needs support now and is willing to negotiate a support contract. Be prepared to write off that support in case no contract materializes though and be firm if the client tries to drag this out.

      • by SomePgmr (2021234) on Wednesday June 06, 2012 @07:04PM (#40238497) Homepage

        Probably a good idea.

        And if there isn't I imagine the only answer would be, "We've met the design goals as conveyed to me, and you haven't contracted me to provide infinite support. But you're welcome to make an offer and I'll be happy to work with you from there."

        Without being a dick about it, of course. Next time, figure it out ahead of time and everyone signs on the line provided.

        • "And if there isn't I imagine the only answer would be"

          Well, there were two questions, and two potential answerers so go figure.

          My position:
          How long the software should be supported for defects?

          Forever. Since the software doesn't wear out, any defect was developed there from origin, it's a reasonable expectation that when someone asks for something, it is asking for something without defects, so covering for bugs forever is the only sensible way to respect the contract.

          Of course, there's the grey area in r

          • by pclminion (145572) on Wednesday June 06, 2012 @11:02PM (#40240289)

            How long the software should be supported for defects? Forever. Since the software doesn't wear out, any defect was developed there from origin, it's a reasonable expectation that when someone asks for something, it is asking for something without defects, so covering for bugs forever is the only sensible way to respect the contract.

            If you have a contract that actually makes you provide free bug fixes forever, then you signed a shitty contract. Software always has defects, this is simply a fact of life. Extremely rare defects, by definition, do not make themselves visible very often. The reason rare defects are not found during testing is precisely because of this. More comprehensive testing does not ensure zero defects -- it only ensures that whatever defects do remain happen exceedingly rarely, or under exceedingly improbable circumstances.

            It is quite reasonable, as a client, to expect a software maker to provide bug fixes for software they provide. It is equally reasonable for the software maker to request ongoing payment (commonly called "maintenance") to continue providing these bug fixes indefinitely. Both parties to the contract are making a risk tradeoff when they sign. The client is risking that they will pay a certain amount of money for the software (including the initial development costs and any ongoing maintenance costs) and never actually recoup this expense by using the software. The software maker is risking that they will charge a certain amount for development and maintenance and some defect will arise that will cost more to fix than they are getting paid to fix it.

            The two parties hopefully meet in the middle with a price and contract that seems optimal for both.

            Just because it's software, doesn't mean you let your eyes glaze over and throw basic economics out the window. Or, for that matter, the basic observation that humans are fundamentally fallible and you can't expect people to magically do things perfectly just because they work in a technical field.

            (Another factor in this is that it is actually not risk-free to fix bugs. Fixing bugs necessarily involves changing code. Changing code may introduce yet another defect, or expose a latent one.)

          • If the parties involved didn't even bother to nail down something as basic as how much support is included in the contract, do you really think anyone bothered to ensure that there were reasonable and unambiguous specifications up front? Who pays to determine what's a bug in the application code (developer's fault), what's a bug in the requirements or user error (customer's fault), or what's a bug in the OS or any third party libraries (someone else's fault)? And once that determination is made, who pays to

      • One mistake I made in a contract awhile back was not defining the lifetime of an app as 2 years. 4 years later, I'm holding the thing together with Elmers and prayer.
    • by cpu6502 (1960974)

      Microsoft has supported XP for seemingly forever. At no charge (3 major updates and also minor bugfixes - all free). But you're right this Questioner should have a contract somewhere to specify exactly how long the software will be supported. One could argue that "no time specified" means the customer should get no support at all. They should not have signed the contract, if they did not like those terms.

      • That's not the same thing at all. Stuff is specifically written to be compatible with Windows, not the other way around.

        His situation is reversed. He puts a web app out there, and browsers / technology / other software will constantly be changing around it.
        • by networkBoy (774728) on Wednesday June 06, 2012 @07:25PM (#40238679) Homepage Journal

          I don't know what his app is, but I look at it this way (and is how I handle something I write):
          Is this a bug?
          Assuming it is then:
          is this something that is obvious code error (i.e. buffer overflow, null pointer, etc.)? I fix it.
          Is this something that is behavior not as expected, but is not a code error (logic error), and should have been seen as part of acceptance testing? I charge for the fix.

          really simple, and so far I've not had any customers balk.
          -nB

          • by thegarbz (1787294)

            That leaves you open to one problem, the bounds of the system. If you promise unconditional support will you need to re-write your app when Windows 10 breaks it even though the customer isn't asking for any different behaviour.

            If you offer support like this, bind it to the system it was designed for. That naturally limits the life of the support contract to the life of the system which may only be a few years.

      • When I've got $30B in the bank and a firehose of an income stream, I'll support all my past customers gratis too...

    • by icebike (68054) * on Wednesday June 06, 2012 @06:58PM (#40238447)

      On the other hand....
      Forever is a long time. There is no reasonable expectation of forever in any legal contract for goods or services in any
      industry I'm aware of. Even contracts for burial plots do not last much more than 200 years.

      Sure, a wise contractor will have a warranty duration mentioned in the contract, and specify an acceptance testing phase, after which
      all bugs belong to the purchaser. Any bug fixes offered after that are likely to require additional payment.

      Without such a Ts Crossed and Is Dotted contract, there are only reasonable expectations to fall back on:

      Both sides know that there is no such thing as bug free software. Never has been. Never will be.
      Expectations to the contrary are not reasonable, and never have been.
      Expectations of indentured servitude went out with the 13th amendment, and no contract can bring that back.

      Further, rare is the software that enters service and remains unchanged for its useful life. Any warranties or assurances
      are lost once the code is modified, even if modified by the same developer, but especially when another developer
      steps in, or the purchaser themselves make changes. Even without a contract that states this, one need only
      point a finger at the changes made by others to divert ALL blame.

      The two month time period mentioned in the story and "adequate time for testing" seem a little thin if you ask me.
      I would never sign a contract for custom software that was so tightly limited, and it does not sound reasonable for any project of any reasonable scope.

      So without something in writing, the contractor deserves a little pain and suffering (as a stupidity penalty), but they are STILL not up the creek without a paddle, because "forever" is not reasonable, and reasonable expectations become the deciding factor. But in this case "reasonable" is no longer strictly the contractor's call, and courts may well have a say.

      • by Registered Coward v2 (447531) on Wednesday June 06, 2012 @09:40PM (#40239743)

        Both sides know that there is no such thing as bug free software. Never has been. Never will be. Expectations to the contrary are not reasonable, and never have been. Expectations of indentured servitude went out with the 13th amendment, and no contract can bring that back.

        Expectations of being sued into indentured servitude, however, did not go out with the 13th (nor did indentured, only involuntary, servitude)

    • Best Practice (Score:4, Insightful)

      by symbolset (646467) * on Wednesday June 06, 2012 @07:39PM (#40238791) Journal
      This is why it's best practice for small software developers to do business with an attorney who offers bulk rates on Delaware corporations and has the reverse merger bit down. You just turn & burn. Several iterations down you can even buy your fully-laundered bankrupt corps back for their "goodwill". Don't they cover this in CS212 still?
    • by Zaelath (2588189) on Wednesday June 06, 2012 @08:21PM (#40239165)

      As a small company you simply agree that your company will support the software in perpetuity, then disband that company when the support costs hit a pre-determined point, and start a new one with the same people. The liability for the support dies with the old company.

      Hey, don't blame me for corporations law.

  • by Anonymous Coward on Wednesday June 06, 2012 @06:07PM (#40237851)

    ...one slip-up and you're gonna be supporting it for the rest of your life.

    Prolly end up having to raise your own grandkids too.

    • by Greyfox (87712) on Wednesday June 06, 2012 @07:20PM (#40238645) Homepage Journal
      Back in the 90's (and still to an extent these days) if you were a really bad programmer you'd just screw around for 3-6 months and then change contracting companies, usually getting a $10-$15K raise in the process. Then the next guy would get stuck supporting your crappy job. Case in point, in the late 90's I got picked up on an inventory project that was already late and over-budget. My predecessor had left in a hurry. Upon reviewing her code, I found that, among other things, she had not realized that in C you have to null-terminate your strings. No accountability must have been nice. It's still pretty damn hard to fire a programmer just for sucking, and it's still pretty damn hard to find good programmers even with the economy as bad as it is. Pretty easy to find bad programmers, though.

      As for this client, you're probably not obligated to anything that's not in writing (IANAL, talk to one.) The "Get it in writing" sword cuts both ways. Tell him you're going to review the support terms in the original contract. Whoops, couldn't find any. Then offer to negotiate some.

  • Never. (Score:5, Insightful)

    by LWATCDR (28044) on Wednesday June 06, 2012 @06:10PM (#40237883) Homepage Journal

    " after which we charge by the hour for all support. How long should a company fix bugs without compensation in software they developed?"
    You have your answer. You charge by the hour for support including bug fixes. Only slaves work for free.

    • by Kjella (173770)

      You have your answer. You charge by the hour for support including bug fixes. Only slaves work for free.

      If there is nothing else in the contract then I would say yes, once the client has signed off on it any remaining bugs are billable. Of course then it's easy to dump a bug-ridden piece of shit on the customer, hope they do poor testing and cash in big both on finishing early and getting extra bug fixes. So I wouldn't say "never" is that common, most contracts I've seen have a guarantee period of 1-6 months where bugs are fixed free of charge. But they always make it clear this is a service and obviously it'

    • You have your answer. You charge by the hour for support including bug fixes. Only slaves work for free.

      It depends. Are you selling the product, or your work? If you're selling the product, you should support it, because if it's buggy, then the client didn't get what they paid for. If you're selling your work, you always charge by the hour no matter what.

      In reality, most arrangements of this type are sort of in between, which is why a service agreement is so important. Also, it may depend on how much

  • 3 Months (Score:5, Informative)

    by Anonymous Coward on Wednesday June 06, 2012 @06:10PM (#40237887)

    We do 3 months for custom / work-for-hire products, and hourly after that.

    You have to be careful, because I've had companies that start making changes to their infrastructure, and then told us our software didn't work when in fact their environment changed. So be very specific.

    • Re:3 Months (Score:5, Interesting)

      by NoNonAlphaCharsHere (2201864) on Wednesday June 06, 2012 @06:44PM (#40238285)
      Too right. Been on the receiving end of that "but our processes have changed" phone call. The analogy I use is "Let's say I'm a tailor who makes a suit for you. Now you gain weight and expect me to fix it for free?".
    • Re:3 Months (Score:4, Interesting)

      by Jane Q. Public (1010737) on Wednesday June 06, 2012 @07:07PM (#40238543)

      "You have to be careful, because I've had companies that start making changes to their infrastructure, and then told us our software didn't work when in fact their environment changed. So be very specific."

      You should have a specified "scope of work", describing the deliverable. If the situation changes to the extent that anything lies outside the original scope of work, it costs extra.

      I used to work for an engineering company, and that worked for them. Just be sure to specify your scope of work. Then actual bugs that lie inside the scope of work are your responsibility. Anything else is not.

  • by Wonko the Sane (25252) * on Wednesday June 06, 2012 @06:12PM (#40237905) Journal
    If they want lifetime support then price your services accordingly and offer that as a option. Chances are if you give them two quotes, one with your typical policy and another one priced for what they are asking for, they'll choose the one that makes the most sense.
    • I would provide x amount of time for warranty (say two months) and provide the option to buy into service (monthly fee) that covers feature and security fixes.
      The best part of a service model is that you keep contact with the customer and you can up-sell them to the next feature release.
      This model does not work as well for all custom work.

      For custom x months of warranty plus $x per hour for changes and fixes. Providing them with a lifetime support option is very unpredictable and may scare the customer awa

    • by Altrag (195300)

      No, they'll choose the one that's cheapest and expect you to fulfill the one that makes the most sense.

      Clients are asshats. Well ok not ALL of them, but a lot of them certainly are. I can't count the number of times I've gotten a call asking me to fix something immediately as if all I had to do was flip the "fix this bug" switch and had really just been holding out on them for some unknown reason.

      • by Dahamma (304068)

        What they expect doesn't really matter (as long as you are willing to lose them as a customer going forward).

        If you both sign a contract for given work at a given price, they are obligated to pay the agreed price and you are obligated to do the agreed work, no more, no less. Unless they can prove in court that you didn't fulfill the contract they're pretty much SOL.

        Which is really the answer to the article question - there is no "industry convention", the industry convention is to negotiate a contract that

  • by greywire (78262) on Wednesday June 06, 2012 @06:13PM (#40237933) Homepage

    Really thats the issue.. whatever support you were willing to offer should have been put in writing and agreed on before work began.

    The same sorts of things can happen during a project too. Get it all in writing. Clients love to change things as you go, and they'll do it until they break you if you don't tell them before hand they can't. IE, you give them say 3 mockups to choose from.. then once approved they can't come back at you and say thats all wrong we need the design changed. Same thing with the support. We all know you probably cant support the code forever without compensation, you have to tell them that or they will expect free support forever!

  • by I kan Spl (614759) on Wednesday June 06, 2012 @06:14PM (#40237941) Homepage

    If you have a good enough support contract then the initial fee for doing the work is usually peanuts compared to the support.

    All of this needs to be in writing, as part of the initial contract or else you will have no fun doing support.

  • by Stargoat (658863) * <stargoat@gmail.com> on Wednesday June 06, 2012 @06:15PM (#40237951) Journal

    There's so many different software industries, you cannot just ask "how long?"

    For example, ATMs need to be supported for about 15 to 20 years. But a web hosting app? Maybe 5 to 7.

    Basically, if your clients are paying you, you support them. If you no longer want to support them, you better be damn sure you have a robust, tested, and thoroughly vetted (and preferably heavily used) replacement product.

  • How Long Should Devs Support Software Written For Clients?

    As long as the clients have paid for, as specified in the terms of the development contract (except insofar as the developer has an interest -- e.g., in developing goodwill -- that outweighs the cost of the support, or applicable law -- e.g., general provisions governing warranty obligations that the contract did not modify, either because the language didn't address them or because the law doesn't allow contracts to modify them -- imposes additional

  • Be careful... (Score:5, Insightful)

    by billster0808 (739783) on Wednesday June 06, 2012 @06:16PM (#40237969) Homepage
    Clients have a funny way of making everything into a bug. Customer changed their minds about something after they've already signed off on it? Bug! Your code doesn't run on an OS that didn't even exist when you wrote the software? Bug! Customer wants a new feature? Bug!
    • I've been caught on that one before... and it was my fault.

      Those things need to be spelled out ahead of time, for a project of any size. If the customer's needs change, that won't be in your written scope of work, and you can point to it as proof.

      For small projects, I've been able to point to emails and say, "You didn't specify that anywhere in your instructions." For anything larger, put it in writing more formally.

      It can be something as simple as a "Project Description", written by you and sent t
  • by fuzzyfuzzyfungus (1223518) on Wednesday June 06, 2012 @06:17PM (#40237991) Journal
    If only there were some sort of body of legal precedent that allowed two parties to write down the salient details of an agreement in such a fashion as to make it reasonably binding...

    Snark aside, the only 'right' answer to this question is the one that was agreed upon when the price was named. Longer support contract = more expensive. Shorter = cheaper. Option to pay per-hour or per-incident thereafter, and for how long thereafter, also preferably specified.

    Some people make a business of charging crazy money, backed by the assurance that they'll still be there to hold your hand in 20 years. Some people sell you a box for $20 and tell you that they hope it doesn't break your computer. Certain consumer protection laws on the low end aside, any support term is a valid offering, supposing that it is priced properly.
  • Of course, clients can pay up-front for, say, 10 years of support. But they only get what they pay for, no matter the details.

  • by dbc (135354) on Wednesday June 06, 2012 @06:20PM (#40238045)

    A 60-day acceptance period sounds generous to me. Have them sign off on an acceptance letter. After that, it could be hourly, or they could pay monthly support that covers things like pro-active security patching and the right to call you with questions.

    Major software packages are sold with support. Oracle, for instance, gives their salesfolk lots of discretion to negotiate price, but *not* to discount the monthly support contract. That should tell you something about how the big boys think.

    • by hey! (33014) on Wednesday June 06, 2012 @07:33PM (#40238737) Homepage Journal

      This guy has it right. Deadlines go both ways.

      I once had a client where the project manager handling our contract often sat on deliveries for a month or more before looking at them -- and here I am with a three man development team dedicated to this project. Finally we fly down install the production software and train the users. A week later the project manager is fired and nobody looks at the system for over two years until a new manager starts to procure a system and realizes that his predecessor already paid for one. Word gets to the board of directors, and then we get letter threatening.to sue us for not delivering the system.We have no way of proving to them that we flew a team down there and actually did the installation and training, because everybody we trained had subsequently left the organization. But we had the bills we submitted that were paid by the client, which is at least prima facie evidence we did the work.

      Now we had the source in our source code control system, but so much time had gone by that just getting all the stuff together needed to build and package the system would have been a pain (this is why you should be using maven, folks, which we weren't at the time). And there is no doubt the system was probably so riddled with bugs that getting it working would have taken much, much more work, but the client made it impossible for us to deliver a quality product. The project manager accepted deliveries with only cursory examination, and so late that it forced us to work on this product intermittently, dropping it and picking it up weeks later.

      The lesson is build client responsibilities and support limitations into the contract.

      Standing behind your work doesn't mean delivering unlimited support. It means delivering more than you promised. That starts by setting clear limits and conditions on what you are promising.

  • I'd say if you've made some obviously boneheaded mistake, something that you should have seen and fixed, then yeah, bite the bullet and fix it for them.

    On the other hand, if it's the kind of day to day stuff that comes under the heading of "maintenance" then charge them.

    Car analogy: Recall and repair of a manufacturing defect (Manufacturer pays) vs an oil change and brake relining (You pay).
  • The EU tends to think 2 years for bugs... I think you should have really thought about this before writing the first line of code but hey it's not like this could end in a lawsuit or a reputation problem or anything...

  • Offer them a service contract.

  • If you want support for any product you have to pay for it; either by contract agreement (low risk to business), pay as you go (low risk to contractor), or having someone on staff to maintain it.

  • Long answer: as long as they are willing to pay you at a competitive rate.

  • No one in their right mind should support "forever", and any client who is foolish enough to demand it can go elsewhere. Anyone who says "yes" to those terms will be bankrupt by the idiot clients who demand that service. The fools who want that service will find that they have software that the vendor no longer exists to torment.
  • Industry convention, by which I mean what companies like IBM and their ilk do to customers, is they deliver crap to their customers then charge them an arm and a leg to fix it. I don't know that industry convention is particularly helpful when you're a small time guy trying to earn a living.

    Like others have said, you should agree to a sign off period, but if you want to make your customers happy, you might consider fixing the worst most serious cases of bugs for free for a lot longer. But you would restrict

  • There's no easy answer to what is "typical" because so many variables exist, especially with custom software. A common model for non-custom work is an annual maintenance/assurance contract. Client's buy the software, and get one year maintenance. After that they pay {x} amount each year to renew that contract. During the life of the contract the client is eligible for support and product updates.
  • by GumphMaster (772693) on Wednesday June 06, 2012 @06:47PM (#40238317)

    For the large contracts I have been part of the contractual arrangements typically include a warranty period of 12 months for latent defects, that is things that are not functioning as agreed in the specification and could not reasonably have been expected to be found during the agreed customer acceptance testing (the equivalent of a pre-purchase inspection for a tangible good). For example; the software is specified to handle any Standard XYZ message, a wide range of messages were tested and the software accepted, but an unforeseen, legitimate real-world message breaks the live system. Everything else involves a fee to change the contract, which includes the specifications, and do the work. They hire people to be bloody-minded about what creeps into the "latent defect" category. For high risk projects they will take out insurance against the possibility of latent defects (and charge the customer indirectly).

  • Some people have tried car analogies that don't work. Here's one that does.

    Car manufacturers cover certain SAFETY related defects indefinitely because the govt requires it (or maybe because they believe it's cheaper to fix than be sued). However, they generally only cover manufacturing defects for the duration of the warranty. They don't "fix" the car when environments and specifications change. e.g. Cars designed for leaded fuel weren't retrofitted to use unleaded fuel (although high octane unleaded fuel w

  • Make some minor/major tweaks, repackage it as Version 2.0 or whatever, and tell them that the old version is no longer supported. Then you can negotiate a service contract for the "new" software.


    Hey, it works for the big dogs...
  • Maintenance (Score:5, Interesting)

    by EmperorOfCanada (1332175) on Wednesday June 06, 2012 @07:13PM (#40238603)
    This is what a maintenance contract is about. Generally there are three parts to a maintenance contract. One is that you will charge a set fee for any changes or new work (potentially with a yearly retainer to cover your costs in being ready to do this work) and the other part is that for every year that they pay a fee you will fix any bugs. Often this second part has a year or so included with the initial work.

    The first part of the contract might also cover preventative maintenance such as checking to see that the hardware is functioning, backups are being done, and that nobody is messing with the software.

    Where you really need to cover your ass is in two areas. One is their losses. You can't be responsible for them. If the system is down for 30 minutes during a critical sales pitch they could argue that you just cost them a billion dollars. The other is if they ruin things somehow. If they have someone else mess with the system or they don't do backups, or use sub standard hardware then you need to be able to wash your hands.

    The third critical part is the breakup clauses. If they become a pain in the ass or your company just morphs into something where the old clients are a distraction you need to be able to walk away. The best way (and something they should insist upon) is the source and documentation they would need for them to be able to hand the contract over to someone new in a second. Personally I would refuse to deal with a company that didn't provide this.

    But most of all I would never in a million years commit myself to a company like that. Not just because it would be stupid but also any company that would insist on something so douchey is going to be the biggest bunch of scum to deal with. I could see them insisting that new work and upgrades come under the purview of fixes. "Oh we have moved to a new OS and your software broke." I tried accessing it with an iPad 9 but they don't use HTML anymore so you need to fix that." Then knowing they have you over a barrel they would say, "If you just make it compatible with our new database, OS, and mobile devices we will let you out of the contract in 2 years."

    Lastly maintenance is where many companies make the big bucks. I witnessed where a letter was capitalized and the company billed $1,200. This was in a scripted environment and implemented by a single developer with no complicated QA process. He just logged in directly and VI'd the script.
  • by Midnight_Falcon (2432802) on Wednesday June 06, 2012 @07:18PM (#40238639)

    I have to chime in here because I feel like many of the comments have missed what this is in .."real world" programming: A Sales Opportunity.

    It is inevitable that after a while, your client is going to want new features. If you offer a low rate for bug fixes, or offer a certain # of hours on bug fixes after the original term, you'll keep the channels of communications open with the client; rather than them forgetting about you.

    So, you can act altruistic and offer some amount of free bug fixes..but use the requests for those bug fixes as an opportunity to suggest new functionality/features, or make changes outside of that realm that translate to billable work.

    If you have a proper consulting agreement, any changes outside of bug fixes will already be in scope as a billable activity, so you should be able to bill for that time accordingly.

    I find that keeping lines of communications open with clients after projects has done causes new projects to happen and is a great rainmaker. I think what seems like their thick-headedness is actually an opportunity for you to get more business out of them.

  • by Charliemopps (1157495) on Wednesday June 06, 2012 @07:45PM (#40238837)
    Seriously? Are you guys nuts?
    Contract Contract Contract
    You get mixed up with the wrong customer with a bad contract and you could be out of business before you can blink.
    You should have very specific, MEASURABLE deliverables. Things like "Make the interface faster" are not going to fly. What does "faster" really mean?
    Your support structure should be very specific. They should be signing off on every single thing in the deliverables. After that your contract should specifically state what's considered a bug and what's considered a scope enhancement. I guarantee you that every single thing they find that isn't exactly what they imagined in their many managerial meetings they are going to consider a "Bug".

    "You designed this forum for us, but when we try to attach this 4 Gigabyte file to the post, internet explorer crashes before it can even upload. Clearly this is a bug!"

    My company has many types of support contracts and it all depends on the project and who we're working with. The company that built and maintains our website has been supporting it for over 10 years. We have an on-going contract with them, and they basically build or change anything we want, whenever we want. That contract is VERY lucrative for them however. We actually have offices for a few of their employees in our building. I don't even have an office!

    Other contracts we have basically state that bugs found that are IN SCOPE are handled, for free, by the vendor for a certain period after we've accepted the product. 2 weeks seem awfully short to me. I doubt we'd ever except that. Usually it's more like 90 days. We're a relatively big vendor and pay a premium for what we want though... so we get what we want or don't do business with you. After that 90 days we have a set hourly rate that the vendor will charge us, for another set period of time. Say 1 to 2 years. Usually that hourly rate is somewhere in the $100-$200/hr range.

    If you don't have good, solid contracts to base your work on, you are either going to get screwed, or get a name for yourself for screwing your customers. Or worse, sued into oblivion when you have a disagreement with the wrong customer that just happened to a have a whole floor full of bored lawyers just waiting for you to screw up.
  • by tkrotchko (124118) on Wednesday June 06, 2012 @08:09PM (#40239063) Homepage

    Dealing with people that will try to nickel and dime you is no way to make a living.

    Let some other chump provide them with "service". Spend your time finding decent clients.

  • by StormyWeather (543593) on Wednesday June 06, 2012 @08:28PM (#40239233) Homepage

    Every piece of software I have seen in the medical field is 1 year support and maintenance and a maintenence and support contract for a fee after that. If they drop support let them know that if they pick it up again in the future then there is a retroactive re-up fee. This covers your costs of having to relearn dead projects. There is no company in the world that supports software infinitely however I've never seen a 2 month span either.

    Sorry for typos, slash dot on an android sucks.

  • by wmelnick (411371) on Wednesday June 06, 2012 @08:51PM (#40239431)
    I write into my contracts: 1/3 due up front (agreement of the spec). 1/3 due at delivery. 1/3 due at acceptance. Acceptance is either when they sign off, or one week after delivery of product or delivery of the fix of the last bug determined between delivery and acceptance. Anything after acceptance is billable. Any "bug" that does not match the initial spec is not a bug, but rather additional work to be billed. The original spec is initialed on all pages by them Any changes that they ask for and I agree to during the course of the product being developed are added to an amended spec, sometimes gratis, sometimes at an additional cost. It is a pain, but it is the only way that these things go smoothly.

Cobol programmers are down in the dumps.

Working...