Bilingual Website Cost: From Build to Maintenance

You have two quotes for a Persian and English website. The gap between them is wide, and you can't tell which one is more complete. A bilingual website cost isn't driven by the number of languages alone. It's the sum of development, translation and content entry, tools, and maintenance after launch. Ask for those items separately and the quotes become comparable.

What makes up a bilingual website cost?

In practice, a bilingual website cost has four separate parts: initial development, content preparation, tools, and post-launch operations. The trouble starts when every vendor writes these parts up in their own way.

Say you receive two quotes, both titled "bilingual website design". One covers translation, content entry and testing in both languages. The other just installs a language-switcher tool and leaves the rest to you. The difference in price isn't a difference in quality. It's a difference in scope.

By a bilingual site, I mean two language versions, each with its own access path and content. You don't need two separate websites; usually a single content management system (CMS) keeps both versions side by side.

Separate the main items like this:

• Initial development: designing and building templates, configuring languages, and technical testing.

• Content preparation: writing, translating, reviewing and entering text into the site.

• Tools: licences for plugins or third-party services, and their renewals.

• Post-launch operations: maintenance, updates, and keeping the two languages in sync.

Also, don't treat the initial contract amount as your first-year budget. The contract usually covers building and launching; renewals and maintenance through the year come separately. This guide explains how to do the calculation. Niasa's current rates live in the table on our services page.

How is the cost of adding a second language calculated?

Put simply, the cost of adding a second language to a site is the sum of these tasks: reviewing and fixing the infrastructure, preparing templates, translating and entering content, setting up language paths, and testing. Count tool licences and recurring maintenance separately. The estimate is based on the number of distinct templates, the volume of text and the features each language needs — not just the number of languages.

For the initial cost, I work with this formula:

Initial cost = sum of (hours per activity × agreed rate for that activity) + fixed items

Fixed items are things not tied to hours, such as buying a tool licence. Keep translation out of the hours too, because it's priced on a different logic. Calculate it with the separate unit you've agreed on.

For the first year, though, you need a fuller picture:

First-year budget = upfront payments + renewals actually due within that year + maintenance and content updates

One mistake I run into often when reviewing estimates is double counting. If you bought a one-year tool licence with the contract, renewing it isn't a new cost in year one.

That's why you should ask every vendor to list the base site cost separately from the added cost of the second language. Without that split, the bilingual website design cost stays a single lump figure. Only with it can you put two quotes side by side.

How does building a new site differ from adding a language?

The main difference is the starting point. On a new site, the team designs the language structure from day one. On an existing site, you first have to find out whether it can take a second language at all. That question alone can sometimes shift the entire bilingual website cost.

Persian is right-to-left (RTL) and English is left-to-right (LTR). The difference goes beyond text direction: menus, icons, arrows and column order flip too. So every template has to be reviewed and tested in both directions. For the principles behind this, the web internationalisation standards resources are a good reference.

On an existing site, the first thing I usually do is run through this list:

• Content structure: Can the CMS hold language versions of the same page?

• Templates: Does the text come from translatable files, or is it hard-coded?

• Forms: Can labels, error messages and confirmation emails be changed for the second language?

• Search: Does it show results per language?

• Page URLs: Does the current structure leave room for a language path?

• Integrations: Will the accounting software, SMS service or CRM have problems with the second language?

Imagine a corporate site whose fixed text, such as section titles and buttons, is written directly into the template code. Before any translation, someone has to pull that text out and make it translatable. In a situation like that, adding a language isn't necessarily cheaper than designing it properly from scratch. A large share of the bilingual website cost here comes down to the technical state of the site itself.

Current URLs matter too. If fitting in the second language forces you to change the Persian page URLs, you need a redirect plan — automatically sending each old URL to its replacement page. Without it, you lose old links and part of your search traffic.

