Working with a client who has no technical contact

Working with a client without a technical contact means you own the technical decisions, not just the code. You translate risk into plain language, get written sign-off from whoever holds the budget, and put every credential, licence and DNS record in the client's name so nothing depends on your memory.

Key Takeaways

• Assume the client cannot review your work technically, so write down every decision in language a founder or office manager can act on.
• Build the inventory before the interview: registrar, DNS zone, hosting panel, repository, database, certificate expiry and third-party accounts.
• Every account, licence and domain belongs in the client's name with the client's billing details, even if you operate it.
• Replace verbal approval with a written change note that states what changes, what could break, and how to roll back.
• Incident triage means asking what the user saw, on which page, at what time — never asking a non-technical person to run commands.
• Expect real translation overhead. It is cheaper than the rework that follows a misunderstood requirement.
• The handover is the deliverable: runbook, credentials, renewal calendar and one named owner on the client side.

What does a client without a technical contact actually look like?

A client without a technical contact is a business where nobody on staff reads code, owns a server login, or can tell a DNS record from a hosting panel. The founder, office manager or accountant approves the work. You become the only person who can judge whether a technical decision is sound.

In practice this covers a lot of ground. It is the trekking agency running a WordPress booking site. It is a small distributor with an internal stock system one developer built years ago and never documented. It is a Kathmandu clinic with a mobile app published under an account nobody remembers creating. None of these are unusual — most businesses buy technology the way they buy accounting, and the absence of an internal engineer is not a failure of the client. It is simply the starting condition.

What changes is who you talk to. You will explain a database migration to someone whose mental model of the website is "the thing the customers see". Your job is to keep the technical truth intact while making the decision legible to them. Our team works this way on most of the builds we take on, and it shapes how we scope.

Why does a missing technical contact become production risk?

Without an internal reviewer, every technical decision has a single point of failure: you. Nobody catches a weak migration plan, and nobody notices when a domain, SSL certificate or hosting renewal quietly lapses. Risk concentrates in the gaps between what the client assumes you handle and what the engagement actually covers.

The failure modes are predictable. A certificate expires on a Sunday and the site shows a browser warning. A domain registered to a former employee's email reaches renewal and nobody can approve the payment. A plugin update breaks the checkout and the client only tells you three days later, because sales "seemed a bit quiet". Each of these is cheap to prevent and expensive to discover.

The fix is not more technology. It is a written boundary: here is what we monitor, here is what renews when, here is who approves, and here is what happens if nobody does. That document is the difference between an incident and a crisis.

When do you genuinely need a technical contact on the client side?

You need a technical counterpart when the work touches regulated data, runs revenue around the clock, or spans several vendors who must agree on interfaces. For a brochure site, a WordPress rebuild or a modest internal tool, a decisive non-technical owner is usually faster than a committee pretending to review code.

Be honest about the threshold. If the system handles payments, personal health information, or a supply chain that stops when the software stops, someone on the client side should be able to read a monitoring alert and escalate it. That person does not need to write code. They need authority and a phone number.

Where there is no such person, the practical answer is to formalise you as the escalation path, with a response expectation written into the agreement rather than assumed.

How do you run discovery when nobody on the client side knows the stack?

Discovery starts with artefacts, not interviews: domain registrar, DNS zone, hosting panel, certificate expiry, repository, database and every third-party account. Pull a live inventory before you ask a single question, because the client genuinely does not know what they own, and guessing wastes everyone's time.

1. Ask for the domain registrar login and record who the registrant contact is, not just who pays.
2. Export the DNS zone and note every record you cannot explain — old mail servers and forgotten subdomains are common.
3. Identify where the site or app is actually hosted, which is often not where the client thinks it is.
4. List every third-party account in use: analytics, payment gateway, email service, SMS gateway, CDN.
5. Check certificate expiry dates and any auto-renewal setting, then write them into a calendar you both can see.

Do this before you quote. Half the surprises on a takeover — an unmigrated mailbox, a payment gateway tied to a departed employee's account — surface in the first hour of an honest inventory.

How do you set up access and ownership so nothing depends on one person?

Put every account in the client's name with the client's billing details, then grant yourself delegated access. Create a shared password manager, enforce multi-factor authentication, and remove your own access from anything you do not need to operate. Ownership and operation are different things, and conflating them is how vendors become irreplaceable by accident.

We have been burned by the opposite arrangement more than once: a client who could not get into their own hosting account because the previous developer used a personal email. Untangling that costs days and goodwill. Our guide to client access and permissions covers the handover checklist we use, including what to do when the original owner has disappeared.

For repository access, GitHub's own documentation on managing repository access is worth reading before you invite anyone, because organisation ownership is a harder thing to move later than people expect.

How do you get sign-off when the approver can't judge the work?

Replace verbal approval with a short written change note that states what changes, what could break, who is affected and how to roll back. Send it in the client's language, not yours, and ask for a reply that says yes. An email reply is a contract; a nod on a phone call is not.

