Frequently Asked Questions

Faciotech is a Ghana-based web infrastructure and digital services provider. On the infrastructure side we handle shared hosting, VPS and dedicated servers, domain registration and transfers, SSL certificates, business email and automated backups. On the services side we build and maintain websites, custom software and CRM/ERP systems, and we run design, digital marketing and managed IT support engagements. Most customers start with a single product, usually a domain or a hosting plan, and add others as they grow. Everything sits in one Client Portal and bills to one account, so you are not reconciling several vendors.

Our customers range from individuals launching a first website to organisations running business-critical systems. That includes startups and small businesses needing hosting, email and a credible web presence; NGOs and schools working to tight budgets with little technical staff; agencies and freelancers managing sites on behalf of their own clients; and larger enterprises needing dedicated infrastructure, custom applications and migration support. Plans are deliberately layered, so you can start on the smallest tier that fits and move up later without rebuilding your site or changing provider.

Three things customers mention most. Breadth: hosting, domains, email, security, custom software and IT support come from one provider on one invoice, so you are not coordinating four vendors when something breaks. Local fit: you can be billed in Ghanaian cedi as well as US and Canadian dollars, and support understands the operating context you work in. Transparency: service health is published on a public status page rather than asked to be taken on trust, and moving an existing site to us is done by our team rather than left to you as homework.

No. Most products are built so a non-technical owner can run them day to day. Hosting includes a control panel with one-click installers for WordPress and other common applications, guided domain and DNS setup, and mailbox creation without editing configuration files. Where something genuinely needs technical work, such as migrating an existing site, pointing DNS at a third-party service or tracing a slow database, our team does it with you rather than sending a link and wishing you luck. If you would rather not touch any of it, managed IT support is available separately.

Your account is created the first time you check out. Choose what you need, a domain, a hosting plan or both, and at checkout you enter your name, email address, contact details and a password. That becomes your Client Portal login. You can also register before buying if you want to look around first. Use an email address you will keep for the long term: invoices, renewal reminders, expiry warnings and password resets all go there, and it is the address support checks to confirm a request genuinely comes from you.

Two channels, and the right one depends on urgency. Live chat suits quick questions and anything actively broken, because someone can look at it with you in real time. A support ticket is better for anything needing investigation, an audit trail, or several exchanges to resolve: server-side errors, migrations, billing queries and account changes. Raise tickets from the Client Portal so they arrive already linked to your services, which skips a round of identity checks. The Support Center brings both channels together with the knowledgebase if you are not sure which you need.

Precision here is what makes the difference between one reply and five. Give the exact domain or service name, since most accounts hold several. Quote error messages verbatim rather than paraphrasing: a status code or a line from a log is far more useful than a report that something is not working. Say what you already tried, and what changed recently, such as a DNS edit, a plugin update or an expired certificate. Add when the problem started and your timezone. A screenshot showing the full browser address bar often answers three questions at once.

Yes. New customers can get help pointing a domain at their hosting, creating mailboxes and connecting them to Outlook or a phone, installing WordPress or another application, requesting and enabling an SSL certificate, and setting up a first backup schedule. If you are arriving from another provider, migration of existing sites, databases and email is handled by our team. The most useful thing you can do is tell support what you are trying to launch and by when, so the work is sequenced around that date rather than discovered piecemeal.

The knowledgebase is the first place to look. It covers the tasks that generate the most tickets: pointing a domain at your hosting, editing DNS records, creating and connecting mailboxes, installing WordPress, requesting SSL, restoring from a backup and reading an invoice. Articles are written against the control panel you actually get, so the steps match what is on your screen. If an article is out of date or does not cover your case, say so in a ticket. That feedback is what drives new articles, and support will walk you through it in the meantime.

The Client Portal is where your account lives. From it you can see every active service and its renewal date, pay or download invoices, register and manage domains, edit DNS records and nameservers, open and track support tickets, and keep your contact and billing details current. Upgrades, cancellations and auto-renewal settings are changed there too. Because tickets raised in the portal arrive already attached to the right service, support can see what you mean without a round of verification. One login covers hosting, domains, email and everything else on the account.

Yes. Prices can be shown and paid in Ghanaian cedi, US dollars or Canadian dollars, and you pick the currency from the selector in the site header before checking out. The currency you buy in is the currency your invoices are issued in for that service, so renewals stay predictable instead of moving with the exchange rate on the day. If you need to change currency on something you already own, raise a ticket rather than re-ordering, and support will confirm what is possible without disturbing the service.

Yes. A public status page reports current service health and any scheduled maintenance. Check it first when something looks wrong. If the platform is reported healthy, the cause is more likely local, such as your own network, DNS still propagating, a cached browser response or a certificate expired on your side, and that narrows the search immediately. If there is an active incident the page carries updates as they happen, so you do not need to open a ticket simply to learn whether it is already known. Maintenance windows are published there in advance.

Yes, and upgrading is the common path. As traffic, mailbox count or database size grows you can move to a larger shared plan, then to a VPS, then to a dedicated server without changing provider or rebuilding the site. Upgrades usually credit the unused value of your current term against the new one. Downgrades are possible wherever the smaller plan can still hold your data, since the real constraint is disk and mailbox usage rather than policy. Ask support before a significant move and they will confirm the sizing and handle the migration itself.

Yes. There is an agency partner programme for people who build and maintain sites for others, and reseller options for those who want to sell hosting under their own brand. Both address the practical problems of running many client sites: consolidated billing, moving a site between accounts cleanly, and one support relationship instead of chasing several hosts on a client's behalf. If you look after more than a handful of sites, talk to us before buying individual plans, because the right structure is usually cheaper than stacking retail products.

Start from the outcome rather than the product. If you need a web address, register the domain first and add hosting second. If you already own a domain elsewhere, buy hosting and point the domain at it, which needs no transfer. If you only need professional email, that can be bought on its own. After checkout your welcome email carries the login and the next steps; the usual order is connect the domain, install or migrate the site, enable SSL, then create mailboxes. Ask about migration at this point and our team will move the existing site for you.

The methods open to you are shown at checkout and again on every invoice, because they depend on the currency you are buying in and where you are billed. Rather than rely on a list that may not apply to your account, look at the payment section of the invoice itself: it offers only the methods that will actually complete for that currency. Invoices can be paid from the Client Portal at any time, and payment updates the service immediately, so there is no waiting period between paying and a suspended service coming back online.

Invoices are generated ahead of the renewal date rather than on it, so there is time to check the amount and pay before anything is interrupted. The invoice arrives by email and appears in the Client Portal at the same moment, and reminders follow if it goes unpaid as the due date approaches. Annual services are invoiced further ahead than monthly ones, which matters when your organisation needs a purchase order or finance sign-off first. If your approval cycle is slow, ask for the invoice early rather than waiting for it.

Displayed prices may exclude VAT, GST or other local taxes. Where tax applies it is calculated at checkout and shown as its own line on the invoice, so the total you approve is the total you pay, with nothing added later. Whether tax applies at all depends on your billing country and the details held on your account, which is why an accurate billing profile matters. If your organisation is tax-exempt, or needs a specific tax identifier printed on invoices, add it to the profile before the next invoice is generated rather than afterwards.

Most products support several billing cycles, commonly monthly, quarterly, semi-annual and annual, chosen at checkout. Longer cycles usually carry a lower effective monthly rate, and they reduce the number of payment events that can fail. Monthly suits a new project you want to stay flexible about; annual suits anything established, and it removes eleven further opportunities each year for an expired card to interrupt your service. Domains are the exception, since registries bill in whole years, so domain registrations and renewals have no monthly option.

Open the Client Portal, select the service, and look for the upgrade or change-cycle option. Where it is offered, the change applies at the next renewal rather than mid-term, and credit from the current term carries over. Not every product exposes it: some are fixed for the term, and domains are always annual. If you cannot see the option, raise a ticket naming the service and the cycle you want, and support will confirm whether the change is possible and what the prorated amount comes to before anything is charged.

Auto-renewal charges your saved payment method shortly before a service expires, so it renews without action from you. Switch it on per service in the Client Portal. It is the single most effective protection against avoidable downtime, because the usual cause of an unexpected outage is not a technical fault but an invoice nobody saw. Two things must stay current for it to work: the card on file, since an expired card fails silently, and the account email, since that is where warnings go. Domains benefit most, as an expired domain is far harder to recover than suspended hosting.

