Ask HN: How do software consultants deal with maintenance?

patio11 · on Sept 14, 2015

You write an acceptance procedure into your MSAs. Pro-tip from Thomas: write the MSA such that the client gets two weeks of business days from delivery to object in writing to the deliverables or "the deliverables shall be deemed accepted." You don't owe clients anything after the acceptance period.

Should it fit with your desires and your clients' needs, you can sell maintenance on a retainer arrangement, which is use-it-or-lose-it access to you at a defined price which is a modest discount to your prevailing rates. If clients do not have an active retainer agreement with you, maintenance projects are entirely new projects, with a new SoW, at your current rate, subject to your current availability.

How this looks in practice: if I'm selling projects at $20k per week, the initial SoW offers 2 weeks at $20k plus two days a month of availability at $7k per month, with those days covering bug fixes, incident response, and such minor tweaks or adjustments as the client may require. In the event the client doesn't purchase maintenance, and the app goes down, then I'll try to slot them in for another 2 weeks at $20k each, but I can't make any promises.

You know the Chris Rock monologue about steak? When you go to a restaraunt with money in your hand and ask for steak, you get steak. Then you go home... and the restaraunt does not owe you more steak. Past clients are wonderful people who you may choose to do business with again, but you are not a free source of steak for them.

samwgoldman · on Sept 14, 2015

This is bound to be a controversial opinion, but I fall down strongly on the side of time and materials billing, as opposed to fixed budget (FB). I don't hold this opinion as a way to cover my own ass, but I actually think it's the best deal for my clients as well.

1. Fixed budget projects are also fixed scope (unless you're a masochist), but in literally 100% of projects I've worked on, we refined the idea as we developed it. In a FB project, now you get to do the change request dance. In a T&M project, you can adjust priorities fluidly.

2. FB projects are a weak guarantee in practice. Once your consultant's billable rate drops to $0, what do you think happens? You are the lowest possible priority. Either your changes/fixes never happen, or they're made hastily. If you're working with a larger firm, your project is now in the hands of the most junior employees.

3. FB projects are an excuse for poor communication. Clients will take the simple dollar value as an excuse to check out until the money runs out, then be disappointed when the end result isn't exactly what they had in mind. You need to show your work as you build it, gather feedback as you go, and adjust priorities.

4. T&M puts both parties on the same team, working together to build the best product. FB is too adversarial. The client tries to get as much possible stuff, because their cost is fixed. You are constantly pushing back, defending a hopefully well-defined concept of "the scope." Guess which kind of relationship gets more accomplished?

I could go on. But TL;DR, you should charge for maintenance and it should be the same way you charge for the rest of it: by the hour/day/week.

agopaul · on Sept 14, 2015

This is very interesting and I'm convinced. But the problem the companies I worked for in the past faced is that sometimes the client has a tight budget and have to share it with other projects too. So they need to have a precise view of the cost of the project not only short-term (initial development) but also long-term (maintenance).

The solution would be finding the clients willing to go down the road of non-FB projects, but hey, sometimes the market is what it is.

samwgoldman · on Sept 14, 2015

My approach to tight budgets is simple. There are just two rules: 1. Get to something that works ASAP 2. Always work on the most important thing

Once you have something that works, you can run out of money and still have created value. I don't tend to call this a MVP, but the idea is the same.

Working on the most important thing is hard, because it requires that you and the client/stakeholders communicate often and well.

If you can get this right, you shouldn't need to worry about the budget other than wholesale feasibility. (You still need to evaluate whether you can do the project at all.) Once you have something working, you just keep improving it until the cost outweighs the benefit of more work, then you're done.

pjungwir · on Sept 14, 2015

You might enjoy this article from Dr. Dobb's: Is Fixed-Price Software Development Unethical?:

http://www.drdobbs.com/is-fixed-price-software-development-u...

Although I think you make the case just as well and more succinctly. :-)

aggieben · on Sept 14, 2015

I don't think this is controversial at all. I wouldn't even give a second thought to a FB deal (unless it was for my own mother, I suppose) - the incentives are all completely misaligned. It starts off adversarial and is extremely likely to end in a failed project and/or hostile client (as you explained very ably).

sbrother · on Sept 14, 2015

