Shipping a Car Hire Site Without GitHub Access
Shipping a client car hire site to Cloudflare without GitHub access, building a full admin panel, and logging the work in our own CRM at day's end.
Tuesday was supposed to be a quiet prep day. Instead I spent most of it shipping a client site to Cloudflare the hard way, because the phone with my GitHub two factor codes was sitting at home while I was at the office. The site went live anyway, with a full admin panel on top, and I ended the day logging the hours into our own CRM.
The CRM gap I found in my own tool
I started the morning not on client work but on our CRM. I went to edit the contact details on a lead and could not. There was no way to fix a phone number once a prospect had been promoted to a lead, and no way to push someone back down from lead to prospect if the deal cooled off.
That is a stupid gap, and it is my own fault for building a one way pipeline. Real sales is not one way. People go quiet, come back, change numbers, change decision makers. If the tool only moves forward, you end up keeping the truth in your head or in WhatsApp instead of in the system. That defeats the whole point of having a CRM.
So that got fixed first. Editable contact fields on leads, and a reverse move back to prospect. Small change, half the day's annoyance gone.
Shipping a client site to Cloudflare with no GitHub codes
The main job was a car hire and travel site for a retail client. The files were sitting locally, built but not deployed. The plan was the usual one we use for everything: GitHub repo, wired to Cloudflare, push to deploy, done.
Two things went sideways.
First, I had to stop and check whose Cloudflare account was being used. For a second I thought the work was landing in my own account, which would have been a mess to untangle later. It was not, but I made the boundary explicit: the client's domain lives in the client's Cloudflare account. Their domain, their billing, their account. Our GitHub, because the code is ours until the handover is agreed. I gave permissions for the client account setup with one condition, do not log me out of my own.
That is not paranoia. Agency work goes bad when ownership is fuzzy. If a client ever leaves, they should be able to take their domain and their hosting without me having to surgically remove my own account from the middle of it.
Second, the GitHub two factor problem. The repo push needed a code from my phone and the phone was at home. I burned maybe forty minutes on token setup, where the token goes, what to remove, before I accepted that I was solving the wrong problem. The question was not "how do I get into GitHub from here". It was "do I need GitHub to make this site live today".
The answer was no. Cloudflare will take a direct upload. So:
- Built the production files locally
- Deployed straight to Cloudflare, no repo in the middle
- Connected the client's domain in their own account
- Dropped the WordPress plan entirely, the site did not need it
- Left the GitHub wiring as a follow up for when I am home with the phone
The site was live. The GitHub connection is a convenience for future deploys, not a requirement for the first one. I had conflated the two because that is how we always do it.
Building an admin panel so the client stops calling me
A live site with no admin is a site that generates support messages. The client sells cars, stays, transfers and tours. If they cannot add a new car themselves, every single listing becomes a message to me, and I become a very expensive content editor.
So the brief grew, correctly. Admin for every content type on the site, not just cars:
- Cars, add, edit, remove, with prices
- Stays, same
- Transfers and tours, same
- The about page content
- Clients and bookings
Prices included everywhere, because a listing without an editable price is useless to them. That was the one thing I made sure of, since pricing is exactly what changes most often and exactly what they will never want to wait on me for.
Then came a stretch of me being short tempered with the process. I kept asking whether the admin was on the main domain yet, whether the change had actually applied, what the final link was. Part of that was my own fault for not writing down what had been deployed where. When you deploy manually instead of through a repo, you lose the deploy history that normally tells you what is live. I asked for the process to be saved to a document precisely because of that.
We also set up an internal email for managing clients, and I put myself on the client's admin as a superadmin. The first login attempt failed, wrong email or password. Of course it did. Nothing goes right the first time on an admin you built an hour ago.
Logging the work in money and token value
The last thing I did was ask for the day's work to be logged in our CRM, in both billable time and money value, and separately in token value, meaning what the AI assistance actually cost to produce it.
I track that second number on purpose. In Nairobi, agency pricing is under constant pressure, and the honest answer to "why does this cost what it costs" has to include what the tooling costs me. If I can build a four module admin panel in an afternoon, that is leverage, but only if I know what the leverage costs. Otherwise I am just guessing at my own margins and quoting on vibes.
The client also asked, at the end, about putting real stay listings on the site grouped under major venues and locations. That is a scope question, not a quick fix, so it stays a scope question until I have costed it properly. I did not promise anything.
What I would tell another founder
Separate the goal from the method you always use. I lost forty minutes trying to get into GitHub when GitHub was never the point, going live was. Also, keep the client's infrastructure in the client's own account from day one, even when it is slower to set up, because fuzzy ownership is a fight you have later at the worst possible moment. And log what the work cost you, in time and in tooling, on the same day you do it. You will not remember accurately next week.