How to choose a web designer in Sri Lanka
Editorial review: 28 August 2026 · By: Alston Antony
Choose a Sri Lankan designer by writing your brief once, sending it to two to three shortlisted providers, and comparing them on scope clarity, ownership and account access, process, references and post-launch responsibility - not portfolio and price alone. Ask each provider the same questions and hold each quotation against the same acceptance criteria. This page is the practical framework. Budget lives on website cost; the wider journey lives on web design.
The 8-point hiring framework
- Define the project before comparing providers
- Verify relevant work
- Check references or credible proof
- Compare scope, not headline price
- Clarify ownership, licences and account access
- Understand the project process
- Define launch and post-launch responsibility
- Compare total cost and risk
1. Define the project before comparing providers
Nothing else on this page matters if each provider is quoting against a different picture of your project. Write the brief once, in your own words, and send the identical text to every shortlisted provider. Two quotations for what looks like the same site can differ enormously because their scope inside is different. Same brief in, comparable quotations out.
One-page website brief template
2. Verify relevant work
Prefer live examples the provider has actually shipped, and understand what they personally contributed. Live sites let you inspect layout, forms and mobile behaviour directly. Screenshots and case-study text are not equivalent to a live site.
- Look at what you can actually verify. Open listed URLs on both mobile and desktop, click through a few pages, test a form, and check that navigation works.
- Ask what the provider personally did. Design only? Development only? Content? Ongoing maintenance? A named role beats "we worked on it".
- Legitimate reasons a project may not be public. The client may have closed, been redesigned, moved to an internal system, sit behind an NDA or have been a campaign. Ask for archived work, case-study material or a private walkthrough where possible.
- Post-handover changes affect what you see. The site's current speed and layout may reflect the client's changes since handover. Ask what the provider originally controlled and whether the current version has changed.
- Relevant experience beats geographic experience alone. A provider who has solved similar problems (ecommerce, booking, multilingual, integrations, local payments) is often more useful than one who has built any Sri Lankan site. Sri Lankan experience matters especially where your project depends on local gateways, .lk, Sinhala/Tamil content or local business workflows.
3. Check references or credible proof
Talk to at least one prior client where you can. Ask targeted questions:
- How closely did the final scope match the initial quotation?
- Did the timeline shift, and if so, why?
- How did the provider handle change requests?
- How responsive were they after launch?
- Would you rehire them for a similar project?
Where a direct reference is not available, credible proof can still take the form of a case study with named client, an archived Wayback snapshot, a demo the provider walks through with you, or a well-documented open-source contribution.
4. Compare scope, not headline price
A low quotation and a high quotation for what looks like the same site often include very different work. Before comparing LKR figures, break each quotation down into deliverables and check that they cover the same items.
- Page count and number of unique layouts.
- Design revision policy (how many rounds, at which milestones, what counts as a revision, what happens after approval).
- Content responsibility (copy, imagery, translations).
- QA coverage (device matrix, forms, accessibility, performance).
- Integrations included and integrations quoted as change requests.
- Launch and handover deliverables.
- Post-launch defect window and retainer terms.
- What is explicitly out of scope, in writing.
Undefined revision policy - not "unlimited revisions" per se - is what creates most scope arguments. A provider who offers unlimited revisions inside a defined phase, against specific deliverables, is not necessarily a red flag; a quotation that never names when revisions end almost always is.
5. Clarify ownership, licences and account access
Legal ownership, day-to-day account access, and third-party licences are three different things and the quotation should address all three. A single "we hand over the site" line is not enough.
| Category | Question to answer in the quotation |
|---|---|
| Domain | You (or your business) are correctly recorded as the registrant with LK Domain Registry (directly or via an authorised agent). You control the registered email and account used to manage the domain. The .lk Registrant/Organisation fields reflect the actual user of the domain per Registry policy. |
| Hosting account | Registered under your business email; you have billing and admin control. Reseller sub-accounts under the designer's parent account are a portability trap - avoid. |
| DNS | You control the DNS zone (at the registrar or a nameserver you own), or you have documented access to update it. |
| CMS administrator access | Admin account under your email, transferred at handover. Existing developer accounts can remain during a support window but should not be the only administrator. |
| Source files / repository | For custom themes or code: source files delivered, and any Git repository transferred to an account you own. |
| Database / content export | Full database and media library export at handover on request. |
| Design source files | Figma, Sketch, XD or equivalent files delivered where contractually agreed. |
| Premium theme and plugin licences | State whose licence powers the site (yours or the provider's agency licence). Ask who pays renewals if the provider's licence stops covering your site. |
| Stock imagery, fonts and third-party assets | Licence type disclosed; ongoing usage rights confirmed in writing. |
| Analytics, Search Console, Tag Manager, ad pixels | Accounts owned by you; provider added as user, not the reverse. |
| Backup and export capability | You can generate a full backup yourself post-handover without a support ticket. |
6. Understand the project process
- Milestones and acceptance criteria. Each milestone should list what "done" means (e.g. wireframes approved, visual design signed off, staging site QA-passed, launch checklist complete). A milestone is payable when its acceptance criteria are met.
- Communication quality. Notice whether the provider answers your actual questions, understands your requirements, documents important decisions, flags limitations early, and responds within the timeframe they promised. Pre-sales communication is one useful indicator of how the working relationship will feel later; fast replies are not automatically good replies.
- Change requests. Most arguments come from mixing revisions and new scope. The agreement should explain how additional work is estimated, whether approval is required before work begins, the change-request rate (hourly or fixed), and the effect on timeline.
- Delay responsibility on both sides. Ask what happens when the client delays content, when the provider misses an agreed date, how long a project can pause, and how the timeline is rebooked.
- Cancellation / termination. If either side ends the project before launch, what happens to work completed, deposits, source files, the domain, hosting, content and third-party licences.
7. Define launch and post-launch responsibility
Handover is where projects most often fall apart. Write the launch and post-launch scope into the quotation, not into trust.
- Launch checklist. DNS switchover, HTTPS/SSL, redirects from old URLs (critical for a redesign - preserving existing URLs and adding 301 redirects where structure changes protects the search ranking of the site being replaced), sitemap, robots, canonical setup, page titles and metadata where included, Search Console and analytics configured.
- Ownership handover. All items from section 5 delivered on the agreed date.
- Post-launch defect window. A short free-fix period for defects discovered after go-live, in writing. Provider warranties vary - ask each quotation to name the exact window and what counts as a defect vs a change request.
- Maintenance retainer. Optional. Should name update cadence, backup verification, restore workflow, support hours, response times and escalation.
- Existing-site redesign? Ask specifically about analytics continuity, redirect map for changed URLs, and preservation of email deliverability if mailboxes or DNS records move.
8. Compare total cost and risk
The right shortlist decision often comes from comparing the total picture rather than the headline build price. For each candidate:
- Build price (one-off).
- Recurring third-party licences (themes, plugins, stock, fonts) - who pays after year one.
- Hosting (whose account, whose plan, and whether they include a promotional discount that renews sharply).
- Maintenance retainer (whose scope, whose cost).
- Change-request rate and typical response time.
- Ownership and portability risk (how easy would it be to move if the relationship ends).
For the LKR side of this comparison, see the website cost hub and the cost calculator - both use the same normalized scope framing as this hiring framework, so the numbers travel between them.
Provider comparison scorecard
Once your shortlist responds to the same brief, score each on the eight dimensions below. Use it as a comparison aid, not a formula - a critical issue on one dimension (unclear ownership, undefined revision policy) can override a strong total score.
| Dimension | Candidate A | Candidate B | Candidate C |
|---|---|---|---|
| Relevant work you could verify | /5 | /5 | /5 |
| Scope clarity and acceptance criteria | /5 | /5 | /5 |
| Communication quality | /5 | /5 | /5 |
| Ownership, licences and account access | /5 | /5 | /5 |
| Technical fit for your workload | /5 | /5 | /5 |
| References or credible proof | /5 | /5 | /5 |
| Post-launch terms | /5 | /5 | /5 |
| Total cost and portability risk | /5 | /5 | /5 |
Red flags in a Sri Lankan web design quotation
Any one of these is a conversation to have. Two or more together is usually a signal to look at the next quotation.
- Vague scope with a fixed price. A number attached to "a nice modern website" is not a fixed price.
- Undefined revision policy. The problem is not "unlimited revisions" per se - it is a quotation that never names when revisions end or what counts as one.
- Domain not registered under your control. You should be the correctly recorded registrant with LK Domain Registry (directly or via an authorised agent), and you should control the account used to manage the domain.
- No handover clause. The quotation should name what accounts, source files, licences and access get transferred at launch.
- No post-launch defect window. Handover with no free-fix period means every launch-day bug is a new invoice.
- Refusal to discuss references, credible proof or the provider's specific role on past work.
- Full upfront payment insistence for a provider you have not worked with before. For unknown providers, milestone-based payments tied to deliverables generally reduce risk.
Methodology and how to read this framework
This framework is WebsiteHosting.lk's recommended buying process for Sri Lankan web projects, drawn from public provider documentation, published rate cards, project quotations reviewed with client permission, and Sri Lankan buyer conversations. It is a heuristic buying framework, not a statistically validated Sri Lankan quotation dataset. Where the page references specific external facts (LK Domain Registry Registrant/Organisation policy, Google's treatment of ccTLDs), those are sourced against the relevant provider documentation.
As WebsiteHosting.lk publishes its Sri Lanka Website Quote Index over time (see the business website cost methodology), this page will be updated with dataset-backed guidance where it strengthens the framework.
Frequently asked questions
How many web designer quotations should I collect in Sri Lanka?
Two to three comparable quotations are usually enough for a small business project. The important part is giving each provider the same written brief so you compare the same scope. If you already have a highly trusted referral with strong evidence, you may not need three.
What is a fair Sri Lankan payment schedule for a web project?
Payment schedules vary. A milestone structure such as 40/30/30 or 50/25/25 is one common approach - what actually matters is that each payment is tied to a clearly defined deliverable with written acceptance criteria. For a provider you have not worked with before, milestone-based payments generally reduce risk compared with an undefined full upfront payment.
How should I evaluate a Sri Lankan designer's portfolio?
Prefer live sites you can inspect. Open the listed URLs on mobile and desktop, check that navigation and forms work, ask what the designer personally contributed, and understand whether the current version is what they originally delivered (post-handover changes can affect the site's speed and layout). Where a project is no longer public, ask for archived work, case-study material or a private demonstration.
What are the red flags in a Sri Lankan web design quotation?
Vague scope with a fixed price; an undefined revision policy; the domain being registered under the provider's control instead of yours; no account-access or handover clause; and no post-launch defect window. Any one of these is a conversation to have; two or more together is usually a signal to look at the next quote.
Sources & references
- LK Domain Registry (domains.lk) — .lk registration authority - Registrant/Organisation records and WHOIS handling (checked 28 Aug 2026)