
Ask HN: Contracts for doing software consulting? - mads
Does anyone here have any experience or know of any good resources for making software development&#x2F;consulting contracts, when doing software consulting?<p>I might potentially be hired to do some contracting (both development and administration) on a software system. Knowing my client very well, I am a bit worried that I might end up without any clear goals for when my job is finished.<p>Should the contract specify specific features that need to be implemented? I dont think there will be any design documents written other than &quot;back of napkin&quot; style task descriptions. How about bug fixing? Would there be a specific amount of time after feature completion that the client would have to report any bugs that I would then fix?<p>I am new to freelance contracting, so if anyone has any experience doing something like this, I would love to get some input.
======
WhitneyLand
The keyword to search on is statement of work, or SOW.

Here's a nice start: [http://programmers.blogoverflow.com/2012/08/fix-price-
vs-tim...](http://programmers.blogoverflow.com/2012/08/fix-price-vs-time-and-
material-contracts)

~~~
mads
Thanks! That was a good start. The comments in the that post also provided a
bit of insight into how to approach this.

------
xeniak
The Contract Killer by Andy Clarke gets some good feedback:

[https://gist.github.com/malarkey/4031110](https://gist.github.com/malarkey/4031110)

~~~
divbit
I wish I could easily star gists from mobile, I always see these kind of
things when reading hn on rest break with just phone.

~~~
alkhatib
I've been using the share button in the browser, then choosing save to inbox.
That is of course if you are using google inbox.

~~~
divbit
I would typically use pocket for this, but then half of the gists I need to
remember are in one place, and half (the ones I've starred on desktop) are in
another, so it's not a good solution. The alternative is to completely use
pocket, and not use github stars, but in any case, since I like github as a
service, the comment was more of a hint to any random githubber who may read
browse hn and want to do an easy modification.

------
EduardoBautista
Bonsai seems to be a good choice for you. They provide a decent contract
template.

[https://www.hellobonsai.com/](https://www.hellobonsai.com/)

------
spotman
Yes, you will need an SOW, (statement of work) that articulates very clearly
what you aim to accomplish. Near the latter part you should have another
section ( there is more than one way to accomplish this however ) that clearly
states what the "acceptance criteria" is for meeting the goals - ie - spells
out usually in bullet points reachable goals for the project that when met
everyone agrees your end of the deal is met.

Along with this it should also cover your rates, payment schedule, terms, and
what things cost if they fall out of scope.

Finally I find it useful to add a "prerequisites", and "disclaimers" section
that say that work can't begin until you have things like write access to
their git repo or access to their aws account ( or whatever ) and that the
current SOW doesn't cover getting it into the App Store or bugs that come
after the acceptance criteria are met.

Put places on this document for your company or self, and the other party and
make sure you properly distribute and record the signed docs.

IANAL but have one, and the more you get into consulting and bigger contracts
it's good to run things by a lawyer if it's something that's high value, with
a lot of effort, or even remotely puts you at risk.

Be even more careful signing documents clients give you;)

Have fun

------
facorreia
If the scope is not clear enough for putting together a statement of work of
acceptance criteria as described in other comments, one thing that you could
do is to start with a time-boxed contract, ranging from a couple weeks to a
couple months, depending on the complexity of the project, to do requirements
analysis. The deliverable of this contract would be a list of functional and
non-functional requirements, at a reasonable level of detail.

The issue is that, for bigger projects, you start running into the problems
related to a "waterfall" approach. As an alternative, you could look into how
"agile" organizations approach their contracts -- basically by selling the
ability to work on "stories" for as long as the customer wants them to -- and
the deliverables for each story are very fine-grained.

Either way, without active involvement of the customer to either elicit
requirements up front or validate your stories as you go, you'll be in for a
rough time. It's probably better to have an honest discussion with them about
this, because it's in their best interest after all.

------
seanwilson
> I might potentially be hired to do some contracting (both development and
> administration) on a software system. Knowing my client very well, I am a
> bit worried that I might end up without any clear goals for when my job is
> finished.

If the requirements are vague then don't agree to a fixed price and charge by
the day or hour instead. Ask for a small task that needs to be done, provide
an estimate, perform the work while keeping the client up to date if the
estimate is still accurate so they can decide what to do next and go from
there for each task. Hopefully trust will build up both ways as you work
through tasks.

You could both burn a lot of time writing up contracts for every small task
instead of just getting on with it.

------
notacissp
I can recommend grabbing a copy of this book:
[https://www.goodreads.com/book/show/14617573-a-guide-to-
it-c...](https://www.goodreads.com/book/show/14617573-a-guide-to-it-
contracting)

~~~
mads
Thanks, I will get it.

~~~
notacissp
Glad I could help.

