How to choose a web studio in Tashkent: 12-point checklist

A portfolio and a low price do not show how an agency will deliver your project. Use these 12 checks before signing: inspect the work, meet the team and document scope, ownership and support. Ask for evidence relevant to your project rather than relying on promises about the whole market.

1. Check the portfolio for the last 12 months

A studio showing only 2019–2021 cases is a red flag — either they lack fresh work, or they are not proud of recent results. Require at least 5 projects launched in the last 12 months. Open them on mobile and desktop, test the forms.

2. Run PageSpeed on their own projects

Run pagespeed.web.dev on several live portfolio pages and test them on a phone. Inspect loading, layout shifts and form usability. A single lab score is a diagnostic sample; ask what the team controls and what user data is available. Agree acceptance criteria for your own pages.

3. Ask which technologies fit the project

Ask which CMS, frontend, backend, database and hosting will be used, and why. A simple CMS can be better for an editable corporate site, while a product with custom workflows may need its own backend. The useful answer explains maintenance, integrations, content ownership and who can support the system later.

4. Ask for a line-item quote

A quote reading "Website development: $5,000" is not workable. A proper one breaks out UX, UI, frontend, backend, SEO, QA and deploy with hours on each. This lets you discuss what to simplify and what to add, instead of negotiating in the dark.

5. Verify the contracting party

Request registration details and ensure the contract, invoice and payment recipient identify the same party. If IT Park residency is claimed, verify it separately. A status or tax benefit does not demonstrate development quality; delivery scope and accountable contacts still need to be documented.

6. Sign a contract with milestones and acceptance criteria

• Milestones with delivery dates (design → dev → QA → launch)
• An agreed staged payment schedule linked to accepted deliverables
• Acceptance criteria, revision deadlines and responsibility for delays
• IP and source code transferred on final payment
• 1–3 month warranty for post-launch bug fixes
• NDA covering your data and business information
• Termination, refunds and handover of completed work

7. Meet the people who will deliver

Ask who handles design, frontend, backend and project management. Confirm whether the portfolio team will work on your project and which tasks are subcontracted. Meet the technical lead before signing and agree who answers questions, accepts changes and replaces an unavailable specialist.

8. Read independent client feedback

Check public business profiles and professional platforms where relevant. Read the studio’s responses to complaints and ask for a reference from a similar project, with that client’s permission. Few public reviews can mean a new team or private work; use it as a question to investigate, not proof of poor delivery.

9. Agree support after launch

Clarify who updates content, monitors the site and restores backups. Separate warranty bug fixes from paid changes. Ask for response times for a broken checkout or lead form, working hours, the contact channel and the cost of support. Ensure you receive admin access and instructions when the project is handed over.

10. Agree how scope changes are handled

A new language, payment flow or page template can change both price and delivery date. Keep a written list of included and excluded work. Require a change request with its estimate and schedule impact before extra work starts, and record approval so neither side relies on a different interpretation of a conversation.

11. Ask how data and access are protected

Ask how credentials are shared, who can access customer data and how access is revoked at handover. Request separate test and production environments, a backup and restore procedure, and a secure way to share secrets. Check that test data does not expose real customers and that sensitive credentials are not stored in source code.

12. Do a technical interview before signing

Ask 5 questions: how do you optimize LCP on mobile, how do you make SPA indexable in Yandex, what JSON-LD schemas do you use for commercial pages, how is code review structured, what do you do the night before a release. Clear answers = professionals. "Our developer will answer that later" = sales disconnected from delivery.

Three warning signs to resolve before signing

• No relevant live work or explanation of the studio’s role
• A quote without scope or acceptance criteria
• No named delivery team or handover plan