Summary
JPR's hosting needs are about to grow beyond a simple marketing website. With BigChange optimisation, a potential customer-facing app, and AI-led call triage on the roadmap, the infrastructure decision made now will either support or constrain what gets built next. The right approach is a three-layer architecture — each layer has a clear purpose, and James's unused office server has a genuine role to play in it.
The customer-facing website never lives on office hardware. Everything else depends on the server spec James comes back with.
The Three-Layer Model
The JPR marketing site lives on Cloudflare Pages regardless of what else happens. It is fast, free, served from Cloudflare's global network, and has no dependency on office broadband, a power supply in James's building, or any single piece of hardware. A customer searching for JPR at 11pm on a Sunday gets a live site — no exceptions.
This layer is already the plan. It does not change based on the server conversation.
As soon as JPR wants anything dynamic — a customer-facing job-status portal, BigChange API middleware, AI call-triage logic, automated certificate delivery — there needs to be a backend environment that runs continuously. This is where the decision forks.
Option A — Small VPS (e.g. Hetzner CX22): Around £4/month. 2 vCPU, 4 GB RAM, 40 GB SSD, hosted in a proper data centre with a guaranteed uptime SLA. Managed by us. No dependency on anything in James's office. This is the safe default and the right call for production customer-facing services.
Option B — James's office server: Potentially free to run (hardware already owned). Could genuinely replace the VPS — but only if the spec is capable and the office has business broadband with a static IP. If those two conditions are met, this is a legitimate production environment for Layer 2. If either is missing, it belongs in Layer 3 only.
Whatever the server spec comes back as, James's machine has an immediate useful role as the internal development and testing environment. BigChange integration sandbox, AI workflow prototyping, internal dashboards, staging builds before they go to production — none of this is customer-facing, so an occasional office outage has zero business impact.
This layer costs JPR nothing to stand up and takes pressure off any paid infrastructure while we build. It is worth doing regardless of the Layer 2 decision.
What We Need From James
James's server could save JPR the VPS cost entirely — but only if it meets the minimum bar. These are the two questions that gate everything.
- Server spec — CPU model and core count, RAM (GB), storage type (SSD or HDD) and capacity, operating system if already installed. Minimum viable for Layer 2 production: 4+ GB RAM, SSD storage, modern quad-core CPU.
- Office internet connection — is it a business broadband line? Does it have a static IP address? A dynamic IP can be worked around with dynamic DNS but adds complexity. A static IP on a business fibre line is the clean answer.
Decision Matrix — Once Spec Is Confirmed
| Server spec + connectivity | Layer 2 recommendation | Cost |
|---|---|---|
| Capable spec + business fibre + static IP | Use James's server for Layer 2. VPS not needed. | £0/month (hardware owned) |
| Capable spec + dynamic IP / consumer broadband | James's server for Layer 3 (dev/internal). Small VPS for Layer 2 production. | ~£4/month (Hetzner CX22) |
| Underpowered spec (low RAM / HDD) | James's server for Layer 3 only. VPS for Layer 2 production. | ~£4/month (Hetzner CX22) |
Longer-Term View
If JPR grows toward a genuine customer app — job booking, account portal, engineer tracking — the infrastructure will need to scale with it. A small VPS handles the early stages comfortably. If the app gains traction and load increases, moving to a managed platform (e.g. Railway, Render, or a larger Hetzner instance) is a straightforward migration. None of that is a concern now — but the architecture chosen at this stage should not close off those options. Cloudflare Pages + a Linux VPS or capable office server keeps everything open.
The BigChange ↔ Xero integration will also benefit from a persistent backend environment — a webhook receiver or scheduled sync process that runs independently of James's laptop. This is another argument for getting Layer 2 right early.