6 ms·

1) Clients come to you because they have a painpoint and they wand to build something to help it. 2) You discuss with the clients what's their needs. 3) Figur

1) Clients come to you because they have a painpoint and they wand to build something to help it. 2) You discuss with the clients what's their needs. 3) Figure out what you can do and agree with the client on the billing/project. (how many people? of what skills? how long? what to build? for how much?) 4) Do the work. Projects could be anywhere from weeks to years. 5) Long time goes bye. 6) Done. There's two ways to handle the billing and making money aspect. First option. Bill per time. You basically promise to have X people of various skillset working on the project for some period of time. They're each billed $$$ per day so it's simple math. Second option, harder to manage. Bill per project. You basically promise to deliver a bunch of features or some result that's agreed upon at the start. This one is tricky because you have to define everything at the beginning and clients usually don't know what they want and change their mind. Now, who wants to have a longer blog post about the difference between contracting and tech companies?

Aaargh20318 6y ago
A third option is to bill per sprint. You define the goals for a single sprint, which should be relatively easy (compared to defining the entire project) and bill when the sprint is completed. The advantage is that you have clearly defined goals, but the client can still change direction of they need to (by adjusting the next sprint).
- Nbox9 6y ago
  Every sprint team I’ve been on is loaded with unexpected stories, and this was doubly true when I was working on a sprint team building for a client.
- user5994461 6y ago
  Arf I didn't cover "when" the client is billed. For short projects (weeks), usually a percentage before and a percentage afterwards, maybe a percentage in the middle. It's all negotiable, welcome to consulting! For long projects (years), you will need to agree on a billing schedule from the moment you draft and sign the contract up to the delivery. There should be periodic billings and milestones. Definitely do not work a whole year for free :D Unlike the comment above (anti pattern!), you don't want to redefine the goals every week and make payment contingency on the goals (it's too much time drafting formal agreements and it allows the client to not pay you by arguing the goal is not reached). What you usually prefer is to bill for the time spent on the project (weekly or monthly) irrelevant of any goals. There's a fundamental struggle in consulting: you should get regular feedback and make sure you're building something the client is happy with... while you need to make sure you get paid, irrelevant of what exactly was completed and of the shifting will of the client... while you can't waste all the time doing paperwork/contracts to cover your ass. Long story short you always end up billing by time, except for some short specialized work you're very confident you can handle.
  - Silhouette 6y ago
    Long story short you always end up billing by time, except for some short specialized work you're very confident you can handle. Or the other end of the spectrum, where you're talking about year-plus projects with year-plus-sized price tags, and it may be worth the overheads for both sides to agree a starting spec, timescales and milestones up-front. You do need to make sure you also have a clear change management process in place, including a shared understanding that any changes are subject to approval by the developer and will increase the bill and timescales.
- tootie 6y ago
  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 6y ago
    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 6y ago
      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
      - user5994461 6y ago
        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.
deleted 6y ago
[deleted]
gadders 6y ago
There is also value-based billing. A lot of people talk about it, but never seen in the wild. EG A business has a manual process that costs them £2m/year to run. Instead of calculating how long it would take you fix, you price based on what it is worth to the business to fix the issue (obviously this needs to be larger than what you would charge on a time and materials basis). Brennan Dunn was a big advocate of this, but mainly on a small consultancy scale (https://doubleyourfreelancing.com/rate/ https://doubleyourfreelancing.com/rate/).
- Radim 6y ago
  1) Are you doing something innovative? By definition there's no clear value to baseline against. Clients don't know what's even possible, much less how much $$$ it might bring them. So the value in "value-based" is correlated with some internal strategy / personal / brand politics. Good luck quantifying that as an external SW dev firm. 2) Doing something run-of-the-mill? Improving a process that's already in place? The client may have an idea about its ultimate specs & ROI. Even if they're able to articulate those to you – why would they? In practice, value-based pricing comes down to "charge as much as they're willing to pay". Which is fine, that's the essence of sales. But more to do with social skills & play-it-by-ear, rather than some objective numbers you might hope to extract from a client.
dawnerd 6y ago
And don’t forget about retainer based work. You agree on a cost per hour and setup a retainer on that. It’s similar to sprint based but more open ended. Works great for clients wanting lots of design rounds and tweaks.

Aaargh20318 6y ago

A third option is to bill per sprint. You define the goals for a single sprint, which should be relatively easy (compared to defining the entire project) and bill when the sprint is completed. The advantage is that you have clearly defined goals, but the client can still change direction of they need to (by adjusting the next sprint).

Nbox9 6y ago
Every sprint team I’ve been on is loaded with unexpected stories, and this was doubly true when I was working on a sprint team building for a client.
user5994461 6y ago
Arf I didn't cover "when" the client is billed. For short projects (weeks), usually a percentage before and a percentage afterwards, maybe a percentage in the middle. It's all negotiable, welcome to consulting! For long projects (years), you will need to agree on a billing schedule from the moment you draft and sign the contract up to the delivery. There should be periodic billings and milestones. Definitely do not work a whole year for free :D Unlike the comment above (anti pattern!), you don't want to redefine the goals every week and make payment contingency on the goals (it's too much time drafting formal agreements and it allows the client to not pay you by arguing the goal is not reached). What you usually prefer is to bill for the time spent on the project (weekly or monthly) irrelevant of any goals. There's a fundamental struggle in consulting: you should get regular feedback and make sure you're building something the client is happy with... while you need to make sure you get paid, irrelevant of what exactly was completed and of the shifting will of the client... while you can't waste all the time doing paperwork/contracts to cover your ass. Long story short you always end up billing by time, except for some short specialized work you're very confident you can handle.
- Silhouette 6y ago
  Long story short you always end up billing by time, except for some short specialized work you're very confident you can handle. Or the other end of the spectrum, where you're talking about year-plus projects with year-plus-sized price tags, and it may be worth the overheads for both sides to agree a starting spec, timescales and milestones up-front. You do need to make sure you also have a clear change management process in place, including a shared understanding that any changes are subject to approval by the developer and will increase the bill and timescales.
tootie 6y ago
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 6y ago
  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 6y ago
    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
    - user5994461 6y ago
      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.

deleted 6y ago

[deleted]

gadders 6y ago

There is also value-based billing. A lot of people talk about it, but never seen in the wild. EG A business has a manual process that costs them £2m/year to run. Instead of calculating how long it would take you fix, you price based on what it is worth to the business to fix the issue (obviously this needs to be larger than what you would charge on a time and materials basis). Brennan Dunn was a big advocate of this, but mainly on a small consultancy scale (https://doubleyourfreelancing.com/rate/ https://doubleyourfreelancing.com/rate/).

Radim 6y ago
1) Are you doing something innovative? By definition there's no clear value to baseline against. Clients don't know what's even possible, much less how much $$$ it might bring them. So the value in "value-based" is correlated with some internal strategy / personal / brand politics. Good luck quantifying that as an external SW dev firm. 2) Doing something run-of-the-mill? Improving a process that's already in place? The client may have an idea about its ultimate specs & ROI. Even if they're able to articulate those to you – why would they? In practice, value-based pricing comes down to "charge as much as they're willing to pay". Which is fine, that's the essence of sales. But more to do with social skills & play-it-by-ear, rather than some objective numbers you might hope to extract from a client.

dawnerd 6y ago

And don’t forget about retainer based work. You agree on a cost per hour and setup a retainer on that. It’s similar to sprint based but more open ended. Works great for clients wanting lots of design rounds and tweaks.