Contracts tend to get signed in the space between a good meeting and a busy week. The designer seems capable, the proposal reads well, and the start date is close. Everyone wants to move.
That haste has a price. Trouble in a web project rarely comes from the fee or the deadline. It gathers around ownership, the edges of the scope, and the weeks that follow launch.
The questions below cover those areas. None require technical knowledge. Each asks for a written answer before money changes hands.
1. Who holds the rights to the finished site?
Payment feels as though it should settle ownership. In web design, it often does not. Rights can be divided in ways that leave a live site surprisingly hard to control.
A site may launch while leaving you unable to edit pages, move hosts, or take the work to another studio. The cause is usually retained rights: source files, code, or a theme licence that remains with the designer. A full transfer avoids that outcome by covering files, credentials, image permissions, and copyright. It should also include the DNS records and any email accounts tied to the domain, since both are easy to forget.
Ask the question directly. Does the agreement hand over the design, the code, and the content? Where a purchased theme or page builder is used, does the licence follow the site to you? If the designer wrote the copy, who holds the rights to it?
Soft wording is itself an answer. A brief clause confirming transfer costs little now. It prevents a much larger problem later, when you want to sell, redesign, or archive the site without asking permission.
2. What does the proposal cover, and what costs extra?
Proposals are written to be read quickly. The items left off the page often matter most. A website design package usually lists the basics: a homepage, a set number of inner pages, a contact form, and responsive layouts. Read that list, then look for the gaps.
Extras accumulate through familiar channels. Stock imagery, custom icons, copywriting, technical SEO, analytics setup, e-commerce, blog templates, translation, and third-party integrations all appear regularly. Some you will never need. Others may be assumed included until an invoice says otherwise.
This is where affordable web design can lose its early clarity. Before signing, ask the designer to mark each item as included, excluded, or priced separately. Keep that marked list attached to the contract. It gives you a fair basis for comparing two proposals side by side.
Ask how later additions are handled. If you request an extra page halfway through, does the quote change in writing? A simple approval step for new items prevents most billing disputes. Loose wording around “additional pages” or “custom features” is where budgets tend to come apart.
3. What happens once the site is live?
Launch day feels like a conclusion. In practice it is a handover, and handovers need terms. Many agreements stop at the live address and say nothing about the following months.
Start with training and documentation. Will someone walk you or your team through editing pages? Is written guidance supplied? For how long can you still ask questions once the site is public? A week, a month, and a quarter are very different offers.
Maintenance is the larger issue. A site needs updates to its CMS, plugins, and security patches, plus occasional attention to hosting. Backups also need a schedule, and someone has to confirm they actually run. Support arrangements belong inside affordable web design rather than beside it.
An unattended site does not stay still. It decays, gets compromised, or breaks quietly. Money saved by skipping support is usually spent later on an emergency repair. That repair often goes to someone unfamiliar with how the site was built.
Get the responsibilities written down. Who acts, for how long, and at what point the arrangement ends. Verbal assurances fade quickly once the invoice has been paid.
4. How was the timeline built, and where does it break?
A schedule is a prediction, not a promise. Designers draft theirs assuming feedback arrives on time and decisions stay fixed. Neither assumption tends to survive contact with a real project.
Ask for the plan in stages: discovery, design, development, content entry, review, and launch. Then ask which stages depend on you rather than the designer. Content entry is the usual culprit, though a photography shoot or a legal review can also hold things up. A realistic website design package will name those dependencies rather than leave them implied.
Revisions consume time as well, so their definition belongs in the schedule. So does the question of what happens when a stage overruns its slot.
The goal is not a shorter date. It is a clearer map of where work can pause and who is expected to unblock it. A designer who cannot name their usual delays is probably guessing.
5. How does the contract define a revision?
Revisions cause more quiet overspend than almost any other clause. The number of rounds sounds precise. The word “round” is not.
One round might mean a single consolidated pass on the homepage. Another might mean thirty small edits scattered across the site. Ask for a definition, then ask what happens when the rounds run out. Is the next change billed hourly, at a fixed rate, or treated as fresh work?
The boundary between a tweak and a new requirement also matters. Changing a button label is clearly a revision. Adding a booking system is not. Where that line falls should be stated, not assumed.
Ask whether revisions cover design alone or extend to development, copy, and functionality. A website design package with a tight revision clause is easier to manage than one that leaves the term open. Such a clause protects the designer's time as much as your budget.
A word on cost
You may have noticed that none of the questions above concern the quote. That is deliberate. A low figure can conceal unresolved issues around ownership, inclusions, and revisions. A vague proposal can look cheap while leaving those issues open.
Affordable web design is defined by clear terms and a scope that fits your needs. It is not defined by the smallest number on a proposal. A precise quote is easier to assess than a cheap one. Settle the five questions first, then turn to the figure.
Putting the questions to work
There is no need to turn this into an interview. Raise the points before drafting begins. A seasoned designer will answer quickly, because the questions come up regularly.
Pay attention to how the answers are given. Evasion, irritation, or a sudden shift between the sales call and the document all carry information. Ask for the final wording to sit in the contract rather than an email thread.
A few minutes spent at this stage is a sensible habit within affordable web design. The contract is the version of the relationship that holds when the project gets difficult.
Top comments (0)