RUNNING A WEBSITE / AN OWNER’S GUIDE
Your website.
Your business.
Your keys.
Buy your own domain. Know where the site lives. Trust the people building it. And agree how you keep control, without making the relationship a battle.
Let’s get into it
Before we talk about colours, layouts or who holds the passwords, there is something worth understanding: getting a website means paying for the build and budgeting for its life afterwards. Hosting, domain renewals, licences and business email are normal parts of the job. They should be explained at the beginning, so you can make a sensible decision about the whole investment.
I’ve been building websites long enough to know that the conversation about the homepage is usually the easy one. The awkward conversations arrive later: who renews the domain, who can restore the site, what happens when a plugin licence expires, and whether another developer can pick things up.
I’ve dealt with enough hosting headaches to have fairly strong opinions. I also know the other side of the desk: designers who have put serious work into a project, only for a client to disappear when the invoice lands. A good arrangement needs to protect both people.
I loved Mark Smith’s guide to what to ask a web designer at CODO Digital. It prompted this longer take from my own experience: the choices I’d make, the access I’d insist on, and the things I’d stop spending three meetings arguing about.
BEFORE WE GET INTO THE DESIGN
The website has a build cost.
And a running cost.
A good website can be your hardest-working employee: explaining the offer, taking enquiries or selling while you’re away. Keeping that employee equipped is part and parcel of owning the website.
Website hosting
Monthly or annual
The home for your website: the infrastructure that serves it to visitors. Check the renewal rate, storage, traffic limits and support included.
Your domain name
Registration + renewal
Your business address online. You register it for a term and renew it to keep it. It is a separate cost from building or hosting the website.
Plugins & licences
Often annual
Paid themes, plugins and connected tools may renew. Ask which you need, who holds each licence and what stops receiving updates if it expires.
Branded business email
Usually per user / month or year
Properly hosted mail at your own domain. Budget for the people who need accounts, storage and any migration or setup work. Check what is bundled.
Then allow for care. Updates, backups, monitoring and support take time. Agree who handles them and what the fee covers. Shops and apps may also have payment fees, usage charges or subscriptions for bookings, messages and other services.
Ask for the setup price, the renewal price, the billing dates and who pays each bill. Monthly and annual payment options can have different terms. Some costs are bundled; some are separate. Get the whole picture in writing.
Try the running-cost calculatorA SMALL DETAIL THAT CARRIES A LOT
Your email should belong
to your business.
A personal email address on a business website can make an otherwise sharp business feel unfinished. An address such as hello@yourbusiness.ie connects the conversation to the name customers have just found.
There is a practical side too. If the business runs through somebody’s personal inbox, what happens when they leave, lose access or mix customer messages with their own correspondence? Ownership, recovery and handing work to another person can become awkward very quickly.
Business-owned access
Keep the service account under the business’s control. Give people their own access and use shared mailboxes or delegation where appropriate, rather than sharing one password.
Protection behind the name
Use multi-factor authentication and secure recovery. Ask your provider to configure SPF, DKIM and DMARC: checks that help receiving services verify your mail and handle impersonation.
A plan for changes
Know who can add or remove users, recover access and move the mail later. Keep the domain renewed, and protect email records when a website moves to a new host.
A branded address alone does not make email secure, and a free personal inbox is not automatically unsafe. The improvement is a professional identity backed by sensible business administration and a properly configured service.
Hosted email is often separate from website hosting. Services such as Google Workspace and Microsoft 365 offer business email on your domain. Compare the actual plan, number of users, storage, support and renewal terms. An alias that forwards a message is not necessarily a separate mailbox, and website form delivery may need its own setup.
Google: email authentication and delivery guidanceKeep control of your business.
Give your designer room to do their job.
01 / Start with the customer
Start with the person who needs to use it.
Before we talk about the account logins, work out what somebody is coming to the website to do. Book a table? Compare a service? Check whether you cover their area? Find the opening hours while standing outside?
Yes, it needs to look sharp. I’m a designer; I care deeply about that. But the design should help the customer understand your offer and move forward. A beautiful page that hides the price, the location or the booking button still leaves them doing the work.
Write down three important journeys before you commission anything. For a hotel, those might be checking rooms, seeing the food and finding availability. For a tradesperson, it might be checking the service area, seeing relevant work and requesting a quote. For a customer app, it might be signing in, completing a task and recovering an account.
Use those journeys when reviewing the finished work. Ask someone who was not in the design meetings to try them. Watch where they hesitate. That is often more useful than another round of personal preferences about the hero image.
02 / Buy your own domain
Buy your own domain. Keep it in your own account.
The domain is the address people type to find you. Hosting is where the website runs. Your email may be a third service again. You can use different companies for each; buying a domain does not mean you must buy every extra offered at checkout.
My preference is simple: you create the registrar account, register the domain to your business, pay the renewal and keep the recovery details. I help connect it. That way your address is not dependent on my inbox, my availability or whether you and I are still working together in five years.
Where would I buy one?
Register365 — my personal choice
I personally use Register365. Honestly, they’ve been the best fit for me, and I’ve really valued the loyalty and support they’ve shown me. That counts for a lot when your business depends on keeping its address online.
Domain renewals can be forgotten. When a renewal has been missed or access needs sorting out, I’ve found them very quick to help restore access and get things live again. That practical support is a big part of why I stay with them.
I still recommend switching on auto-renew, keeping your payment details current and setting your own renewal reminder. If a domain does lapse, contact support promptly: the recovery options depend on the domain’s status.
Explore Register365 Register365’s domain renewal guideCloudflare Registrar
Worth considering for supported extensions if you are happy using Cloudflare DNS. Registration and renewal are offered at cost; check the extension and current price.
One important detail: domains registered there must use Cloudflare’s nameservers. That can suit the setup very well, but agree it with whoever manages your DNS.
Explore Cloudflare Registrar Read the nameserver requirementsNamecheap
Another place to compare for the extension you need. Look at the renewal price, not only the first-year offer. Its Share Access feature lets another account manage selected domain settings while you retain control.
Explore Namecheap domains How delegated access worksA .ie domain?
Check an accredited .ie registrar. Blacknight is an Irish option to compare. The .ie registry explains the registration process and the evidence of a connection to Ireland you may need.
Choose the registrar for the domain service you need; you can make the website hosting decision separately.
Read the .ie registration guide Find an accredited registrarFor any registrar, compare the renewal, account recovery, support and permission options. You do not need to transfer a perfectly well-managed existing domain just because a new designer prefers another dashboard.
If someone already holds the domain for you, ask them to help document or transfer the arrangement while everything is friendly. Before changing DNS, get the existing records checked. A website move should not accidentally take the business email with it.
03 / Know who has the keys
Ownership and access are different things.
“I have a login” is a start. It does not tell you what that login can actually do. A WordPress Editor can work on content; that is different from an Administrator, and neither automatically gives you control of the hosting or domain account.
For a normal standalone WordPress business website, I want you to have a business-controlled Administrator account at the agreed handover. You might use an Editor account day to day so you do not accidentally change the wider setup. We should explain that distinction, not quietly leave you with less access than you expected.
WordPress: what the roles can doYou invite the designer to the access they need. You keep an independent way back in.
I need developer access to do the work properly. That may include the hosting environment, a staging copy, files, logs or relevant app services. Giving me the right access is part of hiring me. It does not require giving up your own account or sending one shared password around the whole team.
Ask your host what roles it provides and whether your plan allows a separate collaborator. WP Engine has its own portal roles; Kinsta separates company-wide access from site-level roles. The names and powers are not identical. Give access to the relevant site when that is enough, rather than automatically to every site and all billing.
WP Engine: portal users and roles Kinsta: working as a team04 / Choose hosting carefully
My WordPress hosting preference comes from experience.
For WordPress, my own preference is WP Engine or Kinsta. I’ve been at this a long time. I’ve tried more hosting companies than I care to count, and dealt with enough heartache that I am not particularly interested in saving a small amount to invite the same problems back.
That is a personal working preference, not a promise that either company will be perfect forever. Hosting changes. Products, support teams, limits and prices change. I still need to check the plan against the actual website and revisit the decision if the service stops doing the job.
What I value is an environment I can work in confidently: sensible access, a way to test changes before they go live, usable backups and a clear route to help. The time spent chasing an avoidable hosting problem is time neither you nor I wanted to spend.
What I would ask before picking a plan
- Does it suit this WordPress site, its traffic, storage and any shop or membership features?
- What backups exist, how long are they kept, and who can restore them?
- Can we test updates on a staging copy, away from the live site?
- What support is included, and what remains the designer’s responsibility?
- What are the renewal, usage and overage charges? Is business email a separate service?
- Can you keep control while inviting your developer, and what would moving later involve?
Do not assume a managed host is also managing every plugin, your content, your email and your customer support. The plan and the maintenance agreement should say where those responsibilities sit. A host having backups is useful; somebody knowing how and when to restore them is another part of the job.
ALWAYS THERE NEEDS A LITTLE CONTEXT
Downtime happens. How we handle it matters.
The aim is a website that customers can rely on. But no responsible designer should promise that every service, network and connection will work perfectly for ever. Maintenance, software failures and wider infrastructure incidents can interrupt even well-run websites.
Compare the annual equivalents. Every extra nine makes a difference.
At 99.9%, that is 8 hours, 45 minutes and 36 seconds in a 365-day year. It is a useful way to understand the number. It is not a prediction that your website will go down for that long. For comparison, 90% availability would mean 36½ days offline across the same year. That would be a serious problem for a business relying on its website.
You will see 99.9% used as a hosting service target. For example, Kinsta’s published SLA sets that baseline unless your order specifies a higher figure. It measures availability by monthly billing period, with its own definitions, exclusions and credit process. An annual equivalent is not a yearly outage allowance or a guarantee that every interruption counts towards a credit.
Kinsta: the uptime commitment, measurement and exclusionsGlobal incidents, external providers, DNS, payment services and the connections between them add variables. Your hosting can be online while a booking tool or checkout is failing. Read the terms, but also agree the response: who notices, who investigates, who tells you what is happening and who checks the customer journey when service returns.
If the business depends on taking orders or bookings at a particular time, say so before choosing the setup. The cost of an interruption, acceptable recovery time and a useful fallback contact should shape the plan. Reliable hosting matters; so does having somebody who knows what to do when something goes wrong.
There are reasonable setups where an agency pays for a shared account and manages a client site within it. That can be convenient. You cannot expect access to the agency’s other clients or billing, so agree the site-level access, backups and transfer process instead. The arrangement needs to be understandable and documented.
WP Engine: site transfers Kinsta: company and site transfers05 / Keep control of your app
Building an app? Keep hold of more than the screen.
Lovable can be a brilliant starting point for a website, a prototype or a working app. When you bring in a designer or developer to take it further, decide which workspace and business accounts the project will live in, and how you will collaborate. Make that decision before lots of customers and services depend on it.
A preview link is not ownership access. Being able to change a heading is not the same as being able to manage the project, recover the account or maintain its data. Ask to be shown the actual setup and the permissions your account has.
Think in four separate parts
| Part | What to establish |
|---|---|
| The project | Who owns it, which workspace it belongs to, who can edit it and what the supported handover route is. |
| The code | A business-controlled repository or agreed export, plus instructions another developer can actually use. |
| The data | Database records, uploaded files, sign-in users and the backup or migration process for the services in use. |
| The connections | Domain, hosting, payment account, email service, API subscriptions, environment settings and billing. |
Lovable documents Git sync as a way to keep a copy of your code and work with other developers. That is useful. It does not make a repository a complete copy of a live business: customer records, uploads, service accounts and secrets need their own plan.
Lovable: GitHub sync and code accessIts project settings also distinguish moving a project between workspaces from changing the project owner. Permissions, the plan and connected services affect the route available. Have your developer check the current procedure with you rather than assuming a duplicated project or one button transfers everything.
Lovable: project settings and ownershipYou can keep hosting on a managed platform and still plan for future portability. Moving everything elsewhere is a separate project with configuration, data and testing work. It is not automatically necessary, and it should not be sold as a free, instant side effect of downloading the code.
Lovable: hosting, data and portability06 / Be fair to your designer
Be fair to the person doing the work.
I understand why business owners worry about being stuck with a designer. I also understand why designers worry about handing over finished work and never getting paid. There are far too many stories of people putting in weeks of work and being left chasing the final invoice.
A request for a deposit, staged payments or a clear final handover point is not automatically a bad sign. It is something to discuss and put into the agreement. Equally, ownership and access should not become a mystery that only gets explained after you have committed.
For a bespoke build, the proposal should identify the deliverables, payment milestones and the point at which the agreed work transfers or is licensed to you. Third-party software, stock images, fonts and reusable tools may have different terms. Paying an invoice does not tell you those details by itself; the written agreement should.
- The business controls its domain and recovery.
- Scope, costs and the access arrangement are clear.
- There is an agreed, workable handover or exit route.
- Deposits and milestone invoices are paid as agreed.
- Feedback arrives from a named decision-maker.
- Extra scope and ongoing support are paid work.
If the arrangement is a subscription or licence rather than an outright bespoke build, ask what continues while you subscribe and what you can take with you when it ends. That model may suit you. The problem is discovering it was the model when you thought you were buying something else.
Agree how disagreements are handled too: a written list of issues, a chance to resolve them, and the process in the contract. Neither side benefits from a relationship built around surprise restrictions or unpaid extra work.
07 / Give useful feedback
Trust your designer. Give feedback that helps.
If you hired someone for their judgement, let them explain the decisions. Ask why a heading is there, why a page needs more detail or why the contact button is so prominent. A good designer should be able to connect those choices to the customer and the job the website needs to do.
That includes the words. A service description may help a person decide whether you offer what they need, and help a search engine understand the page. But “it’s for SEO” is not an excuse for awkward, inaccurate or repetitive writing. The language still needs to sound like your business.
Correct facts, claims and tone. Flag a service you do not provide, a promise you cannot keep, a missing location or wording that sounds nothing like you. Those changes matter. Spending a week swapping two equally clear phrases backwards and forwards is a different use of the budget.
“It doesn’t feel right. Can we make it pop? Maybe try another font.”
“Customers may think we only work in Dundalk, but we cover all of Louth. Could we make the service area clear near the quote button? The tone also feels more formal than how we speak.”
Bring feedback together. One considered response from the decision-maker is easier to act on than a stream of contradictory messages from five people. Ask which changes affect the agreed scope and which are refinements within the current round.
Then return to the customer journeys. Can someone understand the offer, find the information they need, and complete the next step on a phone? The customer is unlikely to know how many meetings went into choosing the border radius. They will notice if the enquiry form fails.
08 / Budget beyond launch
The build price is only the first number.
Ask for a cost breakdown you can compare over more than the launch month. Domain renewals, hosting, hosted email, maintenance, paid licences and app usage may sit in different accounts and renew at different times. A low introductory price tells you very little about year two.
Keep the build fee separate from the cost of keeping things running. Then ask what changes cost: adding a service page, updating a menu, connecting a new booking tool or fixing a problem caused by a third-party update. A “small change” needs a shared definition.
What does the whole thing cost?
Illustrative figures to start with. Replace them with the amounts in your actual quote. Enter the total email bill for all users. If hosting or email is billed annually, divide that bill by 12 for this tool.
This is a comparison tool, not a KAMROK or provider quote. Use the same tax basis throughout. Avoid counting bundled services twice. It assumes unchanged rates and excludes future redesigns, extra work and unexpected usage.
The figures above are deliberately illustrative. Your actual hosting plan, taxes, exchange rates, usage and scope need to come from the quote and provider terms. If support already includes hosting or licences, put that amount in once rather than counting it twice.
Give maintenance a name and an owner
For WordPress, agree who applies updates, checks the website afterwards and handles a failed update. For an app, also agree who monitors connected services, billing limits and changes to integrations. A service being managed somewhere does not mean every part of your business workflow is looked after.
Ask for the backup schedule, retention, storage location and a tested recovery process that fits the business. How much data could you lose between backups? Who can start a restore? Who checks that payments, forms or bookings work afterwards? Those are better questions than simply asking whether there is a backup.
Performance belongs in this conversation too. Ask to see recent mobile tests, then agree which pages and customer journeys will be checked on your project. Lighthouse is a useful set of automated checks, not a promise about every real visitor, complete accessibility or a Google ranking.
Google: what PageSpeed Insights measures09 / Plan a proper handover
Plan the handover while everyone is still smiling.
Leaving should be a process you understand, not a discovery exercise. Ask how notice works, what outstanding payments need to be resolved, what support ends and what assistance with a move would cost. An organised handover takes work; a charge for agreed migration work is different from finding out the site cannot be handed over at all.
If you are replacing an existing website, the handover also needs to protect what already works. Inventory the important pages and addresses, identify the forms and integrations, and plan redirects for URLs that change. Check domain records and email before any DNS changes. Do not cancel the old setup until the new one has been checked and the relevant records and backups are safe.
Ask another practical question: could a competent developer continue from the information supplied? A folder of files without the database, an app without its service accounts, or a paid theme with an unexplained agency licence can leave a lot of follow-up work.
What I would expect in the handover record
- Domain, hosting, website and app account owners confirmed.
- Your logins tested, with appropriate recovery access.
- Bespoke files, content, code and data covered by the agreement.
- A list of licences, renewal dates and any replacements you need.
- Backup and restore instructions, with responsibility assigned.
- Forms, bookings, payments and important links checked.
- Key old URLs retained or redirected where appropriate.
- A short walkthrough of everyday editing and the support arrangement.
- Developer permissions reviewed after the transition is complete.
Keep that record somewhere the business can reach independently. Review it when staff, suppliers or the website change. Ownership is much more useful when someone knows how to exercise it.
TAKE THIS TO YOUR FIRST CONVERSATION
Ask clearly. Get it in writing.
You can send these to me or any designer you are considering. A clear answer is useful to both sides.
Read the questions before copying
Before we start, could you confirm the following in the proposal? 1. Which business accounts will I control, and which access will you need? 2. Will the domain be registered to my business in an account I can recover? 3. What bespoke work transfers after the agreed payments, and what stays licensed? 4. Where will the website, code and customer data live? 5. What are the build, hosting, domain renewal, email, licence, maintenance and usage costs, and when are they billed? 6. Who handles updates, backups, restore tests and urgent problems? 7. How will we protect existing URLs, email and important customer journeys? 8. What are the payment milestones, feedback rounds and change-request process? 9. What would a handover to me or another developer include, cost and require? I want a clear arrangement that works fairly for both of us.
My take is fairly simple. Buy the address yourself. Understand the accounts and the costs. Pay people fairly for good work. Give them useful feedback, listen to their advice, and make sure the business can keep going if the relationship changes. That is a much better foundation than either side having to guess.
Good websites work. They bring in enquiries, sell products, take bookings and help whole businesses move forward. That is what makes this work exciting to me. I’m proud to be part of it, and I want the website we build to be something you can rely on, understand and keep developing as your business grows.