
Ask HN: How do software consultants deal with maintenance? - vertoc
I want to try to get into Software Consultancy. I&#x27;ve read many of @patio11&#x27;s pieces on Consultancy which have been incredibly informative and helpful but one question remains on my mind: how do I deal with maintenance on past projects?<p>Most potential clients I&#x27;ve talked to want me to create a somewhat simple website for them in 2-3 weeks but what happens if they find a bug or they need to scale it up months down the road? How do I prevent myself from being monopolized by maintenance requests from past clients 2-3 years down the road? Should I charge for maintenance?
======
patio11
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
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
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
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.

------
sbrother
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
> 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
People tend to use the terms "consulting", "freelancing" and "contracting"
almost interchangeably, though.

------
navanit
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
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
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
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
Charge for everything.

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

------
x5n1
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
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
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
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.