My rule is simple. Until the vendor has access to the admin panel and the code and has seen the current site, don't treat any figure for adding a language as final. Before that review, any number is just a guess. For design details, take a look at multilingual website design tips.

How do pages, templates and features affect the estimate?

The number of distinct templates has the biggest effect on design and development cost; the word count has the biggest effect on translation cost. That's why page count alone is a poor measure of a bilingual website cost.

A template is a repeating layout. Twenty service pages with a shared layout count as one template, not twenty separate designs. But the home page, contact page and portfolio usually each have their own.

Before asking for an estimate, fill in this worksheet:

For example, say you have a Persian site with 20 pages and only 8 of them will go into English. Count the translatable text for those 8 pages only. But do add shared elements such as the menu, footer and form messages, because they repeat across every page.

Features affect cost by a different route. Each form, for instance, needs bilingual error messages and confirmation emails. Search has to show each language's results separately. Product pages and integrations with other software need their own testing.

That said, don't confuse multilingual with multi-currency or international sales. Showing prices in a foreign currency, an international payment gateway and shipping abroad each have their own scope.

Each language needs its own clear URL. The hreflang tag tells search engines which language a page is in and where its equivalent version lives. This setting helps the versions get indexed correctly, but it doesn't guarantee rankings. See the details in the guide to managing multilingual site versions.

How do you separate translation, content entry and review costs?

My advice is to ask for website translation cost separately from content entry and review, and to define its pricing unit precisely. A vague "per page" rate can't be compared, because a page might be a hundred words or two thousand.

There are three clearer units: source-text word count, a page with a defined word cap, or a content package with an exact list of pages. Whichever you choose, write it into the quote.

Then split four tasks: translation, specialist review, content entry and display checks. If you supply the translation yourself, only the first task drops off. Someone still has to enter the text, fix line breaks and check how it looks on mobile.

These items almost always get missed:

• Menus, buttons and the footer

• Form error and confirmation messages

• The title and description shown in search results

• Image alt text

• Downloadable files such as catalogues and brochures

• Text inside images and banners

In fact, content's share of a bilingual website cost is often bigger than clients expect. Machine translation is useful for producing a first draft. But legal or medical text, or any page tied directly to sales, needs review by a specialist in that field.

A translation that hasn't been properly placed on the site doesn't count as delivered work.

The order of work affects cost too:

1. Lock the source text; changing the Persian copy mid-translation means paying twice.

2. Build a glossary so service names and terms are translated consistently everywhere.

3. The translator does the translation.

4. The approver reviews and signs off the translation.

5. The technical team enters the text into the site.

6. Finally, the test team checks both languages on desktop and mobile.

Write down the number of revision rounds and the name of the approver from day one. Where I track schedules, most of the delays I've seen have come from exactly this point, not from the technical work.

What do plugins, renewals and first-year maintenance include?

Beyond the build, first-year cost covers tool licences and their renewals, technical maintenance, and keeping content in sync across both languages. Cheap quotes tend to stay silent on this part, which makes the bilingual website cost in them look lower than it really is.

A plugin is a tool that adds a new capability to a CMS — managing language versions, for example. But not every approach needs a paid plugin. Some systems support multilingual content natively, and some projects go the custom-development route.

If a paid tool is involved, ask:

• What does the initial licence cost, and what does the annual renewal cost?

• Whose name is the account registered under? I recommend it be yours.

• Does it have usage limits, such as a word cap or a number of sites?

• Can it be legally purchased and renewed from where you operate — for Iranian businesses, from Iran?

• How will exchange-rate changes affect the renewal?

For that reason, don't accept prices for foreign-currency tools without a validity date. The figure in today's quote may mean something quite different at renewal time.

Maintaining a bilingual site involves a few specific tasks: backups, updating the CMS and plugins, testing both languages after each update, and fixing bugs. But the fifth task — syncing content that has changed in one language — is the one most often forgotten.

Don't assume hosting costs will automatically go up either, because a second language doesn't always need a bigger server. That depends on file volume, traffic and the site's architecture.