This can actually be one of the most lucrative and stable sources of revenue for a small software consultancy. At the "end" of a successful project, I usually pitch a retainer agreement to the client. There are lots of variations on the terms, but I've generally done something like "for (~12-24) months, you buy (~8-24) of my hours guaranteed per month at a discount rate of (~10-15%) off my standard rate. Invoiced at the beginning of each month, use it or lose it (throw in a month of rollover if they push back)."

It's a win-win: the average client doesn't use anywhere near their entire allotment, but in general they're happy to pay for the "insurance" that you'll be available if you need them. You're never on the hook for more than you can reasonably provide: if something bad happens and they need more than their allotment, then you can renegotiate that as a new contract. And most of all, predictable monthly revenue does wonders for your cash flow.

goblin89 · on Sept 14, 2015

> I want to try to get into Software Consultancy.

> Most potential clients I've talked to want me to create a somewhat simple website for them in 2-3 weeks…

In my understanding, software consultancy is when you work with your client and their engineering team, but don’t actually build the product. You may help hire the team and you may indeed write actual code, but it’s the team that’s supposed to do the actual engineering and future support.

Deep understanding of client’s needs (a pre-requisite), steering them away from wasting resources on building the wrong or unmaintainable product, and helping them organize their processes efficiently are important parts of consultant’s job. With that in mind, building the whole thing from the ground up at the same time just doesn’t seem to be the best use of your consulting skills. The following maintenance—even less so.

Normally consulting activities seem to be billed by the time (hourly or daily). In my experience, if you do build the thing yourself, it can be difficult to ensure client’s understanding that you’re really acting as both a consultant and the engineering team, and structuring your pay adequately becomes somewhat harder.

If you build the thing, you should probably make it your responsibility to ensure that deliverables include all the information necessary for future maintenance. Then the client is free to use it with their engineering team or a freelancer, and even if later you’re willing to be hired back for maintenance yourself, you’ll appreciate the documentation you’ve left.

stdbrouw · on Sept 14, 2015

People tend to use the terms "consulting", "freelancing" and "contracting" almost interchangeably, though.

navanit · on Sept 14, 2015

You most certainly should charge for maintenance. Depending on the size of the project, you can also charge a monthly retainer to be available for maintenance should the need occur.

ramkalari · on Sept 14, 2015

I would also try to build in as many self-service features that you can so that you are not bugged with routine maintenance requests such as adding master data. Otherwise, all maintenance requests should be done for a fee. Customers also value you even higher if you proactively do maintenance such as security fixes that maybe beyond their capabilities.

buffoon · on Sept 14, 2015

I always run a per incident charge for defects (outside a 6 month approval window) and requote for features. Per incident charge is relatively high to dissuade people from filing lots of trivial things and actually QA it in the approval window.

I have run projects where there are no defects reported however so YMMV.

dandanisaur · on Sept 14, 2015

You have them sign off on the 'finished' product. Then charge for maintenance. Or if you're looking for residual income, you could charge monthly... that is to say that it's not without risks or requiring you to push back.

brudgers · on Sept 14, 2015

Charge for everything.

dboreham · on Sept 14, 2015

Of course you should charge for maintenance. But this is "Contract Development", not Consulting, fwiw.

x5n1 · on Sept 14, 2015

Time is money. Nothing more needs to be said. Also usually the actual cost that you should estimate is 3x your best estimate. If you think you can do it for $1k estimate $3k. It will more than likely end up costing 3k.

tluyben2 · on Sept 14, 2015

I know you mean it just as an example, but I would have used $10k and $30k instead; you cannot do much of anything for $1k or $3k so if you use that as a fixed price you will most likely end up losing money.

abalashov · on Sept 14, 2015

Maintenance is something for which you should definitely charge. How exactly you should charge for it depends on how much you value recurring revenue streams and how willing the client is to commit to recurring expenses.

I have never done web-related consulting, but in my industry (VoIP), customers almost always expect ongoing support of the platform/system built for them, which is analogous to a full-on deliverable like a web site (as opposed to a small patch or tweak). The general thinking is that if customers want to be able to count on your responding to them in a timely manner for down-the-road support, they need to pay for that privilege; merely being willing to pay hourly on an as-needed basis is not enough.

