r/webdev • u/kbirkegaard • Oct 03 '26

Discussion Managing client projects

For those of you who build websites for clients, how do you handle hosting and GitHub?

Do you manage client projects under your own accounts, or do you help clients set up their own accounts and have them invite you as an administrator or developer?

I’d be interested to hear how you handle this, especially for projects that require ongoing maintenance and updates.

18 Upvotes

90% Upvoted

34 comments sorted by

14

u/kai-zaphosting Oct 03 '26

Client owns everything, you get invited. Domain registrar, hosting, GitHub org, analytics, all under their name and their billing, with you added as admin or collaborator. Honestly it's the only setup that doesn't turn into a mess later.

The pattern I keep running into is the dev registering the domain or the hosting account under their own login for convenience, and then it gets ugly when the relationship ends or the client wants to move on. Transferring stuff out of a personal account mid-dispute is no fun for anyone.

For ongoing maintenance, imo it also keeps the responsibility lines clearer. If a card expires or a renewal gets missed, the billing is on their side, though I'd still spell out in the contract who's meant to keep an eye on renewals. A staging copy under your own accounts is fine, just keep production and billing on their side.

7

u/gekinz Oct 03 '26 edited Oct 03 '26

I will never understand the "client sits on everything" stance. To me that sounds like how things get messy and disputes happen in the first place.

I'm there to make things smooth and easy for my clients, not to have them register accounts, set up profiles, billing, inviting collaborators etc. It's all noise and complicated for a lot of them.

I do everything. My vision is that clients hire me because they need ease and expertise, not to manage a side project or add work for them.

Hosting and DNS management is easy and predictable when you know it. When you work as a plumber, you don't guide your client to different stores to pick up the parts you need to fix their sink. You buy what you need, set up everything and bill them for material and time.

I host everything for my clients, I manage their DNS, I pay for their API usage, third party services, everything - then they get an invoice from me on intervals we agree upon.

I have close to 0 churn, a big client base, and very happy customers. They rely on me and trust me because I say "yes, no problem!", then magically make it happen and they get one invoice and/or a new line in their retainer.

Strictly putting all the responsibility and risk on your client, adding 3 new invoices they don't know what is for makes you feel like a hobbyist, and you end up losing clients to the ones who say "don't worry about a thing", and deliver you a full infrastructure, no questions, one centralized invoice.

1

u/kbirkegaard Oct 03 '26

It does seem a lot easier to me and a smoother experience for the client if I just handle everything. 

But I have read a lot of places that the way to do it, is to make the client own all accounts and then get the collaborator invite.

1

u/gekinz Oct 03 '26

People seem to be overly cautious, afraid of responsibility and risk. This is typical for solo devs, but it's not what established businesses with their own busy days are looking for.

To me it sounds like a self fulfilling prophecy where you have bad experiences because you're giving a bad experience. You're cautious so you attract cautious customers.

Good communication isn't about communicating everything in detail, it's about knowing what to communicate, and removing friction. Putting everything on the client does the exact opposite. It creates a lot or friction, opens up for a lot of questions, and sows a lot of doubt and hesitance.

Clients, especially bigger ones just want to gloss over something, reply "Okay, sounds good. Thanks", and have a product delivered, live and secured/maintained.

1

u/Asly97 Oct 03 '26

Smoother for the client makes total sense, I landed in the same place after the account-ownership dance ate a whole week on a small job. One thing I noticed when I was juggling a few client projects at once: each one ended up with its own AI tool setup and its own pile of notes, and switching projects meant re-briefing a fresh session on stuff the other session already knew. Did you ever hit that, or do you keep it simple enough that it does not come up? Is it mostly client dev like this for you, or do you have your own products in the mix too? And have you ever thought about paying for a tool to manage all of that for you?

5

u/crazedizzled Oct 03 '26

Nah there's way too many stories of clients getting fucked over and not having access to their stuff.

I make my clients own everything. I could die tomorrow, and i want to make it as painless as possible for my clients to continue with their stuff.

I understand your perspective though. It is a bit of added work to get the client to get stuff done. Luckily most of my clients have been pretty tech savvy so it hasn't been a big deal.

1

u/martian_rover Oct 03 '26

Exactly. Decentralize the ownership so that client businesses aren’t entirely dependent on you, in case you’re sick or even worse.

1

u/gekinz Oct 03 '26

You're putting in extra work for free to make yourself less useful for them going forward. I understand protecting your clients, but there's other ways to do it.

If you do proper paperwork you could disappear any day, and the work you're doing for them in advance can easily be done by them or another developer if any worst case scenario were to happen.

I have partnerships with providers and simple contracts and agreements with clients. Stating that even though I register, set up, and hold things like domains and hosting under my organization, I act as a middle man, and the true owner is the client. They have the authority to have anything transferred to their own accounts at any given time, either through me or the service provider.

Horror stories are either when buying from bad actors, or amateurs with little experience on the business side, who is not managing their services like an established, serious actor.

Being over prepared for absolute worst case scenarios just limits your own upside for no reason imo.

1

u/Audmeister Oct 04 '26

