A bug fix is free. A new feature is not.
Every fixed price project needs a clear definition of what counts as a defect versus a request for new work. Without that line written down, both sides end up guessing, and guessing breeds resentment.
Every fixed price contract eventually meets a moment like this. The button does not do what you expected. You send a message asking us to fix it. We reply that it is working as specified, and what you are describing is new work.
Neither of us is wrong. We are just standing on opposite sides of a line that was never drawn clearly enough at the start.
What counts as a defect
A defect is when the software does not do what the agreed specification says it should do. If the checkout page was meant to accept a promo code and it throws an error instead, that is a defect. We fix it at no extra charge, because you already paid for a checkout page that accepts promo codes.
A change request is different. It is when the software does exactly what was specified, but you have decided, reasonably, that the specification should have said something else. Perhaps you now want the promo code to stack with a loyalty discount. That was never in the brief. Building it is new work, and new work carries a new cost.
The confusion usually comes from a specification that was too thin to begin with. If the brief only said "a checkout page with promo codes", almost any behaviour can be argued both ways. The fewer decisions we write down before building, the more arguments we invent for ourselves later.
The specification is not paperwork. It is the only record of what was promised, and it is what protects both sides when memory of the original conversation fades.
This is why we spend real time on the specification before a single screen gets built. We describe the states a feature can be in, what happens at the edges, and what a user sees when something goes wrong. Vague requirements produce vague obligations, and vague obligations produce disputes at the exact moment you are trying to launch.
How we keep the line visible
We keep the specification as a living document you can check against, not a file that gets buried after signing. When you raise something during testing, we point to the relevant line and say plainly whether it is covered. If it is not covered, we quote the change before we touch any code, so you decide with full information rather than after the fact.
None of this removes the awkward conversations. It just makes them shorter, because the disagreement stops being about intentions and starts being about a document you already read and agreed to.
If you are choosing a studio for a fixed price project, ask to see how they write specifications before you ask to see their portfolio. The portfolio shows you their taste. The specification shows you whether your future arguments will have anywhere to stand.