Rebuilding a 33-page Website on Realm/ACS Technologies
Full implementation lifecycle — discovery through staff handoff — delivered against a fixed launch date with a mid-project scope increase absorbed without a timeline change.
Situation
Plymouth Congregational Church had licensed Realm/ACS Technologies — a member management platform with an integrated website module — but the web presence had never been built out to match what the platform could support.
The existing site was an externally built and externally hosted legacy site with no connection to the member database. Member records, giving history, and group rosters lived in Realm. Visitor and prospect communication lived in a separate, never-integrated instance of a third-party marketing platform. The public site lived with an outside vendor. Three systems, three sources of truth, and manual re-entry between them.
The organization needed a full public-facing site: program information, staff directory, event calendars, giving pathways, and member-facing resources — all running natively on Realm so that content, member data, and communications drew from one record rather than three.
Constraints
Realm's website module has a defined content model and a set of integration points that assume a particular relationship between page content and the underlying member database. Events, registrations, giving, and directory content are not authored on the site; they are fed from Realm, which means page structure has to be designed around who maintains the source record, not around what looks good in a wireframe.
I chose not to use the stock templates. A templated build would have shipped faster, but it would have forced Plymouth’s content into a structure that didn't match how the organization actually works — and would have left staff maintaining a site that fought them every time they needed to update it.
So the build was custom: 34 pages, structured around the organization's actual programs and member journeys rather than the platform's default assumptions.
Approach
Discovery and content architecture.
Before building anything, I mapped [NUMBER] existing content sources — the legacy site inventory, the annual report, board and committee rosters, governing bylaws, ministry-area program documents, and front-desk intake logs of what people actually call to ask — along with the staff workflow attached to each. The goal was to understand not just what content existed, but who maintained it and how often, because that determines what the site structure has to support after launch.
That discovery produced a written Site Philosophy and Editorial Standards document, signed off before the first page was built. It established the load-bearing rule the whole architecture rests on: the public site serves people who don't know the organization yet; member-facing depth — rosters, registrations, governance materials, meeting minutes — routes to the authenticated member platform. Every later scope dispute resolved against that document rather than against me.
Dependency documentation.
Content approval from each program director for their own ministry pages
A second review layer from the governing board and committee chairs for their areas
Member database cleanup and roster verification, owned by the data lead
LAYER ONE
Editorial standards and content architecture, signed before production began
LAYER TWO
Custom template and section layer, plus a brand system built for the site — including a custom iconography set produced through a scripted SVG/PNG pipeline with numerical verification of centering, artboard fill, and accent-color ratio, so 30+ icons were provably consistent rather than eyeballed
The dependency documentation already established what the original timeline assumed, so the new work could be scoped against a written baseline rather than a remembered one. The custom template layer was built to be extended. Adding pages meant adding content, not rebuilding structure.
Domain cutover, SSL, and redirect mapping from the legacy hosting vendor
Vendor relationship transfer, owned by operations
Sign-off on the Editorial Standards document itself
Each was logged with a named owner and a date needed. This is what made the scope change survivable—when new requirements arrived, there was already a written record of what the original timeline was built on..
Build. Sequenced in four layers:
LAYER THREE
Page-by-page content production against the standards, with every unverifiable claim flagged for human resolution rather than resolved silently
LAYER FOUR
Integrations, then QA across desktop, tablet, and mobile — mobile weighted first, since most first-time visitors arrive on a phone
Platform integration
What talks to what
Event calendars→ dual feeds from the member database: a public events feed and a member events feed, plus ministry-filtered feeds rendering on interior program pages. An event's public/member designation is set once at entry by the program staff member who owns it, and that single field determines whether it publishes to the open internet.
Event registration → handled in the platform, with capacity, deadlines, and confirmation flows; registration lists stay in-system rather than being exported for follow-up.
Giving → native platform giving, reachable from both the public site and the member app, with fund posting handled downstream in platform accounting.
Staff directory and contact forms → driven from platform records so a staffing change updates in one place.
Member app → the authenticated destination for everything the public site deliberately doesn't carry. The public site and member app are designed as complements, not duplicates.
Sermon video → external video platform embed, selected after evaluating three options on responsive rendering, existing audience, and vendor stability.
Scope change
I absorbed it without moving the delivery date. That was possible because of three things:
A published content freeze with named owners and written deadlines. Late inputs did not move the date. Contributors received their deadline in writing, with operations copied; where content didn't arrive, the page shipped with what existed, and the request record showed what had been asked for and when.
The schedule was protected by documentation, not by heroics. Scope growth on an implementation is normal. What matters is whether it's governed — whether the change is documented, priced in time, and agreed to, or whether it silently eats the schedule. This one was governed.
Outcome
34 pages delivered, custom-built rather than templated
Content complete ahead of the published freeze date, with the scope increase absorbed
Architecture designed to consolidate three parallel systems — legacy vendor site, standalone marketing database, member platform — into one integrated stack
What this project demonstrates
Implementation work is a distinct discipline from marketing execution. It requires reading a platform's actual constraints rather than its marketing copy, designing within them, documenting dependencies before they become disputes, and building toward a handoff rather than toward a launch.
This project was a full lifecycle: platform assessment, content architecture, custom build, integration, scope governance, training, and documentation. I'd do the same work on Salesforce, HubSpot, or any martech stack where the implementation is load-bearing rather than an afterthought.