Web Development Company in Pune: What You Should Receive on Launch Day and Own Afterwards

Web Development Company in Pune: What You Should Receive on Launch Day and Own Afterwards

When a web development company in Pune finishes your website, you should receive more than a live URL. You should hold the domain in your own name, the hosting and admin logins, the source files or theme and plugin list, the content and design files, a record of integrations and third-party accounts, documentation of how the site is built, and a written agreement on what happens next: support, backups and who to call. If you cannot name where each of these things is, the project is not finished, however good the site looks.

This article is a handover checklist for business owners, NGO managers and marketing leads who have commissioned a website, or are about to. It explains what to ask for, why each item matters, how to check it yourself, and how to write it into the agreement before the first invoice is paid. It assumes the common arrangement, a website built for you by an outside company, and flags where custom code, WordPress and e-commerce platforms change the answer. It is not legal advice. For anything that depends on the contract you have signed, read the contract, and if it matters, ask a lawyer.

Why handover is where projects go wrong

Websites are rarely lost in the build. They are lost afterwards, when the developer is unreachable, the agency has closed, a domain has expired in someone else's account, or a plugin licence lapses and nobody knows who held it. Because the site keeps working until the day it does not, owners often discover these gaps only when something breaks.

A handover is also the point where leverage is highest. Before final payment, you can ask for anything that was agreed. After it, you are asking a favour. Our guide on twelve questions to ask a web development company before a quote covers asking these things up front; this article covers checking them at the end.

1. The domain name: registered to you, renewed by you

The domain is the most important asset and the one most often held by the wrong party.

What to check

• Registrant. The domain should be registered in your organisation's name, with your email address as the contact. You can check public registration details through the registrar or a WHOIS lookup, although some details may be masked by privacy settings.
• Account access. You should have your own login to the registrar account, not a login in the developer's name.
• Expiry date and auto-renewal. Note when it expires, who gets the reminder emails and whether the payment method on file is still valid.
• Domain lock. Registrars offer a transfer lock that prevents unauthorised transfers; ask that it is on.
• DNS records. Keep a copy of the current DNS settings (A, CNAME, MX, TXT records). Losing the email records, for example, is a common reason business email stops working after a migration.

If the developer registered it for you

This is very common and is not wrong in itself, but you should request a transfer of the domain, or at least the registrar account, into your control as part of handover. Ask the agency to put it in writing that the domain belongs to you.

2. Hosting and server access

What to check

• Who owns the hosting account. Ideally you do, with the developer added as a user, so that you can remove access later without losing the site.
• Control panel login and, where relevant, SFTP/SSH details, database credentials and email settings.
• What the plan actually is. Know the provider, plan, location of servers, renewal date, cost and what is included, such as backups, SSL certificates and email accounts.
• Whether the site shares a server with the developer's other clients. That is common and not necessarily a problem, but it affects who can see what, and how easy it is to take your site elsewhere.

If the agency hosts the site on its own server, ask for the terms in writing: the monthly or annual fee, what is covered, the backup frequency, the uptime commitment, and how you can take a full copy of the site if you leave. Our article on choosing WordPress hosting in India explains the main options and what the differences mean for a business.

3. The website itself: code, theme, plugins and content

What counts as "the website" depends on how it was built, and that determines what you should be given.

WordPress sites

You should be able to obtain:

• A full backup of the files and the database at launch, stored somewhere you control.
• A list of the theme and every plugin, with versions and whether each is free, premium or custom.
• Licence keys for premium plugins and themes, registered to your account or at least documented, because many updates depend on a valid licence.
• Administrator accounts for your team, with the developer's accounts separate and removable.
• Any child theme or custom plugin code, with a statement of who owns it.

If a page builder or a custom theme was used, find out whether the site depends on a licence the agency holds. A site built with a licence in the agency's name may stop updating, or lose features, if that licence lapses. Our article on whether a custom WordPress theme is worth it covers the trade-offs.

E-commerce sites

On Shopify, the store account and its owner login must be yours, with the developer added as a staff or collaborator account. On WooCommerce, the points for WordPress sites apply, with the addition of payment gateway accounts, shipping integrations and tax settings. For a store, also ask for:

• A list of every app or plugin and what it costs per month.
• Payment gateway accounts registered in the business's own name.
• Courier and logistics accounts held by you.
• Documentation of any custom checkout, pricing or inventory logic.

Custom-coded sites

For a site written in code, such as a React front end with a Java or Node back end, you should receive:

• Access to the source code repository, owned by your organisation or transferred to it. If the code lives in the agency's private repository, you cannot easily move to another developer.
• A README explaining how to set up, run, build and deploy the project.
• Environment configuration, listing the settings needed (without exposing secrets in documents).
• Database schema and a backup, plus how migrations are run.
• Details of any open-source libraries and their licences.
• Deployment instructions: where it runs, how updates are released, who has access.

This is where a lack of documentation hurts most. Ask the agency to do a short walkthrough call, recorded, in which someone other than the original developer follows the README to bring the project up. If they cannot, the documentation is not good enough.