A failed payment triggers reminder emails rather than immediate suspension. There is a grace period, and if the invoice is still unpaid when it ends the service is suspended, which takes the website and email offline but deletes nothing. Data is kept for a further period before removal, so paying late restores the service rather than forcing a rebuild. To fix it, update the payment method in the Client Portal and settle the outstanding invoice; reactivation follows payment automatically. If a card keeps being declined, check with your bank first, since declines are usually issuer-side.

Yes, in the Client Portal under your billing or payment settings. You can add a new method, choose which one is the default for renewals, and remove ones you no longer use. Do this before the card on file expires rather than after a renewal has already failed, since the failure path costs you reminder emails and possibly a suspension. Where several services renew on different dates, changing the default affects future charges only; invoices already issued are paid individually or reissued against the new method.

Yes. Every paid invoice in the Client Portal is itself the receipt. It shows the amount, the date, the method used, the service it covers and your billing details, and it can be downloaded as a PDF or printed. Past invoices stay available, so a full year can be retrieved at accounting time without asking support for copies. If your accountant needs a company name, address or tax identifier that is not currently shown, correct your billing profile first, since new invoices pick those details up automatically.

It depends on the product, and the distinction turns on who has already been paid. Hosting plans commonly carry a money-back period for new purchases, because nothing has been spent externally yet. Domains are generally non-refundable: the registration fee reaches the registry the moment the domain is created and cannot be clawed back, and the same applies to third-party licences and certificates bought on your behalf. Renewals, and services already used for a substantial part of their term, are treated differently from new purchases. Ask support before cancelling, since the options are clearer beforehand.

Submit a cancellation request from the Client Portal against the specific service, choosing whether it should end immediately or at the end of the paid term. End-of-term is almost always right, because you keep what you have already paid for. Before that date, take your own copies of everything: website files, databases, and email, which is the one people forget, since mailboxes are removed along with the hosting. Download a backup rather than relying on ours. If a domain is attached, decide separately whether to keep, transfer or release it.

Cancellation is an explicit instruction to end a service, either immediately or when the current term finishes, and it is recorded as a request against that service. Non-renewal is quieter: you switch auto-renewal off and let the term expire, and nothing happens until that date arrives. The practical difference is reversibility. Turning auto-renewal back on before expiry leaves no gap and no trace. An immediate cancellation, by contrast, takes the service down at once and forfeits the remainder of the term, so choose it only when you want the service gone now.

Hosting that expires is suspended first, meaning the site and mailboxes stop responding while the data is still held, and it is deleted only after a retention window, so prompt renewal restores everything. Domains follow the registry's timetable rather than ours, and it is stricter. After expiry a domain enters a grace period where renewal is still ordinary, then a redemption period where recovery costs substantially more, and finally release, after which anyone may register it. The expensive failure is a lapsed domain, not a lapsed hosting plan.

Update the billing profile in the Client Portal, including company name, address and any tax identifier, and every invoice generated afterwards carries the new details. Already-issued invoices are a different matter: an issued invoice is an accounting record, so what can be altered is limited and depends on whether it has been paid. Raise a ticket with the invoice number and the exact details needed and support will confirm what is possible. If you are moving services to a different legal entity, say so, because that is a change of account rather than a relabelling.

Promotions vary and are applied in the cart rather than on request, so the price shown at checkout is already the discounted one. Longer terms generally cost less per month, and eligible hosting plans have at times included a domain registration for the first year. Consolidating related products on one account reduces administrative overhead even where there is no headline discount, since everything renews on a single invoice. For larger or multi-year commitments, and for agency or enterprise volumes, ask for a quote instead of buying retail, because those are priced case by case.

Two live channels plus self-service. Live chat is the fastest route for quick questions and anything actively broken. Support tickets, raised from the Client Portal, suit anything needing investigation or a written trail: server errors, migrations, billing queries and account changes. Behind both sits a knowledgebase covering the tasks that generate the most tickets, from pointing a domain to restoring a backup. The Support Center gathers all three in one place. Tickets opened from the portal arrive already linked to the right service, which removes a round of identity checks before work can start.

Anything on the infrastructure we run, and a good deal beyond it. That covers DNS records and nameservers, domain registration and transfers, hosting configuration and resource limits, mailbox creation and mail client setup, SSL issuance and installation, backups and restores, migrations from another provider, and diagnosing sites that are slow, erroring or unreachable. Support also handles account matters: invoices, upgrades, cancellations and access changes. Where an issue turns out to sit inside your own application code or a third-party plugin, you will get a clear diagnosis and best-effort guidance rather than silence.

Check the public status page first. If an incident is already open you will see it there with updates as they come, which saves you writing a ticket to ask a question that is already answered. If the platform reports healthy, the problem is likely specific to your service, so open a ticket. Include the affected domain, the exact error or status code, the time it started with your timezone, and whether it affects everyone or only you. For anything actively down, live chat is faster because someone can look while you wait.

Match the channel to the urgency. Live chat is the right call for an active interruption: a site that is down, email that has stopped flowing, a checkout that is failing. Someone can look at it in real time rather than in a queue. Tickets suit issues that need logs, screenshots, database work or several rounds of investigation, and they keep an ordered record you can refer back to. Say plainly in the first message what is broken and what it is costing you, because that is what determines how a case is handled.

Yes, and moving an existing site to us is done by our team rather than left to you. Give us your current host, the control panel or access method, and the domains involved, and the transfer is planned around a low-traffic window to keep downtime short. The usual approach is to copy the site, databases and email across first, test it on a temporary address, and only then change DNS, so the switch is a cutover rather than a gap. Tell us about anything unusual up front: custom cron jobs, non-standard PHP versions or large mailboxes.

Hosting carries a published 99.9% uptime target, and rather than ask you to take that on trust we publish live service health on a public status page you can check at any time. Two things sit outside that figure by definition. Scheduled maintenance is announced in advance on the status page and run in low-traffic windows. Third-party outages, such as a registry, a payment provider or an upstream network, can affect what you see even when our own platform is healthy. Checking the status page first tells you which of those you are looking at.

Use the Forgot Password link on the Client Portal login page; a reset link is emailed to the address on the account. This is the main reason to keep that address current and reachable, because losing access to it makes recovery considerably harder. Choose a long, unique password rather than a variation of one you use elsewhere, and store it in a password manager instead of a browser profile shared with other people. Enable two-factor authentication once you are back in: the portal controls billing and DNS, so it is worth protecting properly.

Open the Client Portal and go to Services. Each product has its own Manage view showing the current status, the renewal date, the resources allocated, and the actions available: renew, upgrade, change billing cycle, toggle auto-renewal or request cancellation. Domains have their own area for nameservers, DNS records, contact details, transfer locks and authorisation codes. Invoices and tickets are listed separately and both link back to the service they relate to, so you can trace a charge or a past problem to the exact product without searching your email.

State the goal, not just the symptom: what you were trying to achieve, the exact steps you took, and what happened instead. Name the domain or service, since accounts commonly hold several. Paste error text verbatim rather than describing it, and attach a screenshot with the full browser address bar visible. Note anything that changed recently, because a DNS edit, a plugin update or an expired card explains a large share of sudden problems. Finally, say how urgent it is and what is blocked, so the case is handled at the right pace.

Live chat and tickets are the primary channels, and they are deliberately the ones we commit to, because they give consistent coverage and leave a written record of what was diagnosed and changed. Phone availability varies by product and engagement, and is more commonly part of managed IT support arrangements than standard hosting. For anything urgent, live chat generally reaches someone faster than a call queue and lets them work on the problem while you describe it. If your organisation needs a named contact or a phone escalation path, raise that with sales.

Support covers the layers we run: the server, DNS, SSL, email delivery, resource limits and platform-level faults. That already resolves many problems that look like application bugs, since a plugin failing to save or an upload timing out is often a PHP limit or a permissions issue rather than the plugin itself. For faults genuinely inside a third-party plugin or theme, or in custom code, you will get a clear diagnosis and best-effort guidance, but the fix belongs with that developer. Where you would rather we did the work, custom development can be quoted separately.

Open a sales ticket or use the contact form and describe the outcome you want rather than the technology you assume you need. Useful detail includes what the system must do, who will use it, roughly how many users, anything it must integrate with, your timeline, and any budget range you are working within. Links to examples you like, or to a site doing something similar, communicate more in one line than a page of description. You will get a scoped response, and larger pieces of work are quoted case by case rather than priced off a list.

