3 ms·

Something that you'll want to help them with is educating them that the software is quite a bit more valuable _with_ you than without you. Sure, another develo

Something that you'll want to help them with is educating them that the software is quite a bit more valuable _with_ you than without you. Sure, another developer could come in and take over (and the acquiring company will probably want to get their own developers on it if they have an in-house team), but finding that trustworthy developer and getting them up to speed will be non-trivial for them without you. Being open and transparent has served me well so far in the professional world. Tell them you made a mistake and ended up doing the original project far below your usual rate and that you're now currently busy with other projects. Let them know how long the original project took so they have expectations on how long new modifications might take. Tell them that although you like working with them, in order for it to be worth your while and to turn down other opportunities, you'd need it to be in line with your usual rate of 80€/h. You'll also probably want to get them to agree not to let the acquiring company know what your hourly rate is, as if they are enterprise-y you can definitely increase your rates (which is also warranted, since you'll be dealing with a lot more bureaucracy).

cvhashim 6y ago
80€/h seems really low to me. I don’t think there’s a point of charging by the hour unless you’re doing very small features adds, tests, or maintenance work. I think one should always opt to get paid on a project basis.
- justinram11 6y ago
  I think it can go both ways (as shown by OP's situation of severely underestimating the work required). If you have: excellent project management skills, can correctly estimate the required work, and have good clients who don't try to add "free" features half-way into the project, fixed-bidding 10-20% of the business value add can often work out better for you. * Often that requires the client to have a good idea of how much they are willing to spend on the project, and how much additional revenue it's going to bring in (which is harder for smaller clients to do). If any of the above is false, time-and-materials based pricing is often the better way to go in my experience -- it accounts for any "unknowns" in your estimation, and allows the client to add/change as many features as they want at any point in the project (it's easier to argue about a deadline getting pushed out than having to re-bid the project).

cvhashim 6y ago

80€/h seems really low to me. I don’t think there’s a point of charging by the hour unless you’re doing very small features adds, tests, or maintenance work. I think one should always opt to get paid on a project basis.

justinram11 6y ago
I think it can go both ways (as shown by OP's situation of severely underestimating the work required). If you have: excellent project management skills, can correctly estimate the required work, and have good clients who don't try to add "free" features half-way into the project, fixed-bidding 10-20% of the business value add can often work out better for you. * Often that requires the client to have a good idea of how much they are willing to spend on the project, and how much additional revenue it's going to bring in (which is harder for smaller clients to do). If any of the above is false, time-and-materials based pricing is often the better way to go in my experience -- it accounts for any "unknowns" in your estimation, and allows the client to add/change as many features as they want at any point in the project (it's easier to argue about a deadline getting pushed out than having to re-bid the project).