4. Design files, content and media

Design files

If the site was designed in a tool such as Figma, ask for access to the file, or an export, and the fonts and brand assets used. Check whether fonts are licensed for web use and in whose name.

Content

You should have your own copy of:

• The text of every page, in an editable format.
• Images and videos in their original, full-resolution form, not only the compressed versions on the site.
• Forms and their settings, including where submissions are sent.
• Documents such as PDFs that are offered for download.

Image and font rights

Stock photos, icons and fonts used on the site have licences. Some are free for commercial use, some need attribution, some are paid and tied to an account. Ask the agency to list the source and licence of every image and font that is not yours, and who holds each licence. If a photograph was bought in the agency's name for a single project, you may need to confirm that its use on your site is covered.

5. Third-party accounts and integrations

A modern website is connected to many other services. Make a table, and fill it in with the agency. For each service, record: what it does, who owns the account, the login email, the billing method, the renewal date and the monthly cost.

Typical entries include:

• Analytics: Google Analytics 4, Google Search Console, Google Tag Manager.
• Email and forms: email marketing tools, form handlers, transactional email services.
• Payments: payment gateway, UPI or donation handling.
• Messaging: WhatsApp Business API provider, chat widgets, SMS gateway.
• CRM and automation: your CRM, any workflow tools that connect to it.
• Security and performance: CDN, firewall, backup and monitoring services.
• Maps, reviews and social: Google Maps API keys, review widgets, embedded social feeds.

The ownership rule

Every account that holds your business data, your customers or your money should be in your organisation's name, with the agency given access through a role that can be removed. The reverse arrangement, where the agency owns the account and you are a guest, is the one that causes trouble. Analytics history, for example, cannot easily be moved once it is in the wrong property.

For WhatsApp specifically, see our article on switching WhatsApp providers without losing your number, which shows how much trouble an account held in the wrong name can cause.

API keys and secrets

Keys for payment gateways, maps and messaging services are secrets. They should be stored in a secure place, such as the hosting configuration or a password manager, not shared in an email thread or a chat message. Ask the agency how they were handled and whether any were shared with people who no longer work on the project. If in doubt, rotate them at handover.

6. Logins, roles and a password manager

One list, held by you

At handover, you should have a written list, ideally in a password manager shared with at least two people in your organisation, of every login the site relies on. Avoid keeping this in a spreadsheet on one person's laptop.

Principles for access

• Individual accounts. Everyone who works on the site has their own login. No shared "admin" account.
• Least privilege. A content editor does not need administrator rights. Use editor or shop-manager roles where they exist.
• Two-factor authentication on the registrar, hosting, admin panels, analytics and payment accounts, wherever it is offered.
• A removal plan. When the agency's work ends, or when a member of your team leaves, you remove their access the same day.

Our website security audit guide for Indian small businesses covers the checks that follow from this, and our WordPress security checklist goes deeper for WordPress sites.

7. Backups and recovery

What you need to know

• What is backed up: files, database, uploads, and for e-commerce, orders and customer data.
• How often, and how many copies are kept.
• Where copies are stored. A backup stored only on the same server as the site is not a backup if the server fails.
• Who can restore and how long it takes.
• When it was last tested. A backup that has never been restored is an assumption.

Ask for a recovery test during handover: restore the site to a separate location and check that it works. If this sounds like a lot, remember that it is the only way to know the answer to "what happens if the hosting account is compromised tomorrow?"

8. SEO, redirects and tracking set-up

If the site replaces an older one, the handover should include evidence that you have not lost search visibility.

• A redirect map from old URLs to new ones, and a check that it is in place.
• Search Console verified in your name, with the sitemap submitted.
• Analytics installed and tested, with conversions defined.
• A robots.txt and an XML sitemap that behave as expected, and a statement of whether the site is open to search engines. Pre-launch settings that block crawlers are sometimes left on by mistake, and our article on AI crawlers and robots.txt explains what to check.
• Page titles and meta descriptions that were agreed and implemented.
• Structured data if it was part of the scope.

Our guide on website migration without SEO loss gives a fuller checklist for replacing an existing site.

9. Documentation and training

Documentation worth asking for

Not a hundred-page manual. A short, clear set of documents covers most needs:

• A site overview: pages, templates, plugins or modules, integrations, and how they connect.
• A how-to guide for the tasks your team will actually perform: editing pages, adding a product, publishing a post, updating a donation campaign, handling form enquiries.
• A "what to do if" sheet: the site is down, the form is not sending, the payment page shows an error, who to contact and what to check first.
• A change log from the build, listing significant decisions and customisations.

Training

Ask for a live training session, recorded, with the people who will manage the site. Have them perform the tasks while the agency watches, instead of the other way round. This is the quickest way to find what is missing from the documentation.

10. Quality checks before you accept the site

Do not sign off until you have tested the site yourself, or had someone independent do it.