Give people their own access rather than sharing yours. Where the product supports additional users, create a separate account for the developer or agency with only the permissions they need, so their activity is distinguishable from yours and access can be withdrawn cleanly when the engagement ends. Never send passwords by email or chat; use a password manager's sharing feature or a one-time secret link. For hosting, a separate control-panel or FTP user scoped to one site is safer than the master account. Review who still has access after any project finishes.

Four things on a schedule. Keep the application, its plugins and themes updated, since known vulnerabilities in outdated components are the most common route to a compromised site. Rotate passwords for the portal, control panel, database and mailboxes, and remove accounts belonging to people who have moved on. Verify that backups actually restore rather than assuming they run, because an untested backup is not a backup. Review security settings periodically. For anything beyond a trivial change, test on a staging copy first rather than editing a live site.

Use the abuse reporting channel for phishing pages, malware distribution, impersonation, spam or other misuse involving a domain or service. A report is only as good as its evidence, so include the full URL, the message or page in question, and for email the complete headers rather than the visible body, since headers are what identify the real source. Add timestamps with the timezone. Reports are reviewed under the abuse response process. If your own site has been compromised and is sending spam, say so directly, as that is handled as recovery rather than enforcement.

WHOIS privacy replaces your personal contact details in the public WHOIS record with a forwarding service, which cuts the volume of spam and social-engineering attempts that follow a new registration. Availability is set by the registry rather than by us, so it varies by extension: many generic domains support it, while some country-code extensions publish certain fields regardless. Privacy does not hide ownership from a court order or a legitimate legal process, and it should never be used to make a business harder to contact. Registrant details behind the privacy service must still be accurate.

A registrar lock, sometimes shown as transfer lock or clientTransferProhibited, tells the registry to refuse transfer requests for the domain. It is the cheapest protection you have against domain hijacking, which typically starts with a compromised email account rather than any technical attack on DNS. Leave it on permanently and switch it off only in the moment you are deliberately transferring the domain elsewhere, then confirm it is back on afterwards. The lock does not prevent you editing DNS, nameservers or contacts, so it costs you nothing in day-to-day use.

DNSSEC signs DNS records cryptographically so a resolver can verify that the answer it received genuinely came from the zone's operator and was not altered in transit. It closes off cache-poisoning and spoofing attacks, where a forged response quietly sends your visitors somewhere else. Support depends on two things agreeing: the domain extension's registry must accept the signing records, and the DNS platform hosting the zone must be able to sign. Because a misconfigured or stale key makes a domain resolve nowhere at all, ask support to enable and verify it rather than doing it piecemeal.

The Acceptable Use Policy sets out what may not be hosted or sent from our network. In practice it prohibits the things that endanger other customers and the reputation of shared infrastructure: malware distribution, phishing pages, bulk unsolicited email, fraud, and content that is illegal in the jurisdictions we operate in. It also covers resource abuse, where one account degrades service for everyone on a shared server. Confirmed violations can lead to suspension, and serious cases to termination. If you are unsure whether a planned use qualifies, ask before you launch it rather than afterwards.

Hosting plans can include security tooling and scanning options, and where malware is detected on shared infrastructure it is acted on, because an infected site puts every other account and the server's mail reputation at risk. Scanning is a safety net rather than a strategy. The measures that actually prevent compromise are keeping the application, plugins and themes patched, removing components you no longer use, choosing long unique passwords with two-factor authentication where offered, and limiting who holds administrative access. Most compromises we see trace back to an outdated plugin or a reused password.

Reports go through the abuse response process, and how quickly one moves depends almost entirely on the evidence attached. Include the full URL of the offending page, or for email the complete message headers rather than a forwarded copy, since headers identify the real origin and a forward usually destroys them. Add timestamps with the timezone, and explain what is being impersonated so the claim can be verified. Confirmed phishing and impersonation are treated as urgent because the harm compounds while the page stays up. Deliberately false reports are also taken seriously.

How personal data is collected, used and retained is set out in the Privacy Policy, which is the authoritative statement rather than anything summarised here. Two practical points matter for your own security. Keep the account profile accurate, because security notices, breach warnings and password resets go to the address on file, and an old address means those notices reach someone else. And treat the data you hold on your own visitors as your responsibility: if your site collects personal information, you need a lawful basis, a privacy notice of your own and a way to honour deletion requests.

Yes, and it is worth doing. The Client Portal holds billing details, DNS control and the ability to transfer domains, so an attacker who reaches it can do considerably more damage than by defacing a website. Enable two-factor authentication in your account security settings, and prefer an authenticator app over SMS where you have the choice, since SMS can be intercepted through SIM-swap attacks. Store the recovery codes somewhere you can reach without the phone, because losing both the device and the codes turns a login into a lengthy identity-verification exercise.

Treat backups as a system that must be tested rather than a box that is ticked. Backups should be encrypted in transit and at rest, with access restricted to people who genuinely need it, and at least one copy kept somewhere separate from the machine being protected, so that a compromise or hardware failure cannot take the original and the backup together. Keep enough history to survive a problem you notice late, since damage discovered a week after the fact is useless against a single overnight copy. Most importantly, restore one periodically and confirm the result actually works.

Act in this order. Take the site offline or into maintenance mode so it stops harming visitors and your domain reputation. Change every relevant password: portal, control panel, database, mailboxes and any application admin account. Identify how they got in, usually an outdated plugin, theme or a reused password, because restoring without closing that door simply reinfects the site. Restore from a backup taken before the compromise, then apply all outstanding updates before putting it back. Support can help with server-side cleanup and locating the entry point. Afterwards, review who holds administrative access.

HTTPS requires a valid SSL certificate for the domain, and hosting plans include SSL options so a standard site can be served over HTTPS without buying anything separately. Certificates you have purchased elsewhere can also be installed. Two things are worth checking after issuance: that the site actually redirects HTTP to HTTPS rather than merely accepting both, and that no page still loads images, scripts or fonts over plain HTTP, since that mixed content triggers browser warnings on an otherwise valid certificate. Certificates expire, so confirm renewal is automatic rather than assuming it.

Legal requests are handled under published legal processes, and complete documentation is what determines how quickly one is dealt with. A request should identify the specific service, domain or content precisely, state the legal basis being relied on, and come from a party entitled to make it. Vague or unsubstantiated demands take longer because they have to be clarified before anything can be assessed. Where we are required to act we do, and where a request is not properly founded we will say so. Send legal correspondence through the published channel rather than to support.

Yes. Copyright and other infringement claims go through the abuse reporting channel, and a report must contain enough for the claim to be verified: the exact URL of the material complained of, identification of the original work and where it can be seen, and a statement of your relationship to the rights being asserted. Reports that simply assert infringement without those details cannot be acted on. Where content is removed, the account holder is normally informed and may respond. Deliberately false claims carry consequences, so check ownership before filing.

Publish all three DNS records and keep them consistent. SPF lists the servers permitted to send mail for your domain. DKIM signs outgoing mail so a receiver can verify it was not altered and genuinely came from you. DMARC then tells receivers what to do when a message fails those checks, and gives you reports showing who is sending as your domain. Start DMARC in monitoring mode, read the reports, and only tighten to quarantine or reject once legitimate senders pass. Add strong mailbox passwords and multi-factor authentication, since a compromised mailbox bypasses all three.

Notification is matched to severity and scope. Issues affecting a single account are raised directly with that customer through a support ticket and the account email. Anything platform-wide is published on the status page as it develops, so you can check current state without waiting for a message. Genuinely critical issues, particularly those requiring you to act, such as rotating a credential or applying an update, are communicated by email to the address on the account. This is the practical reason to keep that address current and monitored: it is where anything time-sensitive lands.

Nameservers are changed in the domain management area of the Client Portal, under the domain itself rather than under hosting. Replace the existing entries with the ones your host gave you and save. The change is handed to the registry within minutes, but resolvers worldwide keep cached copies of the old answer, so expect a period during which some visitors reach the new host and others still land on the old one. That window is normally hours rather than the full day people expect. Leave the old site running until it has settled, so nobody meets an error.

