What a website proposal in Finland has to settle before you sign
A proposal exists to remove surprises, and it does that by writing down who does what, by when, for how much, and what you own at the end. Anything a proposal leaves vague becomes an argument later, usually at the worst moment of the project.
The test is simple. Could a third person read this document, with no memory of the sales meeting, and know exactly what will be delivered? If the answer is no, the document is a price, not a proposal.
The line items that must be there
Eight items belong in every website proposal, whatever the size of the project.
- Scope. The page types, the number of pages, the languages, and every function named.
- Content. Who writes the text and who supplies the photographs.
- Design. How many concepts, how many revision rounds, and what happens beyond them.
- Technology. What the site is built with and what that means for who can change it later.
- Timeline. Dates with dependencies, showing what waits on you.
- Price. Split by item, with the VAT basis stated and a payment schedule.
- Ownership. Who owns the design, the code, the content and the domain after the last invoice.
- After launch. What is covered, for how long, and what recurring costs begin.
Anything missing from this list is not a detail that was forgotten. It is a decision that is being postponed, and postponed decisions are billed at the rate of the day they resurface.
Scope written as functions, not adjectives
Good scope reads like an inventory. Home page, six service pages, staff listing with eight people, contact page with a form that sends to two addresses, cookie notice, privacy page, Finnish and English. Anyone can check whether that was delivered.
Bad scope reads like a brochure. A modern, responsive, search optimised website tailored to your brand. Every word of that is true of almost anything, which is why it appears so often.
Look especially for what is excluded. A proposal that lists what is not included is written by somebody who has run projects before and knows where the arguments come from.
Who writes the text, and who takes the photographs
This single question moves more money than any other line, so it should be unmissable in the document. Either the supplier writes from interviews and you approve, or you deliver finished text by a stated date. Half of each is fine too, as long as the halves are named page by page.
The same for photographs. Your own pictures, a shoot the supplier organises, or stock images. If the proposal says images included without saying which, assume stock, and assume your competitor in the next town is using the same ones.
Ask what happens if your text is late. A well written proposal says plainly that the timeline moves and how, which is better for both sides than discovering it in week six.
Hosting, domain and who pays them
The proposal should name the hosting, the annual or monthly cost, whose account it sits in, and the same three facts for the domain. This is the part clients skim and regret.
For a .fi domain, Traficom is clear that a domain name must be registered to its actual holder, and that companies, organisations and private persons can hold one regardless of where they are based. You buy it through a registrar, who sets their own prices and usually bundles hosting and email alongside. The registrar can change, the holder should be you.
Traficom also notes that when a registration expires, the domain becomes available for anyone to register after a grace period. That is the practical reason to know whose card renews it and whose inbox gets the reminder. If the answer today is your old supplier, fix that before the project rather than after. We cover the whole handover in who owns your website and your domain.
Ownership of the design, the code and the content
The proposal should say, in one sentence, that on final payment you own the design, the content and the right to use the code, and that you get a copy of everything. If it says nothing, the default is not automatically in your favour.
Watch for licence language. Some suppliers grant a licence to use a site that remains theirs, which is a legitimate model when it is declared and priced accordingly, and a trap when it is buried. The consequence is that you cannot move to another supplier without rebuilding.
Ask the exit question directly. If we part company in two years, what do I receive, in what format, and how long does it take? An answer that is a list is a good answer. An answer that is a reassurance is not.
Search visibility and accessibility as line items
These two are where vague promises live, so insist on specifics. For search, the proposal should name what is actually done during the build. Page titles and descriptions written per page, sensible URLs, structured data where it fits, a sitemap, speed targets, and the analytics or search tools connected at launch. Anything about rankings is a promise nobody can keep.
For accessibility, ask which standard is being applied and whether testing is included. In Finland the accessibility requirements for digital services were extended from 28 June 2025, according to saavutettavuusvaatimukset.fi, the official guidance site. Whether the rules bind your particular business is worth checking against that source or with your own adviser, because the answer depends on what you do and who you serve.
Price, VAT and the payment schedule
The price should be split by item so you can see what removing something saves. A single total tells you nothing and makes negotiation a blunt instrument.
Check the VAT basis. Business to business quotes in Finland are normally stated without VAT, and the general rate of VAT is 25.5 per cent according to the Tax Administration, which raised it from 24 per cent on 1 September 2024. Comparing one supplier's net figure with another's gross figure is a mistake that is easy to make and expensive to make twice.
On the schedule, staged payments tied to milestones are normal. A deposit to start, a payment at design approval, the balance at launch. Full payment up front puts all the risk on you, and payment only at the end puts it all on the supplier, which tends to produce cautious, slow work.
What happens after launch
The proposal should define a warranty period and what it covers. Something like thirty days in which anything that does not work as specified is fixed at no cost, with a clear line between a fault and a new request.
It should also list what recurring services begin and when. Hosting, backups, security updates, monitoring, a support channel with a stated response time, and small content changes if they are included. Say how a change is requested and how long it takes.
The cost of skipping this is the subject of its own article, what website maintenance covers. In short, a site with no upkeep does not stay still. It drifts out of date, out of security patches and eventually out of the search results.
Who can change a price on a Friday
Ask what you can edit yourself and what requires the supplier. The answer shapes your running costs more than the hosting fee does.
If every text change means an email and a small invoice, you will stop making changes, and the site will quietly go stale. If you can edit text and swap pictures from a simple panel, the site stays current because updating it takes four minutes. That is the reasoning behind a light editing panel rather than a heavy platform with a hundred settings nobody uses.
Whatever the answer, the proposal should include training. An hour of handover with someone watching you do it once is the difference between a tool you use and a password you lose.
Red flags in a proposal
Seven things that should make you slow down.
- A price with no scope behind it.
- No mention of who writes the text.
- Unlimited revisions, which means either a padded price or an argument waiting to happen.
- Domain or hosting registered in the supplier's name as standard practice.
- A guarantee of first place on Google.
- No warranty period and no support terms.
- A quote that is far below everyone else, with no explanation of what is different.
One more that is easy to miss. A proposal that never mentions your customers. If the document describes technology and never describes who the site is for and what it should make them do, the supplier has not understood the job yet.
Questions to ask before you compare two offers
Send the same five questions to every supplier and compare the answers rather than the totals. What is not included that I am likely to need? Who exactly does the work? What do I own at the end? What will this cost me per year for three years? What happens if I want to leave?
The three year total is the one that reorders most shortlists. A cheaper build with heavier monthly fees and paid content changes can overtake a more expensive one before the second summer.
If you want the full picture of what moves those numbers, our guide to what a website costs in Finland goes through it line by line.
Turning a proposal into a contract you can hold
Attach the proposal to the agreement rather than summarising it. The scope list, the timeline and the ownership clause should be the binding document, not a memory of a meeting.
Add two practical lines that are almost always missing. A named contact on each side with a deputy, and a statement that all accounts created for the project belong to you. Those two sentences prevent most of the messy endings.
Then keep the document where you can find it in two years. The people who avoid trouble are rarely the ones with the best contract. They are the ones who can still find it.