How the website business works
Everything a new team member needs: what we sell, how requests flow, how migrations run, and the rules we never break. Read this first; the detailed runbook lives in the team repo.
1 · What we do, in one paragraph
Small businesses get trapped paying heavy yearly fees for slow websites they don't even own. We move their content sites (pages, menus, galleries, forms) to fast static sites on Cloudflare — where hosting costs ₹0 — and keep them fresh under a monthly care plan. The client owns everything: their domain, their code, their hosting account. We operate inside their account as an invited administrator they can remove anytime. Every change is approved by the client on a private preview before it goes live.
2 · The three care plans (what customers buy)
| Care Basic | Care Plus ⭐ most popular | Care Pro | |
|---|---|---|---|
| Price | ₹799/mo ≈₹666/mo billed yearly | ₹1,499/mo ≈₹1,249/mo billed yearly | ₹2,999/mo ≈₹2,499/mo billed yearly |
| Edits / month | ~3 small edits | ~6 edits | ~12 edits |
| Includes | Text, price & image tweaks · client approves before live · Cloudflare hosting (₹0) | Everything in Basic + festival & offer banners that rotate by date + Instagram/Facebook embeds + priority handling | Everything in Plus + multi-page changes + monthly creative refresh + front of the queue |
| Best for | Keeping a simple site fresh | Shops that run seasonal promotions | Busier sites that change often |
Yearly = pay for 10 months (2 months free). Cancel renewal anytime — the client keeps the site.
One-time services: Trap-Escape migration ₹2,500–5,000 (move off an overpriced provider onto free hosting the client owns) · pay-as-you-go edits ₹300–500 each. Bigger jobs (a new page, a redesign) are quoted before we start — never silently billed.
3 · The honest fit check (know this cold — it's our qualifier)
✅ We migrate
- Pages, blog & articles
- Galleries, portfolios, menus
- Contact & quote forms
- Bookings-by-message (Calendly)
- Testimonials & FAQs, embeds, maps
🔴 Needs a separate project (refuse early)
- Live cart / checkout / stock
- Customer logins, members areas, LMS progress
- Real-time booking calendars with payment
- Per-visitor or live-updating content
- Forums, custom server code (CRM/webhooks)
"We can move any content site — your pages, blog, gallery, menu, contact form, and bookings-by-message. We can't move a live shopping cart, member logins, or a real-time booking calendar to the cheap static plan — those need a server running 24/7, which is a different project. Does your site have a cart, a login, or a live availability calendar? If not, you're a perfect fit."
Any "yes" in the red column = not a cheap static migration. Say it before quoting, never after.
4 · How a customer request flows
- Intake: the customer taps through the chat on hub4apps.com — what they need, their site address, where their domain is registered and where their email lives (these two answers decide every migration), timing, contact, consent.
- Ticket: the request lands in our queue with a reference number. A real person reads every one.
- Analysis: we run the intake analyzer on their site — it detects the platform (WordPress/Wix/…), runs the static-fit qualifier, and probes the domain: registrar, expiry, DNS host, email provider + bundled-email risk, plus a full DNS snapshot. Output = a written proposal for review.
- Quote & approval: fit verdict (🟢/🟡/🔴) → honest quote → client approves → work begins. No repo, no deploy, no charge before approval.
5 · How a migration runs (the runbook, condensed)
The full step-by-step process lives in the team repo (CLIENT-MIGRATION-RUNBOOK) — read it before touching client work. The shape:
The standard model
- The client owns their own Cloudflare account; we're an invited Administrator (revocable, no passwords held).
- Nothing client-owned stays on our account — zone, site and data all live in theirs. Demo copies get deleted after cutover.
- Every deploy pins the client's account ID — never rely on defaults.
The three gates (never skip)
- Preflight: exact domain confirmed with a human (typos happen) · full DNS snapshot · DNSSEC checked at the registrar · email decision made (if email is bundled with the old host, cancelling hosting kills it — decide first).
- Cloudflare write: verify you're in the client's account before every write; regenerate resource IDs in their account.
- Go-live: audit the pending zone before the nameserver flip · deploy the production build (demo noindex removed) before the flip · verify site + SSL + email records · human test email after.
Demos are built on our account, noindexed, honest content only, re-scraped fresh before every showing. At go-live the owner changes two nameserver values at their registrar (we send the exact message — templates are in the runbook). Old hosting stays paid through a ~30-day rollback window.
6 · The honesty rules (hard rules, non-negotiable)
- Never fabricate: no invented testimonials, star ratings, review counts, likes, engagement numbers, or metrics of any kind. Real customer words only, with permission.
- No promises we can't keep: no turnaround-time guarantees, no invented prices. Bigger work is quoted before it starts.
- Demos are labeled: demo gates, demo checkouts and sample content say so. Demos stay noindexed until the real domain cutover.
- Tell them before they pay, not after: if something can't migrate (cart / login / live booking), it's said up front.
- Style: no purple in client work; pastel palette (teal, amber, sage, coral, sky); no AI branding anywhere client-facing.
7 · Recent client work (anonymised here — details in the team registry)
| Client | Status |
|---|---|
| Insurance advisor, Canada | Live on his own Cloudflare — zero-downtime cutover, business email untouched, editable rate calculator |
| Dance academy, California | Approved off the demo — WordPress migration queued |
| Incense brand, Pune | Demo ready — awaiting owner answers + hosting invite |
8 · Where to go deeper
- The runbook — full migration process, owner message templates, gate checklists (team repo).
- The client registry — one row per client: domains, accounts, email risk, open items (team repo).
- Each client repo carries its own CLAUDE.md with account IDs, deploy command and do-not-touch list — read it before working on that client.
hub4apps · team orientation · keep this page current when plans, prices or process change.