DNS records are edited in the zone editor for the domain, which is separate from the nameserver setting: the zone editor only takes effect while the domain points at our nameservers. An A record maps a name to an IPv4 address and is what sends a domain to a server. A CNAME points one name at another name, which is what most third-party services ask for. MX records direct email and must point at your mail host, not your website. Lower the TTL before a planned change so it propagates quickly, and raise it afterwards.

Transfers need three things in place at the losing registrar: the domain unlocked, WHOIS privacy temporarily off if it hides the administrative contact, and a current authorisation or EPP code, which you request from them. Start the transfer from the Client Portal and approve the confirmation email that follows, since an unanswered email is the usual reason a transfer stalls. Registry rules block transfers within sixty days of registration or a previous transfer. A transfer normally adds a year to the registration, and your DNS records travel only if you copy them across first.

Search for the name from the domain area of the site. The search reports whether it is available and, for names that are taken, usually suggests alternatives across other extensions. Add the one you want to the cart and complete checkout; registration is normally live within minutes for common extensions, though some country-code registries take longer. You will be asked for registrant contact details, and these must be accurate: registries can suspend a domain for demonstrably false WHOIS data. Use an email address you will still control in a year, since renewal notices go there.

It depends on who you are trying to reach. A .com reads as international and is what most people type by habit, so it suits anyone selling beyond one country. A Ghanaian extension signals local presence clearly, which matters for trust and for local search, and the name you want is far more likely to still be free. Many businesses register both, point one at the site and redirect the other, which protects the brand for the cost of a second registration. Availability, requirements and pricing differ by extension and are shown in the domain search.

Registration itself is usually complete within minutes, and the domain will appear in your Client Portal straight away. Resolving worldwide takes longer, because recursive DNS servers cache answers: expect a period where the site works for you and not yet for someone on a different network. That is normally hours rather than the full day people expect. If it has been well over a day, the cause is more often a missing or wrong DNS record than propagation, so check that the A record points at your hosting before waiting any longer.

Yes. A domain and hosting are separate products and many people register a name long before building anything, simply to secure it. An unused domain can sit parked, forward to a social profile or another site, or hold only email. You can add hosting later without re-registering or transferring anything. The reverse also works: if you already own a domain elsewhere you can buy hosting here and point the domain at it, which needs a nameserver change rather than a transfer.

The registry's timetable applies, not ours, and it is stricter than people expect. At expiry the domain stops resolving, so the website and any email on it go down immediately. It then enters a grace period during which renewal is still ordinary. After that comes redemption, where recovery is possible but costs substantially more because the registry charges a restoration fee. Finally it is released and anyone may register it. Once released it is gone, and buying it back from a new owner is a negotiation. Keep auto-renewal on for domains specifically.

Renewal invoices are generated ahead of the expiry date and can be paid from the Client Portal like any other invoice. The safer approach is auto-renewal: switch it on per domain so renewal happens without anyone remembering. Two things must stay current for that to work, the payment method on file and the account email address, because an expired card fails silently and the warnings go to that address. You can also renew early to add years in advance, which most registries allow up to a limit and which removes the risk entirely.

Yes. A domain you have registered is yours and you can move it to another registrar whenever you like. From the Client Portal, unlock the domain, disable WHOIS privacy if it masks the administrative contact, and request the authorisation or EPP code, then give that code to the gaining registrar. Registry rules block transfers within sixty days of registration or of a previous transfer, which is a registry restriction rather than ours. Copy your DNS records to the new provider before the transfer completes, or the site and email will stop resolving during the switch.

A subdomain is a prefix on your existing domain, such as shop.example.com or blog.example.com, and it costs nothing extra because it belongs to a domain you already own. Create one from your hosting control panel, which sets up both the DNS record and a folder for its files in one step. They suit anything you want separated from the main site: a staging copy, a client portal, a documentation area, or a service hosted somewhere else entirely. Search engines can treat a subdomain as a distinct site, which matters if you are weighing it against a subfolder.

Two routes, and the right one depends on where you want DNS managed. Changing the nameservers hands the whole zone to the other provider, which is simplest when they will run everything including your email. Alternatively keep our nameservers and edit records in the zone editor: an A record to their IP address, or a CNAME if they gave you a hostname rather than an IP. Watch your MX records if you take the nameserver route, since moving the zone moves email with it and mail stops without them being recreated.

Forwarding sends visitors who type one domain to a different address automatically. It is what you want for defensive registrations and alternate spellings: point the misspelling and the second extension at your real site so nobody lands on nothing. It also suits a short campaign URL. What it is not good for is running your actual site, because a forward is a redirect rather than hosting, and search engines credit the destination. If you want two domains to both serve a real site, host one and forward the other rather than duplicating the content.

Work through it in this order. Check the domain has not expired, which is the single most common cause and takes seconds to rule out in the Client Portal. Then check the nameservers point where you expect. Then check the A record points at the right server. A default parking or hosting-provider page usually means DNS is correct but nothing has been installed at that address yet. A certificate warning alongside the error points at SSL rather than DNS. If it works on your phone but not your laptop, that is local caching and it will clear.

There is no cap on how many domains you register under a single Client Portal login, and keeping them together is much easier to manage than spreading them across registrars: one renewal calendar, one invoice, one place to edit DNS, and one support relationship. Hosting is what carries limits, since a plan permits a set number of sites, so twenty parked domains cost nothing extra while twenty hosted sites need a plan sized for them. If you manage domains for clients rather than yourself, ask about the agency and reseller options instead of stacking retail registrations.

The range covers four broad needs. Shared hosting suits personal sites, brochure sites and small businesses. WordPress-optimised hosting is shared hosting tuned for WordPress specifically, with tooling that matters for that platform. Reseller hosting is for agencies and freelancers selling hosting on to their own clients under their own brand. VPS gives isolated, guaranteed resources and root-level control for growing sites and custom applications, and dedicated or cloud servers sit above that for heavy workloads or strict isolation requirements. You can move up the range later without changing provider or rebuilding.

Shared hosting places a number of sites on one server, with the operating system, web server, PHP and mail handled for you and resources allocated per account. It is the right starting point for personal sites, small business sites, portfolios and new projects, because you get a working, secured, backed-up environment without administering anything. The trade-off is that you share the machine, so resource limits apply and a genuinely busy site will eventually outgrow it. That is a normal progression rather than a failure: the upgrade path to VPS keeps the same account and the same support.

WordPress hosting is shared hosting configured specifically around WordPress rather than a different product. In practice that means the PHP settings, caching and server tuning suit WordPress's actual behaviour, and the platform-specific tasks are catered for: migrating an existing site in, staging so you can test a theme or plugin update before it reaches visitors, and sensible defaults for the things that most often break a WordPress site. If you run WordPress it removes a set of decisions you would otherwise have to make yourself. If you run something else, standard shared hosting is the better fit.

A VPS is a virtual machine with resources reserved for you alone: guaranteed CPU and memory, your own operating system, and root-level control over what is installed. That matters when shared hosting starts to constrain you. The usual triggers are sustained traffic growth, a site that has become slow under load, an application needing a specific PHP version, extension or background worker, or a compliance requirement for isolation from other tenants. If your current site is fast and comfortably inside its limits, a VPS adds administrative responsibility without adding speed, so upgrade when the constraint is real.

A dedicated server is one physical machine allocated entirely to you, which gives predictable performance and complete isolation, and suits sustained heavy workloads or requirements that rule out shared hardware. Cloud servers are virtualised, so resources can be resized as demand changes and new instances provisioned quickly, which suits workloads that vary or need to scale in a hurry. The practical trade-off is predictability against flexibility: dedicated hardware gives you a known, fixed machine, while cloud gives you elasticity. Which is cheaper depends entirely on how steady your load actually is.

Far less than most people assume. A typical business or brochure site, including its images, occupies well under a gigabyte, and email is usually the part that grows. Bandwidth is consumed by visitors downloading pages, so unless you serve video or large downloads it is rarely the constraint. The honest advice is to start on the smallest plan that fits and upgrade when something actually binds, because paying for headroom you never use is the most common waste in hosting. Usage is visible in your control panel, so you can watch it rather than guess.

On plans that permit multiple sites, yes, and it is usually far cheaper than separate accounts. Each site gets its own domain, its own folder and its own email, while sharing the plan's disk, bandwidth and CPU allowance. The trade-off is worth understanding: sites on one account share resources, so a busy one can slow its neighbours, and they share a security boundary, meaning a compromise in one can reach the others. For unrelated businesses, or anything handling payments, separate accounts are the safer arrangement even though it costs more.

