[tootie]

That's an agency-friendly type of contract and it's really, really hard to sell that way unless you have a sterling reputation and great rapport. Most clients want to know exactly what they're getting and how much it will cost. Experienced tech leaders know estimates are estimates and clients usually can't even articulate what they need clearly enough anyway. It's why client services people get paid so much and why it's so hard to find good ones.

[FpUser]

I had projects like this. We define the whole project with the client first and agree on overall price. I then split it into few stages and upon completion of each stage I would sit with the client show the work and client signs off the stage as done and pays for said stage. With this type of work I would also always charge non refundable initial deposit as sometimes the client will have the contractor started and then change their mind. I also specify 3 month "free" bug fixing after final acceptance and then maintenance fee should they desire.

[g00gler]

That’s really interesting. I’m coming at this from 2 angles —- I run a small “shop”, me and 1 or 2 other guys part time; I also work for a company who has contracted an agency for creating a design system for us.

Do you estimate there will be X hours of bug fixing and add that to the price of billable hours?

How do you take into account client requests after a billing period is complete or during a billing period?

IME US agencies wind up billing over $100/hr/dev then still charge for bug fixes.

I’ve learned over the years that I cannot give a per project price and it has to be hourly as requirements shift often or certain tasks run over

[daniellarusso]

I have done this both ways.

The most success I have had with per project pricing is having a discovery phase to actually scope out the work.

There is a decent amount of up-front work, but it really ensures everyone is on the same page.

This is usually a series of 4 meetings, anywhere from 30 minutes to an hour.

From there, I can write a spec/contract, I present that, which is another meeting (I don’t just email it).

Then once they agree, 50% up front, and 50% upon completion.

There is language in the contract that any changes to spec/feature, they require an additional contract and do not change existing work/agreement.

The pain comes from vague specs and everybody has a different interpretation, and the feat of not getting paid until satisfying the vague expectations.

So, just don’t do that.

:)

[Silhouette]

The most success I have had with per project pricing is having a discovery phase to actually scope out the work.

I concur. Also, the discovery phase itself can be flexible on time allotted and billed in time increments, even if the main project won't be. You might well not know up-front whether you need a day, a week or a month to pin down the spec and all the other details, so a self-contained "getting to know you" phase before anyone makes big commitments has a lot of upsides for all parties.

Also, regarding the problem of vague requirements and differing interpretations, getting a complete set of acceptance tests agreed early-on has a lot of upsides for both parties too.

[user5994461]

I think you need to think hard what is a bug. Need to update the URL to the outlook API because microsoft is changing it every now and then? Need to send a new icon/logo because reasons and the client doesn't know how to update an icon himself?

These are dumb things that can be easily sorted out.

On the other hand it's super risky because you don't control the environment of the client (dude can't open a firewall port to make the application work, security department needs 3 weeks of ticket to open the firewall). One unlucky client and you will be in a world of pain.

I think the OP is working on small projects of a reasonable nature/domain or he would have learned the hard way to not promise upfront. (Well, it's possible to do and thrive, never getting burned by a dysfunctional client)

Benefits: You can double the project price to factor in the bugfixing/maintenance included. The client is okay with it because it comes as a great deal, project and maintenance guaranteed. The only reason to work per project as a consultant is to bill wayyy more, because you take on more risk, gotta manage the quality the scope and the client tightly.

[tootie]

I put defect severity definitions right in the contract. Critical, major, minor, cosmetic. Then put like a 24-hour SLA on critical and major only. Maybe 2 business days on a minor or cosmetic. And a max of 30 days post delivery after which we require a change order to address further issues.

[FpUser]

>"Do you estimate there will be X hours of bug fixing and add that to the price of billable hours?"

I'll give you an example of particular product I made for a client:

The agreement I had stated that I would support (fix bugs, no feature change) for 3 month. After that it was $X per hour with $XX minimum charge. Alternatively client could always sign for a year of support at $xxx per year.

Currently I have a contract where they simply pay me flat fee per year with the clause that each side can terminate it with 1 month advance notice.

But in my long career I've had all kinds of contracts. Including getting licensing fee while I maintained and own product (I paid for development myself)

[daniellarusso]

I think it is all in the ‘selling’ of it, it may be a sprint, but it is sold as a ‘milestone’.

[FpUser]

I actually meant milestone. I do not do Sprints as in Agile. Normally I design and develop new products from a scratch and there is no use of Agile propaganda in it.

[tootie]

Funny because I do product dev from scratch and wouldn't dream of doing it without agile being explicitly bought into by the client. How you do a non-trivial project setting fixed milestones upfront?

[FpUser]

Being very experienced product designer/developer after few talks with the client I could fairly accurately split big project in few comprehensible stages with the price for each. I do not remember ever being off by any significant margin. I've done way too many of projects either directly or as a director during the course of my life so it is mostly an autopilot at this stage for me. Also my clients tend to be real business people with real business needs. They do not really like to go into methodology level. they just look at my resume, and check references. They are much more interested in how I can solve their problem on conceptual levels before really engaging.

[user5994461]

I concur. Milestones are comically similar from project to project.

Software in internal development, software available in testing, beta deployment on the customer site with real customers/data, go live in production, first user, first thousand users, etc...

For hardware projects (I did a lot of joint software/hardware) hardware design, ready to manufacture, first prototype, second prototype, first production series, first delivery to customers, etc...

Last but not least, the primary use cases are major milestones, the software allows to do A then B then C. Gotta determine the main use cases of the project as early as possible.

Large projects (10+ people over years) are split into components, each component has its own milestones and should stand on its own as a deliverable. Add major milestones for integrations, as soon as any 2 dependent pieces are in a working state, they need to be integrated together and tested.

[tootie]

I mean, I've worked on plenty 7-8 figure programs for Fortune 50 companies of all kinds and that has not been my experience at all. I've even worked for FAANG clients who didn't know what they wanted until we tell them. The kind of work I did (I am exiting the consulting world as of this week) was very consumer-facing and creative driven. I can estimate tech work as well as anyone, but there's always too many moving parts to a big project to know how everything will fall into place.

[daniellarusso]

Great response!