Prototype work, flexible hours

[limiteddeveloper]

I'm currently in discussions with a potential client regarding a new project they are starting. I met them through another client I worked for during an integration project.

They'd initially like me to do some proof of concept / prototype work to test whether the technology is available and decide whether to commit to the project. So far they have requested a very small prototype and we agreed that they would be paying me on an hourly basis. At this stage it isn't clear what else they want to prototype and how long it would take to prototype everything.

Previous contracts have always been for x months, with the expectation that during that my services would be required every weekday.

My question is whether I need a different style of contract for doing small pieces of work "as requested" (and if I really need one at all). I'd prefer not to have a specific contract for each proof of concept.

Any advice would be much appreciated.

[jamesbrown]

Generally, if I'm working something quite small and finite, I'll quote a fixed price, but you need to include a sufficient margin for risk. This works well on both sides, because the client has a guaranteed set of deliverables for a fixed price, and you have a well-defined scope and opportunity to increase your margin (but there is certainly risk involved). This will require some additional time on scoping, but that is a good idea anyway with prototyping work; without careful scoping, there's a good chance that a project will run on and lead to differences in expectations.

[d000hg]

You do need a contract and it doesn't need many modifications. Many times, contractors have a main contract, supplemented by a Schedule which defines the duration and working hours of the contract, etc.

If you look at your current/last contract, you probably just want to remove any bits which say how long you'll be there.

You may wish to add a clause which adds sensible notice periods and service level i.e. they can't phone up after 2 weeks of no work and demand you come in "this afternoon". But largely speaking a normal contractor B2B contract covers all this stuff, as long as it is written well to begin with.

[TykeMerc]

No reason you couldn't have one contract to cover multiple proof of concept pieces, just needs to be worded sensibly.

The contract doesn't have to be anything monumental, full of complex clauses and sub-clauses or be in legalese, but you do want it to be clear.

Sit down and list what you think they want, I'd recommend doing it in bullets so you can add or subtract them with sub bullets if necessary.
List want you're prepared to do.
Think about how long a notice period to take on a piece of work and agree the requirements
Think about what good will look like, set some acceptance criteria
Think about how you want to be paid (on completion, hourly charges etc)
Think about if a retainer fee is sensible to ask for if you think they will take their time asking for stuff

Essentially come up with a bunch of stuff you think would be fair and reasonable (that includes you making money) write it down, and you have a contract, it's actually not as hard as it looks.

[limiteddeveloper]

Thanks for the feedback.

They are looking to move from a desktop application to something web-based but don't have any experience with web development. They want to ensure that a web version of the application can match the functionality of the desktop application. The first thing they've asked is for a mock up of a screen. They have said that there will be a number of this type of request before they decide whether to kick off with the project but they haven't fully thought them through yet. This first one is straight-forward enough and the scope / deliverable is pretty clear.

At this stage, I'll be working on it in my spare time. The company is US based so I'll be working remotely. I'll be invoicing on an hourly basis but we've not discussed whether this would be at a regular time interval or on completion, or what happens if I spend time on something which I am not able to deliver, or they are not happy with (since it is a proof of concept).