Hosting plans commonly carry a money-back period for new purchases, so you can put a real site on the platform and judge it in practice rather than from a specification. Two things sit outside it. Domains are non-refundable, because the registration fee reaches the registry the moment the name is created and cannot be recovered. The same applies to third-party licences and certificates bought on your behalf. If you want to evaluate before committing at all, tell support what you intend to run and they will tell you plainly whether the plan you are considering fits.

You do not do it yourself. Migration is handled by our team: give us your current host, the control panel or access method, and the domains involved, and the transfer is planned around a low-traffic window. The sequence matters, and it is what keeps downtime short. We copy the site, databases and email across first, test on a temporary address so problems surface before anyone sees them, and only then change DNS. That makes the switch a cutover rather than a gap. Flag anything unusual up front, such as custom cron jobs, a specific PHP version or very large mailboxes.

Hosting comes with a full control panel, which is where the day-to-day work happens without needing a developer. From it you create and manage email accounts, add domains and subdomains, edit DNS records, install applications such as WordPress through a one-click installer, manage databases, upload files or use FTP, request and install SSL certificates, schedule cron jobs and restore from backups. It also reports your disk, bandwidth and resource usage, which is how you tell whether you are near a plan limit rather than discovering it when something stops.

Yes, and they are the common case rather than a special one. WordPress can be installed in a few clicks or migrated in from another host, and plans are configured with the PHP settings a WordPress site actually needs rather than bare defaults. Multiple PHP versions are available so an older application keeps working while a newer one gets a current runtime, and you can change version per site. MySQL databases are included, with a database manager in the control panel for imports, exports and backups. Other common applications install the same way.

Automated backups run on hosting plans and can be restored from the control panel, which covers the ordinary disasters: a bad plugin update, a deleted file, a botched theme edit. Treat that as a safety net rather than your whole strategy. Keep your own copy of anything you cannot recreate, especially before a major change, because a backup you control is one nobody else's schedule can affect. Take a manual backup immediately before updating a site, since that is when things break, and verify a restore works before you actually need it.

Hosting plans include SSL options, so a standard site can be served over HTTPS without buying anything separately, and certificates purchased elsewhere can also be installed. Two things are worth checking once it is active. Confirm the site genuinely redirects HTTP to HTTPS rather than merely accepting both, since accepting both leaves the insecure version indexable. And check no page still loads images, scripts or fonts over plain HTTP, because that mixed content triggers a browser warning on an otherwise valid certificate. Certificates expire, so confirm renewal is automatic instead of assuming it.

Physical location affects latency, which is the delay before a page starts arriving, so hosting closer to your audience genuinely helps. It matters less than people think for a well-built site, because the larger wins are usually image weight, caching and the number of requests a page makes, all of which you control regardless of where the server sits. If your visitors are concentrated in one region, say so before you buy and support will advise on placement. For a genuinely global audience a content delivery network in front of the site is the better answer.

It depends which limit. Disk and email quotas usually stop new writes, so uploads and incoming mail fail while the existing site keeps serving, and clearing space resolves it immediately. CPU and memory limits typically slow the site or return errors during peaks rather than taking it offline permanently. You will not be silently cut off: hitting a limit repeatedly is a signal to move up a tier, and support will tell you which resource is actually binding rather than selling you the next plan by default. Usage is visible in the control panel.

Managed IT Services means ongoing responsibility for your IT environment rather than help when something has already broken. Under a defined plan that typically covers day-to-day user support, oversight of devices and network equipment, patching and update management, account and access administration, backup verification, and routine security hygiene. The distinction from break-fix is that maintenance is proactive and the cost is predictable: you are paying for the environment to stay healthy rather than per incident. Scope, hours and escalation paths are agreed in advance so both sides know what is covered.

Help Desk Services is the end-user layer: the people in your organisation who cannot print, cannot get into an account, have a laptop that will not start, or need software installed. Requests come in through a ticketing system so nothing is lost in someone's inbox, are triaged by urgency, and escalate to deeper technical work when the fix is not a desktop one. Because it is ticketed you get a record of what breaks most often, which is usually where the real cost sits. It can be bought on its own or as part of a wider Managed IT plan.

Choose Managed IT when the cost of downtime exceeds the cost of prevention, when you have no internal IT person, or when you need predictable monthly spend rather than unpredictable emergencies. It suits organisations where several people depend on the same systems and a failure stops work. One-time support fits a specific, bounded task: a migration, a new office setup, recovering from a particular incident, or a security review. Many organisations start with a one-off engagement and move to a managed plan once it becomes clear which problems keep recurring.

Most issues are resolved remotely, and remote is usually faster because there is no travel between the request and the fix: account problems, software faults, configuration, email and server work can all be handled that way. Onsite attendance is for what genuinely requires hands on hardware, such as network cabling, router and switch installation, device replacement or a new office build-out. Onsite availability depends on your location and the scope of the engagement, so raise it when the work is being scoped rather than assuming it, particularly if you operate from several sites.

Onboarding exists so that support is not guessing when the first incident arrives. It usually starts with an inventory of what you actually run: devices, servers, network equipment, accounts and the software people depend on. Then access is established under least privilege, with credentials stored properly rather than emailed. A baseline security review follows, covering patch levels, backups, and who holds administrative rights. Finally the working agreement is set: support hours, how to reach us, what counts as urgent, and escalation paths. Documentation from this stage becomes the reference for everything afterwards.

Access is granted on a least-privilege basis: the minimum permission needed for the task, held for as long as the work requires and revoked afterwards. Administrative rights are requested explicitly rather than held permanently by default. Credentials are kept in secure storage rather than in email, chat or a spreadsheet, and shared through mechanisms that do not leave a copy behind. Named individual accounts are used in preference to shared logins, so activity is attributable. When an engagement ends, access is withdrawn and you should verify that independently rather than take it on trust.

Yes. That covers the administration these platforms need in practice: creating and removing users as people join and leave, mailbox and shared-mailbox setup, licence assignment, distribution lists, security and access policies including multi-factor authentication, and the DNS records that make mail work correctly for your domain. Migration between platforms, or from an older mail system, can also be handled. The most valuable part is usually the leavers process, since dormant accounts with valid credentials are a common and avoidable route into an organisation. Exact scope is agreed in the service plan.

Yes. That includes router and firewall configuration, segmenting the network so guest and payment traffic are not sharing a flat space with everything else, wireless coverage and channel planning, and the practical causes of unreliable Wi-Fi, which are more often placement, interference and oversubscribed access points than bandwidth. We can review an existing setup and recommend changes, or specify and configure equipment for a new site. Where the fault turns out to sit with your internet provider, we deal with them directly rather than leaving you to relay technical detail.

Security services can include hardening, patch and update management, access reviews, and alerting on suspicious activity. How deep the monitoring goes depends on the plan and the tooling in place, and it is worth being clear-eyed about that: continuous monitoring with investigation is a different commitment from periodic review and alerting, and they cost differently. For most small organisations the largest risk reduction does not come from monitoring at all but from the basics, namely multi-factor authentication everywhere, current patches, tested backups and removing accounts people no longer need.

We help design the backup routine and the recovery runbook, which are two separate things and both are needed. The routine covers what is protected, how often, how long history is kept and where copies live, including at least one separate from the system being protected. The runbook covers what happens during an actual failure: the order systems come back, who does what, and how long it should take. The part organisations skip is testing. A restore that has never been rehearsed is an assumption, so schedule test restores and treat a failed one as a live finding.

Response targets are set by the service tier and the severity of the request, and they are agreed in writing when the plan is scoped rather than left implicit. The principle is that a critical outage stopping work for multiple people is prioritised above a routine how-to question, and both are ahead of a scheduled change with no deadline. What matters more than a headline figure is that severity is defined the same way by both sides, so ask for the severity definitions along with the times and check they match how your organisation actually works.

Yes, and the sensible approach with a limited budget is sequencing rather than a smaller version of everything. We propose phased plans that address the highest risk first, which for most young organisations means email security and account protection, then tested backups, then patching and device management. Those three cover the overwhelming majority of incidents that actually harm small organisations. Later phases add monitoring, documentation and formal support hours as the organisation grows. Starting narrow and real beats a broad plan that is never fully implemented.

