How I handle every project as someone who bills himself as a consultant, which often includes developing custom software from scratch (solo or with a team):

1. Invest serious time into drafting a scope of initial features that fit a client's budget. Figure out as much as I possibly can to avoid pitfalls later.

2. Document results of #1 into a formal Statement of Work and contract for the work.

3. The SoW, depending on size and scope, may include a negotiated support window that begins at project launch. This is strictly technical bug-fixes only, and is not a window within which the client can request additional features, enhancements, tweaks, etc. It only covers bug fixes for original SoW scope where issues may arise within a specific time period (30, 60, or 90 days). [0]

4. Any changes to the original SoW that occur after acceptance and before completion are Change Orders. This is written into and agreed upon in the signed SoW. Want to modify how something works halfway through the project? Change Order. Just realized Feature X really needs to be part of the project? Change Order.[1]

5. Any changes, features, enhancements, modifications, deletions, etc.--any work at all--after the SoW is complete is always new billable work. In this case, whether or not I require formalizing the work into a new SoW really depends on the size and scope of the request, as well as the working relationship and trust level with my clients. If there is a large changeset requested, I go for a new SoW; if it is a relatively small thing I can measure in days, I typically work that out via emails that document the scope of the change, the forecasted days it will take & day-rate charged, and only begin the work when I have a documented response from them that says to do it.[2]

6. No matter what, if the client & I agree SoW is completed, the project is launched, and I've received final payment, I owe them nothing further. If I cannot schedule them in, they have to wait or find another solution. If they do not want to pay, they have to find another solution. I have the power to say no to any request, and I have no obligation to work for free.

---

0: This may be controversial to some, but I value the quality, stability, and correctness of everything I create. This offers clients peace of mind that I will be on the hook for any mistakes made, and I have incentive to ensure I do not fuck up. I would be offended if someone delivered buggy software to me and then wanted to charge me to correct their mistakes within a reasonable period of time. If I've made mistakes, they will be discovered within the support window, and I will happily fix them.

1: Honestly, I've really had some ups and downs here while learning just where to draw the line. The longer I work as a consultant, the more militant I get with requiring & enforcing the Change Order rule (which is always in my SoWs). Every time I have not enforced the CO rule when a client has requested modifying/changing something from the SoW, I have regretted it. Every time. I have basically had to learn to remind myself that I am not their employee, and they have to pay for my time, no matter how small I think something may be. My own nature and desire to help them constantly works against me when I think I should just go ahead and throw something in--because it sounds easy, because it seems small, because I think it would be helpful, because I feel guilty/weird about requiring a CO during the course of a SoW, whatever.

2: Even as I type this, I recognize this is an area where I expose myself to risk, and probably should just be militant in documenting everything in a new SoW/CO that the client actually has to sign and return to me.