The cheapest quote has usually left half of the first year out of the calculation.

The maintenance cost pattern of a multilingual site also depends on your own habits. On a site that rarely changes, maintenance is a small slice of the budget. But if you publish new content every week, translating it can shift your bilingual website cost over the course of the year.

What assumptions do the three budget scenarios rest on?

These three scenarios are hypothetical. They only show how scope changes the shape of a budget. None of them is a rate, a service package or a real client's experience.

Limited scenario: An existing, compatible site, with 8 pages going into English. Those pages use 2 templates and one form, and the client supplies approved translations. Most of the budget goes on language configuration, content entry and testing.

In the mid-range scenario, we have a new Persian and English corporate site with 20 pages in each language, 4 templates and two forms. Specialist translation is part of the job. Here the Persian–English website quote should have two separate parts: the base build cost and the second-language share. For the base part, budgeting for a corporate website will come in handy.

Extensive scenario: An existing online shop with 200 products whose checkout pages and automated messages must work in both languages. Assume the payment gateway and currency stay the same. Even so, translating the products and fully testing the purchase flow in both languages are within the project's scope.

In other words, the budget difference between these three comes from scope, not from labels like "economy" or "professional". In each scenario, the assumptions themselves set the bilingual website cost.

For each scenario, a good estimate delivers these four outputs separately:

• The initial cost of building the site or adding the language

• First-year commitments, including renewals and maintenance

• Exclusions — work explicitly not included in the price

• Items that still need investigation

I've deliberately left out price ranges for these scenarios. A range built without real data misleads more than it helps.

What should be spelled out in a quote?

A trustworthy quote states the scope of work, acceptance criteria, the boundary for changes and the payment terms explicitly, so the bilingual website cost isn't just a number to you. The table below is only a sample for organising the items; it doesn't reflect Niasa's actual service terms.

Beyond the table, look for these figures in the body of the quote: the number of pages and templates, the list of languages and the content volume. Who handles translation, who enters the content and how many review rounds there are should also be written down.

Acceptance criteria are the list of things you check at handover. I suggest checking at least these:

• Switching language from any page lands on its equivalent version.

• Both languages display correctly on mobile.

• Forms and automated messages reach users in their language.

• The behaviour of untranslated pages is defined in advance.

• Each language version's URL follows the agreed structure.

Make the line between bug fixes and new features clear too. If a form that was supposed to work is broken, that's a bug fix. If you want a new form after delivery, that's a new feature. How changes are priced, who owns the licences and how access is handed over also belong in the contract.

Alongside these, ask for the quote's validity date, any applicable tax, the payment stages and the maintenance start date. The schedule also depends on content being delivered and approved; if content arrives late, launch slips too.

Ask every vendor one question without fail: "Which items are needed to launch both languages but aren't included in your price?" The answer clarifies the bilingual website cost across quotes better than any table. You'll find more questions in key questions to ask web design companies.

Niasa's price table and getting a tailored estimate

Niasa's current rates appear only in the multilingual website design price table, and this article doesn't repeat any figures from it. The reason is simple: multilingual website prices may be updated, and a single source of truth prevents contradictions.

Wherever you see Niasa's pricing plans, they come from that services page. Any figure you see outside it isn't a basis for agreement.

To get a tailored estimate, prepare:

• The URL of your existing site, or a short description of the new one

• Target languages and the primary language

• The worksheet of pages, templates and word volume

• Translation status: ready, to be produced, or a mix of both

• The features needed in each language

Then ask for the initial budget and first-year commitments separately, so your bilingual website cost is visible in two clear parts from the start. Settle anything still undecided before you sign, not midway through the build.

Working with Niasa starts with a scope review: we look at your site or your needs, ask about anything unclear, and then give you an itemised estimate. If you want your bilingual website cost estimated from real data, send us the worksheet and we'll go through the project scope together.