• Forms and notifications: submit every form and confirm the right people receive it.
• Payments: for a store or donation site, complete test transactions in the way real customers will, including failures, and confirm receipts and confirmation messages.
• Mobile and browsers: check on real phones, not only a resized desktop window.
• Speed: run the main pages through Google's PageSpeed Insights or Lighthouse and note the results. Our article on speed optimization for Indian business websites explains what to look at.
• Accessibility basics: keyboard use, contrast, image descriptions. See our accessibility checklist.
• Legal pages: privacy policy, terms and any required disclosures are present and accurate. Check what applies to you with a qualified adviser; our article on DPDP Act website compliance is a starting point.
• Content check: no placeholder text, test pages or "lorem ipsum" left behind.
• Staging and test pages removed from search engines.

Our guide to approval checkpoints from brief to launch shows where these checks fit in a project timeline.

11. After launch: support, maintenance and warranty

What to agree in writing

• A defect warranty period: a set number of days after launch in which bugs that come from the agency's work are fixed without charge. What counts as a defect, and what counts as a change request, should be defined.
• A maintenance arrangement, if you want one: updates, security patches, backups, uptime monitoring, minor content changes. State the scope, response times and cost. Our guide to website maintenance and support in Pune explains what a sensible plan includes and what to watch for.
• An escalation path: who to contact, how, and what happens outside business hours.
• An exit plan: what happens if either side ends the relationship, how long notice is, and how the agency will help you move the site.

Beware of dependency by design

Some arrangements make it deliberately hard to leave: a proprietary platform that only the agency can host, a licence held in the agency's name, code that is not delivered, or a fee for releasing your own files. Ask directly: "If I want to move to another developer in two years, what will I receive, in what form and at what cost?" A good agency will answer without hesitation.

A one-page handover checklist you can copy

Use this as a sign-off sheet. Each item should have a name, a date and a "done" mark.

1. Domain registered to our organisation; we hold the registrar login; auto-renewal and lock confirmed.
2. DNS records exported and stored.
3. Hosting account in our name (or terms in writing); we hold the control panel login.
4. Full file and database backup received and tested by restoring.
5. Theme, plugin or module list with versions and licences received; licences in our name.
6. Source code (custom builds) delivered with README and deployment instructions; walkthrough done.
7. Design files, fonts, images and media received; licences recorded.
8. Third-party accounts listed with owners; analytics and Search Console in our name.
9. All logins in a shared password manager; two-factor authentication on key accounts; agency access role-based.
10. Backups scheduled, location and frequency documented; restore tested.
11. Redirects, sitemap, robots.txt and tracking verified.
12. Documentation, how-to guide and recorded training received.
13. Forms, payments, mobile and speed tests passed and signed off by us.
14. Warranty period, maintenance terms, support contact and exit terms agreed in writing.
15. Final invoice paid only after the above are complete.

Common mistakes

• Paying the final invoice before the handover is complete.
• Accepting "we will send it later" for logins, backups or files.
• Leaving domain, hosting or analytics in the agency's name because it was easier at the start.
• Not testing a restore.
• Skipping training, then paying for every small content change.
• Not asking about licences, and finding out a year later that a premium plugin stopped updating.
• Sharing passwords by email or chat and never rotating them.
• Not planning the exit, until a relationship breaks down.

Working with Govindani Infotech

Govindani Infotech Pvt. Ltd. is a web development company in Pune. Our website creation service covers WordPress, e-commerce and custom builds, and our pricing page for websites gives a starting point for scoping. We will walk you through what you will own and hold at the end of a project before you commit, and the same questions apply to us as to any other agency.

If you have a website built by someone else and want to check whether you really own the pieces, you can message us on WhatsApp or use the contact page. We will confirm scope and cost after reviewing your situation.

For the recovery side of ownership, see our guide to website backups and disaster recovery, including a restore drill you can ask your developer to run.

Frequently Asked Questions

What should a web development company hand over when a website is finished?

At minimum: the domain registered in your name, hosting and admin logins, a full backup, the theme and plugin list with licences (or the source code and README for custom builds), design files and media, a list of third-party accounts, documentation and training. The terms for support and exit should be in writing.

Who owns my website, me or the developer?

It depends on your contract. Many agreements transfer ownership of the work on full payment, but they may exclude third-party software, templates, or the agency's reusable code. Read the intellectual property clause before you sign, and ask a lawyer if the site is business-critical.

How do I check that my domain is registered in my name?

Look up the domain through a WHOIS service or your registrar. Check the registrant name and contact email, and make sure you can log in to the registrar account yourself. If the domain is in the agency's account, ask for a transfer before final payment.

Should I get the source code for my website?

For a custom-coded site, yes, you should receive access to the source code repository, or a transfer of it, with instructions to run and deploy it, unless your contract clearly says otherwise. For WordPress and similar platforms, you should receive the full site files, database, and a list of themes and plugins with their licences.

What if my web developer is unreachable and holds my logins?

Start with what you control: the registrar, your hosting provider's account-holder verification process and the platform's account recovery. Many providers will help the verified owner regain access. Gather proof of ownership, such as invoices and your business registration. If those routes fail, take legal advice on your contract before doing anything more drastic.