Web Development Company in Kolkata: How to Choose
How to vet a web development company in Kolkata on stack fit, code ownership and post-launch support — with the questions to ask before you sign.
A web development company in Kolkata should give you three things in writing: the technology it will use and why, who owns the code and accounts after launch, and what support looks like in month two. If any of those is vague, the price is not the real problem. This guide is a practical checklist for Shopify merchants, ops managers and CTOs comparing local studios with remote teams — what to ask, what to avoid, and how a build should actually run.
We build websites, web apps, mobile apps, Shopify apps and Zoho integrations for growing businesses, and we work with clients in India and abroad. You can see the full scope on our web and mobile development page.
What a Kolkata web development company should actually deliver
Strip away the portfolio slides and a web project comes down to a short list of deliverables. Ask for each one by name.
- A scoped build, not an estimate range. Page count, templates, integrations, CMS structure, user roles, and what is explicitly out of scope.
- The stack, named. WordPress, headless CMS, Next.js, Laravel, Django, Shopify, Flutter — whatever fits. A studio that can only build one way will bend your requirements to fit its tool.
- Source code and repository access. Your GitHub or GitLab organisation, your name on it, from day one.
- Domain, hosting and third-party accounts in your name. You should be the owner of the Cloudflare, AWS, Shopify or Google account, with the agency added as a collaborator.
- A handover pack. Setup docs, environment variables, deployment steps, credentials list, and a short walkthrough call.
- A support window. What is covered after launch, for how long, and what triggers a paid change request.
If a proposal does not cover these, it is a quote, not a plan.
The stack question, asked properly
Do not ask "what do you build with?" Ask "what would you build this with, and what would you rule out?" A good answer names trade-offs. A Shopify store with heavy custom checkout logic points to Shopify Plus and checkout extensions, not a from-scratch build. A content-heavy corporate site with a small internal team points to WordPress or a headless CMS with a friendly editor. A customer portal with logins, roles and reporting points to a proper backend — Node.js, Laravel, Django or .NET — plus a frontend framework.
A full-service team should be able to say "either of these two, here is why I would pick one." A single-stack shop will say "ours."
Local vs remote teams: cost, timezone and communication trade-offs
"Local" is not automatically better, and "remote" is not automatically cheaper in practice. Compare on the things that actually affect delivery.
| Factor | Local Kolkata team | Remote team |
|---|---|---|
| Timezone overlap | Full working-day overlap | Depends on region; ask for overlap hours |
| Meetings | In-person possible | Video-first, needs written discipline |
| Cost | Mid to high | Wide range, often lower |
| Communication | Easier for non-technical stakeholders | Needs clear specs and async updates |
| Talent pool | Limited to the city | Global |
| Risk | Relationship and proximity | Process and documentation |
Local wins when you need frequent face-to-face workshops, when stakeholders are non-technical, or when procurement requires a local entity. Remote wins when the work is well-specified, when you need a niche stack, or when budget is tight and your team is comfortable with async tools.
The honest answer: the deciding factor is rarely location. It is whether the team writes things down. A local studio that never documents will hurt you more than a remote team that does.
Questions that reveal how a team really works
- Who is my day-to-day contact, and are they technical?
- How do you share progress — staging link, weekly demo, ticket board?
- What happens if the developer on my project leaves?
- Can I see a recent handover document, redacted?
- How do you handle a change request mid-project?
Questions to ask before you sign: stack, ownership, handover
Run this checklist in the second call, not after the contract.
- Ownership. Who owns the code, the design files, the domain and the hosting account? Get "the client" in writing.
- Access. Will I have admin access to the repository and all third-party services during the build, not just at the end?
- Stack rationale. Why this CMS, this framework, this database? What would you migrate to in three years?
- Performance targets. What Core Web Vitals or load-time target are you committing to, and how will it be measured?
- SEO basics. Will the build include clean URLs, metadata, sitemaps, schema and redirects from the old site?
- Integrations. Payments, CRM, ERP, shipping, email — which are in scope, and which need a separate quote?
- Security and backups. Who patches, how often, and where do backups live?
- Handover. What exactly do I receive on the last day?
- Support. Response times, hours, and the boundary between bug fixes and new work.
- Exit. If we part ways, how do I take the project elsewhere?
A team that answers all ten without flinching is worth a second meeting. A team that gets defensive on ownership or handover is not.
Red flags: fixed templates, hidden retainers, no post-launch support
- "We have a template for that." Templates are fine for a five-page brochure site. They are a trap for anything with custom logic, integrations or a content model you will grow into.
- No repository access until final payment. This is leverage, not security. You should own the code while it is being written.
- A retainer you cannot leave. Maintenance contracts are normal. Lock-in clauses that hand over your hosting or domain if you stop paying are not.
- No named stack. "Modern technologies" means nothing. Ask for names and versions.
- No post-launch plan. Bugs appear in week one. If support starts at an hourly rate with no included window, you will pay for their mistakes.
- Prices far below the market. Someone is cutting scope, skipping testing, or planning to make it back on change requests.
- No staging environment. If you cannot see the work before it goes live, you cannot approve it.
How we work: AI proposes, you approve, nothing ships unreviewed
We use AI where it speeds up the boring parts — audits, drafts, bulk field updates, first-pass copy — and a human reviews everything before it reaches your customers. That rule applies across our products too: SEO Products by EP Digital audits a Shopify catalogue with 22 checks and a 0–100 health score, then proposes bulk fixes for you to review side by side before anything goes live.
On custom builds, the process is deliberately plain:
- Scope call. We map pages, integrations, roles and constraints, then name the stack and the trade-offs.
- Fixed scope, staged delivery. You see a working staging link early, not a big reveal at the end.
- Your accounts, your repository. Access from day one.
- Review gates. Every AI-assisted step is a proposal. You approve, we publish.
- Handover and support. Docs, credentials, walkthrough, and a support window after launch.
We work with Shopify, Zoho (CRM, Creator, Projects, Bookings) and mainstream stacks across web, mobile and backend. If your project spans a store, a CRM and a custom portal, it stays with one team instead of three vendors blaming each other. You can compare our products and services on the products page.
Next step: scope your project with us
Write down four things before you talk to any studio: what the site or app must do, which systems it must connect to, who will maintain it after launch, and your realistic budget range. Those four lines will filter out most of the wrong partners in one call.
If you want a second opinion on a proposal you already have, or a scoped plan for a new build, send it over. We reply as soon as possible and we will tell you plainly if a simpler stack would serve you better.
Related reading
Frequently asked questions
How much does a website cost from a web development company in Kolkata?
It depends on scope, not location. A brochure site with a CMS is a small fixed project; a store with custom checkout logic, integrations and a customer portal is a much larger one. Ask for a scoped breakdown — pages, templates, integrations, content migration and support — rather than a single number. Any quote without a scope list is not comparable to another quote.
Should I hire a local Kolkata team or a remote one?
Choose local if you need frequent in-person workshops, non-technical stakeholders, or a local entity for procurement. Choose remote if the work is well-specified, you need a niche stack, or budget is tight and your team works well async. The bigger predictor of success is whether the team documents decisions and shares progress weekly.
Who owns the code and the accounts after the project?
You should. Insist on your own repository, your own domain, hosting and third-party accounts, with the agency added as a collaborator. Get it in the contract. If a studio only hands over code at final payment, treat that as a red flag.
What should be included in post-launch support?
A defined window for bug fixes at no extra cost, agreed response times, security patching, backups and monitoring. New features and design changes are normally separate change requests. Ask where the line sits before you sign, not after something breaks.
Can you take over a project another agency started?
Yes. We take over existing projects, review the codebase and infrastructure, document what is there, and then continue development or migrate it to a stack that fits. Expect a short audit phase first so the estimate is based on the real state of the code, not assumptions.
Do you build Shopify apps and Zoho integrations as well as websites?
Yes. We build websites and web apps, iOS and Android apps with Flutter, custom and public Shopify apps, and Zoho CRM, Creator, Projects and Bookings implementations. We also build AI chatbots and agents that work over your CRM and store data.
Get a scoped plan, not a vague quote
Send us your requirements, or a proposal you want a second opinion on. We will name the stack, the trade-offs and the handover terms in plain language, and reply as soon as possible.