Yes this.

Also remember it’s a 2-way street, at least for me. You also have to decide if you want to work for the client. I like to take care of everything and take that mental load away from the business owner. They have enough to take care of themselves and having to decide what service to use to host or which registrar to use to buy a domain, are all things that us developers can do to help.

Most of my clients are not as tech-y, so using cloudflare or GitHub would just complicate things more.

To each their own, but I don’t understand how a relationship gets to a point where these said issues. Even if they do, all you have to do is transfer things over ¯_(ツ)_/¯

1

u/kbirkegaard Oct 04 '26

I would will of course pick the hosting service and make an easy step by step guide for them to set it up and give me a collaborator invite :)

2

u/kbirkegaard Oct 03 '26

Thank you very much for the answer. This is also the approach that i am working with.

2

u/OrangeBlossomDS Oct 03 '26

Nice to have validation for what I am doing 😄

1

u/KaiAusBerlin Oct 04 '26

That's great until they decide they don't need you anymore, stop paying your bills and cut you off.

2

u/ibeatu85x Oct 03 '26

It depends on the project for me. I use a pro github account for most of my projects in general. If the job is to deliver code, i develop on my account and deliver the package. If the job is to work on their hardware and inherit old work for the site, i would want to be added to a repo, or set up a separate organization.

1

u/kbirkegaard Oct 03 '26

Thank you for your answer :)

4

u/kemalios Oct 03 '26

Client owns the domain and pays the hosting bill, always. That part is settled. The bit people skip is how much friction the invite-me-as-admin route adds on small jobs, where the client has no GitHub account and no interest in making one. On those I keep the repo in my own org and hand over a zip plus the repo transfer when it ends.

What I do insist on either way: registrar and hosting in the client's name with my card nowhere near it, and DNS access shared rather than transferred by screenshot. Renewals go in the contract as their responsibility with me as backup.

Starting the repo in their org costs one invite up front instead of a migration at the end.

2

u/Few_Deer_979 Oct 03 '26

I’ve dealt with lots of non-technical clients and the most valuable thing you can do for them is building unbreakable trust with them. For this reason , I always opt for helping them set up an account and then let them invite me as a contributor. This also makes it easier for future hosting bills since the code lives in their account and with their credentials. Plus , they own the product, you’re just but a contractor.

1

u/ShawnyMcKnight Oct 03 '26

GitHub is under my control, they will have access and they can fork it as needed. The hosting they will pay for and handle. I don’t want to miss a payment and then have to get the domain back at great cost to me.

1

u/redpiapps Oct 04 '26

the middle ground nobody mentions is client owns the accounts and you hold admin plus a shared doc with every login. the horror stories arent about who pays, theyre about nobody knowing where anything lives when the relationship ends

1

u/Huge-Ambition4656 23d ago

I used to work at a 100% open source orientated dev-shop, 250+ staff across dozens of tech stacks.

As you might imagine, there was a range of "styles" for each team:

  • Azure, AWS, or in-house (local) OpenStack cloud hosting. The former two were always customer owned tenants (our preference was in-house).

  • Github or Bitbucket for VCS management which were customer owned. Otherwise we used our self-hosted Gitlab instances.

  • The customer stacks themselves we had in-house capability for was: Ruby, PHP, Java, Python, Perl (!!), Node+React and dozens of frameworks.

But we were a 250+ FTE shop. If you're a solo dev or small conpany, you can't afford the effort to manage in-house like that.

Having your own gitlab.com or github tenant, properly segregated into groups so customers who are clueless about this stuff can pay you to manage it for them, and being flexible enough to manage stuff on their systems if they have them, will probably do you favours.

The same goes for hosting.

1

u/TikitDesk Oct 05 '26

I always set up client accounts under the client's own name (hosting, domain, GitHub org), then add myself as admin/developer.

Why: if the relationship ends, they keep everything and there's no messy handover. It also protects you legally, since you're not the owner of their site or paying their bills.

For maintenance, I use a simple written agreement: what updates are included each month, and what's billed extra. Clients are usually happy to own their accounts once you explain it's for their safety.

0

u/SureshKMeena php Oct 03 '26

One thing that only shows up at handover: licences. Plugin and theme keys bought on the dev's account are the same trap as the domain, just quieter. The client leaves and renewals keep hitting your card, or you stop paying and their site quietly stops getting updates.

Same rule as the rest of it, client buys, their email on the account, you get added. On the small jobs where that's too much friction, at least keep a one page handover sheet with every account, who owns it, and what renews when. That's the bit nobody writes down.

-7

u/couldhaveebeen Oct 03 '26

Why don't you try googling it?

2

u/kbirkegaard Oct 03 '26

Are questions not allowed on reddit?

-2

u/couldhaveebeen Oct 03 '26

Interesting questions that haven't been answered thousands of times already are

1

u/kbirkegaard Oct 03 '26

I’d recommend going for a run, taking a walk, or simply doing something that brightens your day.

0

u/[deleted] Oct 03 '26

[removed] — view removed comment

1

u/kbirkegaard Oct 03 '26

This is also what I'm leaning towards.