Yes. Documentation is what stops the same problem being diagnosed from scratch every time, and it is what makes an organisation resilient to a key person leaving. Where in scope we maintain an inventory of systems and how they connect, notes on changes as they are made, access lists showing who holds what, and runbooks for recurring procedures such as onboarding a new employee or recovering a system. It also protects you commercially: documented environments are far easier to hand to another provider, which is precisely why you should insist on having it.

Yes. Acting as technical liaison with internet providers, SaaS vendors and hardware suppliers is often the most useful part of the service, because those conversations go faster when someone on your side can answer technical questions directly and reject an incorrect diagnosis. That covers chasing an ISP over a line fault, escalating with a software vendor, arranging hardware replacement under warranty, and coordinating work where a problem crosses two vendors who each blame the other. You stay the account holder and decisions remain yours; we handle the technical exchange.

Contact sales or submit a request through the Services area with a short description of your organisation: roughly how many people, how many locations, what systems you depend on, and what is currently going wrong or taking too much of someone's time. That last point matters most, because a plan built around your actual pain is more useful than one sized on headcount alone. A scoping conversation follows to establish coverage, hours and escalation, and you receive a written proposal. Larger or multi-site engagements are quoted case by case.

We build and maintain custom business applications: CRM and ERP systems, internal portals, customer-facing tools, and automation that removes repetitive manual work. Typical engagements replace a process currently held together by spreadsheets, email threads and someone's memory, where the cost is not licence fees but the hours and errors involved in running it by hand. Work covers the full lifecycle, from discovery and design through build, data migration, testing and launch, and then ongoing maintenance. Because we also run hosting, the application and the infrastructure it depends on come from one place.

A CRM faces outward, toward the people you sell to and serve. It holds contacts and companies, tracks deals through a pipeline, records every interaction, and shows what is likely to close and what has gone quiet. An ERP faces inward, coordinating how the business runs: inventory, purchasing, finance, payroll and HR, with one set of records rather than a system per department. The distinction blurs at the edges, and many organisations need both. The practical question is which problem costs you more today, losing track of customers or losing track of operations.

Scoping starts with discovery rather than a feature list, because the feature list is usually a guess at the solution. We work through what the business is trying to achieve, who will actually use the system and what their day looks like, the workflows it must support, what data exists and where it currently lives, and how you will know it worked. That produces a written scope, a delivery plan with phases, and a timeline. Where a requirement is uncertain we say so and price it separately rather than burying the risk in an optimistic estimate.

Yes. Product design is normally part of the build rather than an extra, because an internal system that people avoid using is a failure regardless of how correct the logic is. Work covers the flows people follow, the screens themselves, and the details that decide whether a system is adopted: sensible defaults, clear error messages, forms that do not ask for what the system already knows, and layouts that survive on the devices staff really use. Getting this right reduces training time and the volume of support questions after launch.

Yes, and integration is often where most of the value sits, since a system that does not talk to the tools around it just creates a second place to type things. Common integrations include payment gateways, email and SMS providers, accounting platforms, and other business systems through their APIs. Feasibility depends on what the other side exposes: a documented API is straightforward, a closed system with no export is not, and something in between may need a scheduled file exchange. We check that before committing rather than discovering it mid-build.

Migration is treated as its own workstream, because it is where projects most often slip. We map the source data and agree what actually needs to move, since legacy systems accumulate records nobody has used in years. Formats and values are validated and cleaning rules agreed with you, as the decisions about duplicates and incomplete records are business decisions, not technical ones. Test imports run into a non-production environment, and you check the results against what you know to be true. Only then does the final migration run, with the old system retained as a reference.

Yes. Applications we build can be hosted on infrastructure sized to them, typically a VPS or cloud server where the application needs isolated resources, specific runtime versions or background workers. Having the application and its hosting under one roof removes the argument that follows a problem in a split arrangement, where the developer blames the host and the host blames the code. It also means backups, SSL, monitoring and updates are handled as one thing. If you would rather host elsewhere, that is fine, and we will document what the environment requires.

Security is built into how the work is done rather than reviewed at the end. That means authentication and role-based access control designed in from the start, validating and escaping input so injection and cross-site scripting have nowhere to land, encrypting sensitive data in transit and at rest where appropriate, and keeping secrets out of source control. Dependencies are tracked and updated, because most vulnerabilities arrive through libraries rather than your own code. Changes go through review before deployment, and production environments are hardened rather than left at defaults.

Changes are expected, since no discovery anticipates everything, so there is an agreed process rather than an argument. A requested change is written down, assessed for its effect on scope, timeline and cost, and approved by you before any work starts. Small clarifications are absorbed; anything that moves the delivery date or the price is quoted first. The reason for the formality is protective on both sides: it prevents a project quietly growing without anyone deciding to grow it, which is the most common way fixed-scope work turns into an overrun.

Ownership is set out in the project agreement rather than assumed, and it is worth reading that clause before signing anything, with any supplier. Commonly, ownership of the custom code written for you transfers on full payment. Two things usually sit outside that. Third-party libraries and frameworks remain under their own open-source or commercial licences, which is normal and does not restrict your use of the system. And any pre-existing tooling we bring is generally licensed to you rather than assigned. If you need source-code escrow or a specific arrangement, raise it during scoping.

Yes, and it is worth planning for rather than treating as optional. A support plan can cover bug fixes, security and dependency updates, monitoring, backups, and a budget of hours for small enhancements. The case for it is that software decays even when untouched: the platform it runs on gets security updates, browsers change, integrations alter their APIs, and business processes move on. Without maintenance those accumulate until a routine change becomes a rebuild. Scope and response expectations are agreed up front so you know what is covered before you need it.

Mobile development can be scoped, but the first question is whether you need a native app at all. A responsive web application reaches every device from one codebase, needs no app-store approval, and updates instantly, which for most internal tools and customer portals is the better economic answer. A native app earns its cost when you genuinely need offline operation, push notifications, camera or location hardware, or presence in an app store for discovery. We will tell you which case you are in rather than defaulting to the more expensive one.

Testing runs alongside development rather than as a phase at the end. Functional checks confirm each piece behaves as specified. You then run user acceptance testing on a staging environment that mirrors production, because the people who do the job daily find the cases a specification never described. Key workflows are checked under realistic data volumes, since something that is fast with fifty records can be unusable with fifty thousand. Releases go to staging first and only then to production, so a problem is found on a copy rather than in front of your users.

It depends on complexity, and any figure quoted before discovery is a guess. What we can commit to is shape rather than a single date: work is phased so something usable arrives early instead of everything arriving at the end. A discovery and prototype phase typically produces a working model you can react to, which is far more informative than a written specification, and it often changes the requirements in useful ways. The full build then proceeds in stages you can see. You will get a timeline with the proposal, along with what could move it.

Start by describing the problem rather than the system you have in mind. Useful detail includes what the business is trying to achieve, who would use it and in what roles, how the process works today including the spreadsheets and workarounds, what it must connect to, and what your deadline is driven by. Send that through the contact form or a sales ticket and a discovery session follows. You receive a written scope, a phased delivery plan and a quote. Discovery is worth doing properly even if you ultimately build elsewhere.

Design work spans full website design, standalone landing pages for campaigns, brand visuals such as logos and colour systems, interface design for applications, and design systems that keep everything consistent as a site grows. The last of those matters more than it sounds: without an agreed set of components and rules, a site drifts as pages are added by different people, and after a year it looks like several sites. Work can be a complete build or a focused piece, such as redesigning a single high-traffic page that is not converting.

Yes, and it is often the sensible approach. If your content is accurate and earning search traffic, replacing it wholesale throws away value for no reason. A redesign can rework layout, navigation, typography, responsiveness and page speed while keeping your existing pages, URLs and messaging intact. Preserving URLs matters: changing them without redirects is one of the most reliable ways to lose established search rankings. Where a page genuinely underperforms we will say so and suggest changes, but keeping working content is the default rather than the exception.

Yes. Designs start from the small screen and scale up, because most visitors to a typical business site arrive on a phone, and a layout designed for desktop first tends to be crammed rather than adapted when it gets there. Working mobile-first also imposes useful discipline: limited space forces a decision about what actually matters on each page. Designs are checked at phone, tablet and desktop widths, including the awkward sizes in between, and on real devices rather than only a resized browser window.

