HN Explorer

Ask HN: Contracts for doing software consulting?

34 points by mads ↗ HN
Does anyone here have any experience or know of any good resources for making software development/consulting contracts, when doing software consulting?

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.

Should the contract specify specific features that need to be implemented? I dont think there will be any design documents written other than "back of napkin" 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?

I am new to freelance contracting, so if anyone has any experience doing something like this, I would love to get some input.

14 comments

[ 1.9 ms ] story [ 47.7 ms ] thread
xeniak
The Contract Killer by Andy Clarke gets some good feedback:

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.
seanwilson
I like plain english contracts but I find the casual almost jokey tone of it in some places gives the wrong impression.
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.