So, in our area of consulting, this is usually done on a flat-rate monthly retainer basis which entitles them to X hours per month of support at a discounted hourly equivalent rate (additional hours are billed at an overage rate which may or may not be higher), and it's use-it-or-lose-it; in other words, it's an insurance policy that you'll be there when they need you. The scope of such support is also confined to configuration tweaks and minor modifications; fully fledged additional product development is usually not included and is billed ad hoc at normal development rates. In some cases, if the retainer amount is sufficiently high, you can probably justify all-you-can-eat maintenance without limiting the hours, which can make customers feel better about not being billed through the nose for fixes for bugs/errors/omissions/defects, but as with any "unlimited" plan, it's also a great way to screw yourself with demanding customers that take full advantage of the buffet model. Still, it's how we do support for our product in our particular industry, because it allows us to charge a lot more per month.

I don't know how much commitment of this sort can be extracted from clients in the web industry, since I don't know what sort of revenue can be directly attributed to the web site or how critical it is to any given business that has approached you.

You can always just charge them on an hourly basis for any maintenance needed, which will sit better with customers that are resistant to recurring commitments of any sort. However, in that case, you should definitely not discount the rate; after all, they're not guaranteeing you any revenue, yet they're expecting you to drop whatever you're working on (which could, at some future moment, be quite large/lucrative/urgent) and help them. So, discounting is usually used to make the recurring approach more attractive.

From a business perspective, I highly encourage the recurring revenue approach. It has much to recommend it for reasons of cash flow.

bobwaycott · on Sept 14, 2015

How I handle every project as someone who bills himself as a consultant, which often includes developing custom software from scratch (solo or with a team):

1. Invest serious time into drafting a scope of initial features that fit a client's budget. Figure out as much as I possibly can to avoid pitfalls later.

2. Document results of #1 into a formal Statement of Work and contract for the work.

3. The SoW, depending on size and scope, may include a negotiated support window that begins at project launch. This is strictly technical bug-fixes only, and is not a window within which the client can request additional features, enhancements, tweaks, etc. It only covers bug fixes for original SoW scope where issues may arise within a specific time period (30, 60, or 90 days). [0]

4. Any changes to the original SoW that occur after acceptance and before completion are Change Orders. This is written into and agreed upon in the signed SoW. Want to modify how something works halfway through the project? Change Order. Just realized Feature X really needs to be part of the project? Change Order.[1]

5. Any changes, features, enhancements, modifications, deletions, etc.--any work at all--after the SoW is complete is always new billable work. In this case, whether or not I require formalizing the work into a new SoW really depends on the size and scope of the request, as well as the working relationship and trust level with my clients. If there is a large changeset requested, I go for a new SoW; if it is a relatively small thing I can measure in days, I typically work that out via emails that document the scope of the change, the forecasted days it will take & day-rate charged, and only begin the work when I have a documented response from them that says to do it.[2]

6. No matter what, if the client & I agree SoW is completed, the project is launched, and I've received final payment, I owe them nothing further. If I cannot schedule them in, they have to wait or find another solution. If they do not want to pay, they have to find another solution. I have the power to say no to any request, and I have no obligation to work for free.

---

0: This may be controversial to some, but I value the quality, stability, and correctness of everything I create. This offers clients peace of mind that I will be on the hook for any mistakes made, and I have incentive to ensure I do not fuck up. I would be offended if someone delivered buggy software to me and then wanted to charge me to correct their mistakes within a reasonable period of time. If I've made mistakes, they will be discovered within the support window, and I will happily fix them.

1: Honestly, I've really had some ups and downs here while learning just where to draw the line. The longer I work as a consultant, the more militant I get with requiring & enforcing the Change Order rule (which is always in my SoWs). Every time I have not enforced the CO rule when a client has requested modifying/changing something from the SoW, I have regretted it. Every time. I have basically had to learn to remind myself that I am not their employee, and they have to pay for my time, no matter how small I think something may be. My own nature and desire to help them constantly works against me when I think I should just go ahead and throw something in--because it sounds easy, because it seems small, because I think it would be helpful, because I feel guilty/weird about requiring a CO during the course of a SoW, whatever.

2: Even as I type this, I recognize this is an area where I expose myself to risk, and probably should just be militant in documenting everything in a new SoW/CO that the client actually has to sign and return to me.