Two habits matter here. First, never present a decision without a recommendation — "we can do A or B" invites paralysis, while "we recommend A because it keeps the existing URLs working" invites a decision. Second, whenever a command or migration is destructive, say so plainly and name the backup that must exist first. Something like terraform apply against production, a data migration, or a DNS cutover all deserve a sentence explaining the blast radius and the rollback path.

How do you debug a live incident when the client can't read an error message?

Incident triage with a non-technical reporter starts with observation, not diagnosis. Ask what they saw, on which page, at roughly what time, and whether it affected one person or everyone. A screenshot and a timestamp are worth more than any description they can give you.

From there you work from the outside in, using tools that never touch client data:

# what does DNS actually resolve to right now?
dig +short example.com

# what does the web server return, and with which headers?
curl -sSI https://example.com | head -n 20

# is the certificate still valid, and when does it expire?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

These three checks rule out a surprising share of "the site is down" reports: a stale DNS record, a redirect loop, or an expired certificate. Only after that do you go into application logs. Never ask the client to run a command, and never run a destructive one — a cache flush, a database restore, a service restart — before you have told them what it changes and confirmed the backup is current.

What does this cost you in time and operational overhead?

Expect meaningfully more communication time than a project with an in-house engineer, and budget for it in the plan rather than absorbing it. You will write the same explanation twice, once in the ticket and once in plain language, and you will attend calls that exist purely to build confidence.

Set against that, the expensive alternative is rework. A misunderstood requirement discovered at launch costs far more than the meeting that would have caught it. The ongoing overhead is a renewal calendar, a monitoring alert path with a human at the end of it, and a short monthly written summary. That summary is not bureaucracy — it is how a client with no technical staff keeps a grip on what they are paying for, and it is usually the thing that keeps the relationship alive.

What mistakes do teams make with non-technical clients?

The most common mistake is answering the question that was asked instead of the one that matters. A client asks whether the site needs a redesign; the real problem is that the contact form has been silently failing for weeks. The second most common is letting credentials live in personal accounts, which turns a routine handover into an archaeology project.

• Assuming silence means approval, then discovering at invoice time that it did not.
• Sending a technical proposal the client cannot evaluate, then reading their hesitation as disinterest.
• Running an update or migration on production without a named backup and a rollback step.
• Leaving renewals on auto-pay tied to someone who has left the company.
• Never writing anything down, so the client's only record of the system is their memory of your phone calls.

If you are inheriting a setup like this rather than building one, our notes on what a web development quote should actually itemise are a useful frame for pricing the cleanup honestly.

What does this look like on a real project?

A distributor asked us to rebuild an internal ordering system built years earlier by a developer who had since emigrated. There was no technical contact. The operations manager, who was excellent at logistics and had never seen a database, was our counterpart for the whole engagement.

We started with an inventory and found the app running on a VPS in the former developer's name, backed up to a personal cloud drive, with a domain renewing on his old work email. Before a line of new code, we moved the domain, the VPS billing and the backups into the client's accounts and rotated every credential. Then we rebuilt in stages, demoing every Friday for twenty minutes and sending a written summary the same afternoon. The rebuild took longer than a straight rewrite would have, because we deliberately avoided a cutover weekend the client could not support.

Eighteen months on, the operations manager handles plugin-style updates herself, calls us for schema changes, and has the runbook on her desk. That outcome is not accidental. It is what you get when you treat the missing technical contact as a design constraint rather than an inconvenience.

How do the options compare?

There is no single right answer, and the honest comparison is about who carries the judgement. Hiring an in-house engineer gives you real review, but a small business rarely has enough technical work to keep one occupied. Retaining a contractor part-time works when the system is stable. Having your delivery partner hold the technical role works when the work is project-shaped.

Option	Who owns the technical calls	Review quality	Main cost driver	Main risk
Client hires in-house	An employee	Strong, if they stay	Salary and retention	Not enough work to keep them
Part-time contractor	A retained specialist	Good on a stable system	Retainer scope	Nobody on site day to day
Delivery partner holds it	You, in writing	Depends on your discipline	Communication overhead	Knowledge leaving with you
Client self-manages after handover	The client's named owner	Basic, with a runbook	Training time upfront	Slow response to real incidents

Most small businesses end up with a blend: a partner holding the architecture and a named non-technical owner holding the renewal calendar and the escalation phone. You can see how this plays out on our delivery work, and the common questions we get asked about running it.

In short: a client without a technical contact is not a harder project, it is a differently documented one. Build the inventory first, keep every account in their name, write decisions down in their language, and hand over something they can operate without you.

People also search for

These are the questions readers send us most often after working through this guide, each linked to the closest piece on our blog.

• Who should own the domain and hosting logins?
• What should a web development quote actually include?
• Should a small business move off shared hosting?
• What does technical debt cost a non-technical owner?
• Custom software or off-the-shelf for a small team?
• Why do contact form emails suddenly stop arriving?
• Cross-platform or native for a first mobile release?

If you are taking over a system with no technical contact on the client side, or you are the client and nobody on your team can read the code, our team can help you inventory what exists, move ownership into your name and document it properly. Talk to us about your setup and we will tell you what is risky, what to fix first, and what it takes — or start with the services we offer.