

Ask HN: Freelance web developers, what do your contracts typically look like? - marcusmolchany

When you agree to make a website for a new client do you hash out the details then agree to exactly what you are going to make? Do you let them modify things along the way? And do you support the website after it has been developed?<p>Any and all answers are welcome thanks!
======
leepowers
Contracts are secondary to clear communication. Your first task it to
understand and shape client expectations and to clearly communicate your
abilities and project deadlines. Figure that out and spell it out clearly in
your original estimate and contract. I don't usually write up a contract for
projects <$5,000 - anything under $5k can be resolved in small claims court
without getting lawyers involved. But I always write up an estimate and walk
the client through it.

Remember, a contract may help you during a legal proceeding. But that's the
worst case scenario - the best case is to preempt any legal action in the
first place by clearly communicating and by providing great service. A
contract is an instrument used to resolve disputes - it's best not to get into
a dispute in the fist place. To truly protect and your business, consider
purchasing general/professional liability insurance.

Invariably, clients are going to want changes. And that's a good thing. It can
mean more business and more profit. You need to determine if these changes are
in scope or not. Don't be afraid to ask for more money and revise your
original estimate when you encounter feature creep. But you have to be able to
clearly explain and justify any price expansion.

Building on that - don't be afraid to walk away. If a client isn't willing to
pay more for more features, find a way to make a graceful exit.

Long-term support can be another revenue stream. And as the creator of the
original product you are in the best position to provide quality,
knowledgeable support. That's valuable and worth money. Make sure to
communicate the long-term support strategy at the beginning of the project, be
it hourly billing for bugfixes & patches, or a monthly/quarterly/annual
payment for ongoing maintenance. Your original estimate should also budget for
initial bugfixes and tweaks near or after launch.

------
garethsprice
Contracts - for small projects, nothing substantial, just something basic in
the initial proposal like "I will work for you and you will pay me to do so".

New site - a basic proposal, usually about a page or so in length. A sitemap,
maybe basic user stories to describe interactive functionality. If it's a
complex site, charge for discovery/planning as part of the project and
document enough to create a reasonable scope.

Modifications - Clients will always, always have suggestions and changes along
the way. Buffer your bids to expect this (~20%) and don't be afraid to issue
change orders (short written descriptions of new functionality) with
appropriate charges for major scope creep. Managing expectations is key.

Post-launch support - Yes, you'll often make more money this way. Hosting can
be one way, for clients with lots of regular changes try to get them onto a
retainer where they buy a block of hours at a reduced rate each month,
provides cashflow and steady income for you.