Having worked with me before they have trusted me enough not to ask me to commit to either a delivery time frame nor an estimate for the number of hours it would take (I wouldn't have thought the first one would take more than a few hours).

It sounds like at this stage a simple contract which states that I will be spending time developing a series of proof of concepts, with no fixed time frame would be most the appropriate.

Would the deliverable need to be in writing if the contract was general enough to cover a number of them?

Would it be unreasonable to invoice for time spent on something that turned out to be impossible to deliver?

Thanks

[jamesbrown]

Thanks for the feedback.

They are looking to move from a desktop application to something web-based but don't have any experience with web development. They want to ensure that a web version of the application can match the functionality of the desktop application. The first thing they've asked is for a mock up of a screen. They have said that there will be a number of this type of request before they decide whether to kick off with the project but they haven't fully thought them through yet. This first one is straight-forward enough and the scope / deliverable is pretty clear.

At this stage, I'll be working on it in my spare time. The company is US based so I'll be working remotely. I'll be invoicing on an hourly basis but we've not discussed whether this would be at a regular time interval or on completion, or what happens if I spend time on something which I am not able to deliver, or they are not happy with (since it is a proof of concept).

Having worked with me before they have trusted me enough not to ask me to commit to either a delivery time frame nor an estimate for the number of hours it would take (I wouldn't have thought the first one would take more than a few hours).

It sounds like at this stage a simple contract which states that I will be spending time developing a series of proof of concepts, with no fixed time frame would be most the appropriate.

Would the deliverable need to be in writing if the contract was general enough to cover a number of them?

Would it be unreasonable to invoice for time spent on something that turned out to be impossible to deliver?

Thanks

Whether you've worked with the client before is neither here nor there in terms of needing a contract and a schedule of work. Aside from the obvious reasons for a contract, what are you going to do about business insurance? You won't get insurance for US jurisdiction and governing law in a US state without a contract and schedule of work and, trust me, you need insurance, particularly when working for US clients on US terms.

In terms of your specific questions, I would get an overarching contract in place that allows for task orders on a fixed price or time and materials basis or some combination of the two. When a new request comes in, you add this task order to the schedule of work (via a change/mod). Once the over-arching contract is in place, the additional admin should be trivial. Then, in terms of what is reasonable for invoicing, it depends what your contract says, and this is precisely why you have a contract. If the task order is to produce a visual mock-up without working to practical criteria (such as cost/delivery timeframes), then that is the basis for your work/invoicing on that particular task.

[d000hg]

Actually, working on an hourly rate makes it easier to have one contract used for various projects... at its heart the contract just confirms they want you to do this work and will pay you for it, and codifies how the work and payment should happen.

When I've hired freelancers in a similar way, one thing I've done is suggest they raise an invoice whenever the outstanding amount reaches a certain amount that makes it worthwhile, and avoids wasting money on international payment fees.

[limiteddeveloper]

Whether you've worked with the client before is neither here nor there in terms of needing a contract and a schedule of work. Aside from the obvious reasons for a contract, what are you going to do about business insurance? You won't get insurance for US jurisdiction and governing law in a US state without a contract and schedule of work and, trust me, you need insurance, particularly when working for US clients on US terms.

In terms of your specific questions, I would get an overarching contract in place that allows for task orders on a fixed price or time and materials basis or some combination of the two. When a new request comes in, you add this task order to the schedule of work (via a change/mod). Once the over-arching contract is in place, the additional admin should be trivial. Then, in terms of what is reasonable for invoicing, it depends what your contract says, and this is precisely why you have a contract. If the task order is to produce a visual mock-up without working to practical criteria (such as cost/delivery timeframes), then that is the basis for your work/invoicing on that particular task.

Thanks for the advice, seems like a sensible way forward.

It sounds like you have experience working for a US client first before. I haven't signed any contract with the US company yet, assuming we only sign the contract I give them, would it still be considered that I am working on US terms? I have looked into additional US insurance but from what I understood it was only necessary if working in the US or the work is governed by a US contract.

[jamesbrown]

Thanks for the advice, seems like a sensible way forward.

It sounds like you have experience working for a US client first before. I haven't signed any contract with the US company yet, assuming we only sign the contract I give them, would it still be considered that I am working on US terms? I have looked into additional US insurance but from what I understood it was only necessary if working in the US or the work is governed by a US contract.

Yes, I currently work with several US clients. Certainly, put forward your own contract and try to get the jurisdiction and governing law here (England and Wales). There's a contract template available from IPSE for direct engagements, for example. In practice, while you may be able to put forward the bulk of the contractual terms, you're unlikely to secure England and Wales as the jurisdiction (at least, in my experience, as US clients are always very edgy w/r to legalities), in which case you will need insurance coverage for a prescribed US state as the jurisdiction and US governing law. For that, your best bet is to join IPSE (if you're not already a member) and look for the IPSE-subsidised cover through Randell Dorling.

[jamesbrown]

Actually, working on an hourly rate makes it easier to have one contract used for various projects... at its heart the contract just confirms they want you to do this work and will pay you for it, and codifies how the work and payment should happen.

When I've hired freelancers in a similar way, one thing I've done is suggest they raise an invoice whenever the outstanding amount reaches a certain amount that makes it worthwhile, and avoids wasting money on international payment fees.

There's no problem in having payment terms as part of a task order, allowing flexibility, depending on the nature of the task. In general, it's easier to work with hourly rates. However, there are circumstances (which I generally try to engineer, both for margins and for encouraging the client to think clearly about deliverables) where I prefer fixed price. It really depends on the nature of the task, though, and I would agree that the more blue-skies stuff (which is more likely with prototyping) will be more difficult to pin down with a fixed price model. Regardless of the pricing model, IMHO, you want to glean as much as you possibly can from the client and put this down in writing, while obviously leaving some flexibility (there's an element of artistry to it), as this will minimize issues down the line, in terms of what was agreed.

Also, you're right about payments. OP: if the money becomes significant, consider opening a USD account with your business bank.