Yes. Send your brand colours, typefaces, logo files in vector format where possible, and examples of existing material you consider correct. We will build layouts and components that follow those rules, and flag anywhere the guidelines do not cover a case the website needs, such as states for buttons and forms, or how the palette behaves on dark backgrounds. Where a guideline actively causes a problem online, usually a colour pairing that fails contrast requirements, we will show you the issue and propose a compliant alternative rather than silently departing from it.

Copywriting can be included as an add-on. If you supply your own text we will still edit it for the web, which is a different medium from print: people scan rather than read, so structure, headings, short paragraphs and a clear next action matter as much as the words. The most common problem with client-supplied copy is that it describes the organisation rather than what the reader gets. That is fixable, and usually improves conversion more than any visual change. Tell us which pages you want written and which you will supply.

Accessibility is treated as part of building it properly rather than an optional extra. That means semantic HTML so screen readers and search engines can interpret the structure, text and interface colours that meet contrast requirements, everything operable by keyboard rather than mouse only, visible focus states, labelled form fields, and alternative text on meaningful images. Beyond being the right thing to do, it overlaps heavily with SEO and general usability, so the same work improves the site for everyone. Tell us if you have a specific standard to meet.

Yes, and the platform choice matters more here than on a brochure site because payments, shipping rules, tax, stock and order management all have to work together. We will work through what you actually sell and how, including whether products vary by size or option, how shipping is priced, whether you sell across borders, and how orders reach whoever fulfils them. That determines whether a standard platform fits or something more custom is warranted. Getting the operational side right is what makes a store workable after launch, not the storefront design.

Platform follows the goal rather than habit. WordPress suits content-led sites where you want to publish regularly and have a large ecosystem available. Our own site builder suits fast launches where you want a professional result without ongoing platform maintenance. A custom build makes sense when the site is really an application, with logic no off-the-shelf platform models well. We will recommend based on who maintains it after launch, how often it changes, and what it must integrate with, and explain the trade-offs rather than simply naming one.

We can source stock imagery and produce simple graphics, icons and diagrams as part of the work. What clients normally provide is the material only they have: photographs of their premises, team, products or actual work, plus final approval on content. That is deliberate, because genuine photography consistently outperforms stock on business sites, particularly for local and service businesses where visitors are assessing whether you are real. If you have no usable images, say so early and we will plan around it rather than discovering the gap during build.

Review rounds are set by the project scope and stated in the proposal rather than left open-ended, which protects both sides. A typical process includes a round after wireframes, when structure and layout are settled and changes are cheap, and a round after visual design. Feedback is most useful consolidated into one response per round rather than arriving piecemeal over days. Changes that go beyond refinement into new requirements, such as adding pages or altering the agreed structure, are handled as a scope change and quoted rather than absorbed silently.

Yes. Speed work usually starts with measurement rather than assumptions, because the actual bottleneck is often not what people expect. Common wins are compressing and correctly sizing images, which are the largest payload on most sites, enabling caching, removing scripts and plugins that are loaded on every page but used on one, deferring what is not needed for the initial render, and moving to a hosting tier that matches the traffic. Speed is worth doing for its own sake: it affects conversion and bounce rate directly, and it is a ranking factor.

Yes, in the sense that the technical foundations are built in: clean readable URLs, a proper heading hierarchy, editable page titles and meta descriptions, structured data where it applies, fast loading, mobile usability, and semantic markup search engines can parse. That is the part design controls. It is worth being clear that this makes a site findable rather than automatically ranked: content quality, relevance and authority do the rest, and no amount of markup compensates for a page that does not answer the question a searcher typed.

Yes. A landing page is built around one goal, whether that is a form submission, a booking or a purchase, and everything not serving that goal is removed, including the navigation that would otherwise let visitors wander off. That single-purpose focus is what makes landing pages convert better than sending paid traffic to a homepage. Conversion tracking can be included so you can see cost per lead rather than guessing. Where you are testing more than one message, variants can be built to compare, provided traffic is sufficient for the result to mean anything.

Yes, in most cases, and it is worth deciding before the platform is chosen rather than after. WordPress and our site builder are both designed for non-technical editing: text, images, and adding pages can be handled by your own staff without touching code. Custom builds can include an admin area for the parts that change often. Where a site needs a developer for routine edits, that is usually a platform mismatch. Tell us who will maintain it and how confident they are, and the recommendation will follow from that.

Send four things: a link to your current site if you have one, two or three examples of sites you like with a note on what appeals about each, who your customers are and what you want them to do, and the pages you think you need. The examples are the most useful part, because visual preference is far easier to show than describe. You will get a proposal covering approach, structure, timeline and cost. If your requirements are unclear, a short discovery conversation comes first.

Services cover search engine optimisation, content strategy and writing, social media support, guidance and setup for paid advertising, analytics and conversion tracking, and conversion rate work on pages that already receive traffic. Engagements are usually shaped around one question: where is the gap between the visitors you get and the enquiries you want. Sometimes that gap is visibility, and the answer is SEO or ads. Often it is not, and a site already receiving traffic simply converts poorly, in which case spending more on acquisition wastes money. We will say which case you are in.

SEO is the work of making a site findable and credible for the searches your customers actually run, split between technical foundations, content that answers those searches, and earning references from other sites. Timescales are genuinely slow and anyone promising otherwise is selling something: technical fixes and obvious gaps can show movement within weeks, while competitive terms usually take months of consistent work. It compounds, which is the appeal, but it does not switch on. If you need enquiries this month, paid advertising is the honest answer and SEO runs alongside it.

Yes, and for a business serving specific towns or regions it usually matters more than national SEO. The work centres on your map listing, which is what appears beside the map for searches with local intent, keeping your name, address and phone number identical everywhere they appear online, since inconsistency undermines confidence in the listing, building pages that genuinely serve each area you cover rather than one page with place names swapped, and encouraging reviews. Local results are also heavily influenced by proximity and reviews, which changes where effort is best spent.

Yes. That covers installing analytics correctly, defining the conversions that actually matter to your business such as form submissions, calls, bookings or purchases, and setting up reporting you will realistically look at. Most analytics installations we inspect record traffic but no conversions, which means they can tell you how many people arrived and nothing about whether it worked. Tracking is also where consent obligations apply, so it needs to be configured to respect the visitor's choice rather than fired regardless. A small dashboard with three real numbers beats an unread report.

Social media management can cover a content calendar, scheduling and posting, basic design assets to accompany posts, and agreed guidelines for responding to comments and messages. The honest framing is that social works well for some businesses and poorly for others, and it depends far more on whether your customers make decisions there than on posting frequency. For many business-to-business and service companies, effort is better spent on search visibility and a site that converts. We will give you that assessment before proposing a calendar you may not need.

We can help with campaign setup, keyword and audience selection, ad copy, the landing pages the traffic arrives on, and conversion tracking so results are measurable. Advertising spend is separate and paid by you directly to the platform, which keeps the budget visible and under your control. The single biggest determinant of whether paid advertising works is usually not the ads but where the clicks land: sending paid traffic to a generic homepage wastes a large share of the budget. Expect landing page work to form part of the engagement.

By outcomes, not activity. The measures that count are leads, enquiries, bookings, sign-ups or sales, and the cost of acquiring each. Traffic and impressions are diagnostic, useful for understanding why a number moved, but they are not the goal, and reporting that leads with them is usually hiding a weak result. We agree the metrics before work starts, along with where the baseline sits today, because improvement is meaningless without a starting point. Some things are genuinely hard to attribute, notably phone calls and word of mouth, and we will say so rather than claim credit.

Yes. Content work can include website copy, blog and article writing, service and location pages, and supporting graphics. Effective content answers a question your customer actually has rather than describing your company, which is the most common failing of business writing. That also aligns with how search works now: pages that comprehensively answer a real query outperform pages assembled around keywords. For technical or specialist industries we will need access to someone who knows the subject, since credible content in those fields cannot be written from the outside.

Yes, and it is frequently the highest-return work available, because you are improving the yield on traffic you already pay for. Typical changes include making pages faster, since abandonment rises sharply with load time, clarifying what you want the visitor to do and making that action prominent, cutting form fields down to what you genuinely need, adding trust signals such as reviews and clear contact details, and fixing the mobile experience where most visitors actually are. We start by identifying where people currently drop out, then change that, rather than redesigning everything.

