Web developer in Waterloo: a startup site the next hire can run
When I'm the web developer in Waterloo taking over a site, the logins come before the pages. Then I build a site that anyone on your team can update from a dashboard, and I write down how it all fits together. The work is done from Kolkata, India.
Overview
Logins first, then pages
The first job is finding out which accounts your company controls today, and moving any held under a personal address across to a company one. Where the code lives in a repository, that moves across as well.
Then I look at the pages. A site that works can stay as it is, with its setup written down. If you'd like a new look as well, website design for a startup is part of the same job, and the designer on my team handles the layouts.
What a website handover leaves with the company
We go through each of these together before the job closes, with the person who will look after the site next.
- 01
Accounts
the domain, hosting, analytics and code repository, each registered to a company email - 02
A platform
WordPress, or Next.js with an editing dashboard, so pages change without code - 03
Notes
a plain document saying where each part lives and what renews when - 04
An access list
who holds which login, with a second person on every account
Where this comes from
Reviews from Canada, and where I work
With their agreement, five clients from Canada have reviews on the projects page.
I run each takeover from Kolkata, India, and talk you through it on video calls. The team works on your schedule, in your time zone.
One email worth finding
One renewal email for your domain shows me which registrar holds it and whose name is on the account. It's worth a search of your inbox ahead of our meeting.
What moves the number
What makes a handover bigger
Tracing accounts and writing down how the code runs are where a handover's work sits.
| What changes it | Why |
|---|---|
| Accounts under a personal email | a transfer request to each provider, one at a time |
| Code without written notes | I'll read it and write down how it runs before changing anything |
| A platform only a developer can edit | moving to an editor your team can use is a line of its own |
| Pages carried over | content that's still right moves across as it is |
| Contact with whoever set it up | if they can still be reached, one call with them answers a lot |
What changes the size of the job.
What a scope from me looks like
Startup website scope, version one
Included
- A written scope: every page and feature as its own line, agreed before work starts
- Design to build, reviewed on a staging URL that stays open the whole project
- Mobile first — checked on a real phone
- Domain, hosting and every account created in your name from day one
- Every existing account moved into the company's name
- An editing dashboard set up for staff who don't write code
- Basic on-page SEO: titles, descriptions, headings, sitemap, Search Console connected
- A runbook at handover: how to edit it, what renews and when
Phase two
- A redesign, once the accounts and notes are settled
- Product pages for a new release
- Ongoing SEO once the site has traffic to read
- A maintenance plan once the site is live
- Logo and brand design, quoted separately from the build
Not doing
- Guaranteed rankings
- Getting into an account without the holder's permission
The runbook is written as the work happens, so it's complete on the day of handover.
Nearby
Ontario pages worth reading next
Government suppliers come up on the Ottawa page, with a compliance page at the centre, and pages for one language or neighbourhood on the Toronto page.
FAQ
Taking over a startup website
Every change is tried on a staging copy before the live site sees it.
Where does a takeover start when the person who built the site has moved on?
- A takeover starts with whatever logins and renewal emails your company still has. From those I work out who holds the domain, the hosting and the analytics. Domain recovery comes first, because the site and the company's email both depend on it. The accounts then move to a company address one at a time, and design waits until that's done.
Does a working site need replacing?
- A working site doesn't need replacing just because it has changed hands. Once its accounts are moved and its setup is written down, it can run as it is. I'd suggest a rebuild when your team needs an editor it can use safely.
What happens to the logins when someone on the team leaves?
- When someone on the team leaves, the second person already on each account keeps access, and the runbook from handover is updated with the change. Every account is registered to a shared company email, so nothing is tied to one person's inbox.
What's needed from the company to begin?
- To begin, I need every login your company can find, even partial ones, and the name of whoever can approve account transfers. A username without a password still narrows the search. Old invoices from a registrar or host help too, since they show which account paid.
Which platform suits a startup website run by non-developers?
- For a startup website run by non-developers, I'd pick WordPress when the team edits pages every week. Next.js with an editing dashboard suits a site that sits beside a software product. My team builds on both.
Next step
Which pages change with each release?
The pages your team edits most decide how the dashboard is laid out. A rough list is plenty, and we'll go through it in our meeting.
Published · Updated