The problem
A small independent used-car dealer runs its website on a rented template platform. The business owns none of it: not the code, not the hosting, not the way its stock reaches the page.
Stock is loaded in the browser, so search engines see little of it. The site also has no room for what the business needs next: enquiries tied to a specific car, bookable viewings and test drives, proper company and legal pages and, in time, deposits and online payments. The owner is not technical. The brief was a site the business owns, still fed automatically from the stock already managed on the marketplace, that turns visitors on phones into enquiries and appointments, on a small monthly budget and within UK consumer, pricing and data-protection rules.
The approach
Planning came first. Before any code, I settled the scope and signed off the requirements, the architecture, a security plan with a threat model, a map of the UK rules the site must meet (down to a retention schedule and a subject-access procedure) and a roadmap with a risk register, with each key choice recorded as an architecture decision record. Three hosting options were costed before one was chosen.
The build runs in twelve slices, each small enough to review on its own and ordered by risk and value: a site the business owns that search engines can read, stock kept current automatically and enquiries tied to a car all come before deposits and buying online, which wait until a solicitor has reviewed the terms. Each slice will go to the owner on a private, unindexed test site with a plain-English note on what changed and what to try, and nothing is released until an explicit yes is on record.
What’s built
- Automatic stock updates: the marketplace sends a signed message for every stock change; the site checks the signature, never lets an older change overwrite a newer one, and refreshes the affected pages within seconds, while regular reconciliation repairs anything missed. Until the live feed is connected, this runs against realistic test data.
- Server-rendered pages for search: listing, make, model and car pages are rendered on the server, each with its own title, description, canonical link and structured data in the first response, plus a sitemap generated from current stock.
- Search without JavaScript: make, model, price, mileage, fuel, gearbox, body type, age and sort order in a plain form with a result count, so search works even when scripts do not load.
- All-in prices: the price shown includes any mandatory fee, and delivery is shown beside it as an optional extra.
- Sold cars handled cleanly: a sold car leaves the listing as soon as the change arrives, and its own page stops offering it for sale and drops out of search results, rather than lingering as if still for sale.
- A redirect map for the switch-over: the old site’s addresses are mapped to their new equivalents and covered by tests, ready to turn on when the domain moves, so existing links keep working.
- Security and privacy foundations: security headers on every response, configuration that refuses to start with an unsafe setting, least-privilege database roles with an append-only audit log, error reports stripped of personal data, and a build that fails if a secret could reach the browser.
- Business rules as settings: rules the owner may change are kept in validated settings with a history and an audit trail, not in code, and anything not yet confirmed is labelled as an assumption.
Key technical decisions
Render on the server, refresh on change
Stock pages are generated ahead of time and invalidated the moment a stock change lands, so the next visit gets a fresh page, with a timed rebuild as a safety net; search renders per request. Pages arrive complete for search engines, load fast on a phone and keep hosting costs low. Next.js’s newer Cache Components mode was ruled out because it cannot be combined with the per-request security policy planned for the pages that handle personal data.
Push for speed, pull for safety
Signed notifications keep pages current, but they can be missed, arrive out of order or leave fields out, so regular light and full reconciliations compare the marketplace’s stock with the database and repair any drift.
One gate in front of the main branch
Every merge must pass a single command: linting, type checks, unit tests, integration tests against a fresh Postgres database, a production build with a secret scan, end-to-end tests on desktop and mobile with automated accessibility checks, performance limits and a secret scan of the history. The code is kept in a local repository for now, so git hooks stand in for hosted branch protection: they refuse to move the main branch to anything that has not passed, whichever git command tries, and every merge triggers a verified backup.
Managed hosting without lock-in
For a one-person team running a site that will take payments, managed UK hosting and a managed Postgres database with point-in-time restore beat running a server. Background jobs run from a table in the same database rather than a vendor queue, so moving host would be a redeploy, not a rewrite.
No customer accounts
Customers will never need to sign in. Bookings and orders will use signed, single-purpose links sent by email: less personal data held, fewer passwords to protect and a simpler, more accessible experience. Only the owner’s admin area will have a login.
Every rule traced to its source
Regulations, prices and third-party behaviour in the documentation are cited with their source and the date they were read, anything unconfirmed is marked as such, and all legal wording stays in draft until a solicitor has reviewed it.
Quality & security
- Test-first: each behaviour starts as a failing test, and the suites cover pure logic, the database on real Postgres, and the main journeys end to end in a browser, on desktop and mobile.
- Accessibility: automated checks against WCAG 2.2 AA rules run on every page type at desktop and mobile sizes, with manual keyboard and screen-reader passes to follow on the test site.
- Fast pages: Lighthouse performance scores of 99–100 on the stock pages in mobile lab tests, measured with placeholder photos until real stock arrives.
- A stated security baseline: the OWASP Top 10 as the review checklist and ASVS Level 2 as the target, a threat model across ten areas, signed and replay-protected webhooks, prices always computed on the server, and no personal data in logs.
- Review before merge: each slice’s branch has had a whole-branch code review and a separate security review before merging, and I rule on every finding: fixed, test-first where it touches code, or recorded with a written reason.
- Documented interfaces only: a written evidence policy rules out scraping and undocumented interfaces, and stock work runs on test data until real credentials exist.
What’s next
- Owner review: finish the test site and monitoring, test the stock sync against the marketplace’s sandbox, and put the first slices to the owner for approval.
- Company pages, enquiries and bookings: legal and company pages, enquiry forms with bot protection and rate limits, and bookable viewings and test drives with reminders.
- Switch-over: go live on the business’s own domain, with the live listings feed connected and the old site’s links redirected.
- Deposits and buying online: holding deposits and payments through a hosted checkout, so card details never touch the site, once a solicitor has reviewed the terms and the site has had an independent penetration test.
- An admin area: passkey sign-in for the owner to manage bookings, orders and settings.
- Measures of success: the first month after the switch-over sets the baseline for enquiries tied to a car, bookings kept, time from a stock change to an updated page, car pages indexed by search engines and Core Web Vitals on mobile.
Skills demonstrated
- Next.js & React Server Components
- TypeScript
- PostgreSQL data design
- API integration & signed webhooks
- Test-driven development
- Web accessibility
- Web performance
- Application security
- Technical SEO
- UK consumer & data-protection rules
- Working with a non-technical client