Yes. That includes setting up your lists and sign-up process, templates that render correctly across mail clients, basic automation such as welcome sequences and follow-ups, and the authentication records that decide whether your mail arrives at all. Deliverability is where most email programmes quietly fail: without correct SPF, DKIM and DMARC on your sending domain, a proportion of legitimate mail lands in spam regardless of content. We also cover consent and unsubscribe handling, which is both a legal requirement and the thing that protects your sending reputation.

It can, but it is a weaker position and worth understanding why. On social platforms you are renting the audience: reach is set by an algorithm you do not control, the rules change, and an account can be restricted without warning, taking the audience with it. A website is the asset you own, it is measurable, and it is where search traffic can arrive without paying per visit. Social and search send people somewhere, and that somewhere should be yours. If budget is tight, a small credible site plus one channel beats a presence spread thin.

Yes. On naming, the practical criteria are that it is easy to say aloud and spell after hearing it once, distinctive enough to be searchable, and not already trading in your sector, which is worth checking properly rather than assuming. On domains, register the main extension your customers expect and the obvious close variants and misspellings if the brand matters, pointing them at the primary. Check the name is available as a domain and on the platforms you intend to use before committing, since discovering a clash after printing signage is expensive.

Multi-language work is possible, and the deciding factor is usually whether you can sustain the content rather than whether it can be built. Each additional language needs proper translation rather than machine output, which reads poorly and can damage credibility, and it needs maintaining as the original changes, or the versions drift apart. Technically the site needs correct language markup so search engines serve the right version to the right audience. Start with the language your customers actually buy in, and add others when there is content and demand to justify them.

Content goes through an approval workflow before publication, so you see it first. At the start of an engagement we document the brand guidelines, the tone expected, claims that must not be made, subjects to avoid, and who holds final sign-off, because ambiguity there is what produces a post someone has to delete. Approval is deliberately a single named person rather than a committee, since content that needs four sign-offs does not get published. For anything time-sensitive we agree in advance what may go out without a fresh approval round.

Start with what you want more of, and how you would know you had it. Useful detail includes the goal in concrete terms, who your customers are and how they currently find you, what you already run and what results it produces, roughly what you can invest monthly, and any deadline driving this. Send that to sales and you will get an initial plan separating quick wins from the slower compounding work. If your analytics do not yet show where enquiries come from, fixing that is usually the first task.

Consulting covers the decisions that are expensive to get wrong: infrastructure planning and sizing, whether and how to move to cloud, security reviews, disaster recovery design, vendor and platform selection, and technical roadmaps tied to what the business is actually trying to do. It is advisory rather than delivery, so the output is a decision you can defend, with evidence and costed options, and it is deliberately available without committing to us for the implementation. Engagements range from a short second opinion on a proposal to a full assessment of an estate.

Yes. A review looks at real performance rather than the specification you were sold: actual page load times and where they are spent, uptime history, whether backups exist and have ever been restored, the security posture including patch levels and access, and what you are paying against what you use. Overprovisioning and underprovisioning are both common, and they are not always where people expect. The output is a phased plan separating what should change now, what can wait, and what is fine as it is, with the reasoning for each.

Yes, and the answer follows the workload rather than the brochure. The relevant questions are your actual traffic pattern including peaks, what the application needs in runtime versions, extensions or background processes, how much disruption an outage causes, who will administer the server, and what you can spend. Shared hosting is right far more often than vendors suggest. A VPS earns its cost when you hit real resource limits or need control shared hosting cannot give. Dedicated hardware suits sustained heavy load or strict isolation. Buying ahead of need wastes money.

Yes. Planning covers what should move and what should not, since lifting an application unchanged into cloud often costs more than leaving it alone, target architecture and sizing, how data will be migrated and validated, the cutover approach and rollback plan, and the risks with mitigations. The cutover strategy is where most of the value sits: sequencing the move so services can be tested before traffic is switched, and so there is a way back if something is wrong. We also model running costs, which frequently differ from the initial estimate.

Yes. An audit reviews the common and consequential risk areas: outdated core software, plugins and themes, components no longer maintained, weak or reused credentials, missing or excessive administrative access, absent or untested backups, exposed configuration and backup files, missing security headers, and TLS configuration. Findings come with a severity and a remediation step rather than a raw scanner dump, since an unprioritised list of two hundred items gets ignored. Remediation can be handled by your team or ours. This is a review of configuration and exposure, not a penetration test.

We can advise on the technical controls that compliance frameworks typically require, such as access control, encryption, logging, retention, backup and recovery, and help you evidence that they are in place. What we do not do is provide legal advice or certify compliance: whether your organisation meets a given obligation is a legal determination and should come from qualified counsel or an accredited auditor. The useful division is that your advisers establish what is required, and we implement and document the technical side. Say early which framework applies.

Yes. That means implementing SPF, DKIM and DMARC correctly for your sending domains and reviewing how you actually send. Deliverability problems are usually structural rather than content-related: a missing or over-permissive SPF record, unsigned mail, a DMARC policy set to reject before legitimate senders were identified, or a third-party service sending as your domain without authorisation. We start DMARC in monitoring mode and read the reports before tightening, because tightening first is how organisations block their own invoices. Sending practice and list hygiene are reviewed alongside.

Yes. A plan defines what must survive, how much data you can afford to lose and how long you can afford to be down, since those two targets drive every other decision and cost. From there it covers backup frequency and retention, where copies live including at least one separated from production, the order in which systems are recovered, who does what, and how you communicate during an incident. The plan is only real once a restore has been tested, so testing is scheduled rather than intended, and a failed test is treated as a finding.

Yes. A roadmap sets out what to spend, when, and why, phased so the highest risk and highest return items come first rather than whatever is most visible. It separates recurring operational cost from one-off project spend, which is the distinction finance usually needs and technical plans usually blur, and it flags the deadlines that are not negotiable, such as end-of-support dates and licence renewals. The point is to replace unplanned emergency spending with something predictable. Roadmaps are normally phased across quarters and revisited as circumstances change.

Yes. Training is built around your environment rather than generic material, which is what makes it stick. Common areas are administrative basics so routine tasks stop needing an external call, security hygiene for all staff covering phishing, passwords and multi-factor authentication, and operational runbooks for the procedures that recur, such as onboarding a new employee or restoring a file. The security session is usually the highest value, because most incidents in small organisations begin with someone clicking something, and that is addressable by training in a way technology alone does not solve.

We can provide the technical side: comparing options against your actual requirements, testing vendor claims, and identifying the costs that are not in the headline figure. Those are where procurement decisions usually go wrong, particularly renewal pricing after an introductory term, per-user costs that scale badly, charges for data export or migration away, support tiers that exclude what you will need, and contract lengths with automatic renewal. Having an independent technical view materially changes negotiations. The commercial decision and the relationship remain yours; we make sure it is informed.

Yes. Those engagements have particular constraints and we work within them: formal procurement processes and documentation, reporting and audit requirements, fixed budget cycles where money must be committed within a period, and often a requirement that the resulting systems be maintainable by internal staff rather than dependent on a supplier. Nonprofits in particular benefit from a phased approach that fits grant funding. Tell us the procurement rules early, because they frequently shape what can be proposed as much as the technical requirements do.

Discovery first: we gather evidence about the current environment rather than relying on how it is described, since documentation and reality diverge, and we establish the real constraints of budget, timing, staff capability and anything that cannot change. Analysis follows, then recommendations with costed options and the trade-offs stated plainly, so you are choosing rather than being told. Implementation can be carried out by your own team using the plan, by us, or split. We are explicit about that separation, so advice stays advice rather than a route to a larger contract.

Deliverables are agreed at the start so there is no ambiguity about what you are buying. Typically they include an assessment of the current state with the evidence behind it, architecture or network diagrams where relevant, a prioritised backlog of recommendations ordered by risk and return rather than ease, a risk register naming what could go wrong and what would reduce it, and costed timeline options. Everything is written to be usable by whoever implements it, including another supplier, because a report only you can act on has limited value to the client.

Send a summary of your current setup and what is prompting the question. Useful detail includes what you run and roughly how large it is, what is going wrong or what decision is pending, any deadline and what drives it, and who internally will act on the recommendations. A scoping call follows to confirm the questions worth answering, since the presenting problem is not always the one that matters most. You then receive an engagement proposal with defined deliverables, timeline and cost before any work begins.