Bayside ChurchWebsite Redesign
We're rebuilding our main website and looking for an exceptional design partner. We're looking for an established agency that is exceptionally strong in design to rebuild our main site — across a growing, multi-campus church — on a flexible, easy-to-manage platform.
One church, many campuses.
Weekend attendance
Campuses today (incl. Folsom Prison) — 3 more by 2027
California regions
Bayside has been around since the late 1990s, and today we're one church meeting across ten campuses — nine public locations plus Folsom Prison, a special campus that isn't treated like a normal location. Our campuses span three California regions — the Sacramento area, the Bay Area, and Southern California — and we're still growing, with three more planned by the end of 2027.
We're not a broadcast church. Each campus has its own campus pastor who preaches their own message every weekend — there are no video venues replaying one central service. Each campus also runs and publishes its own weekend services and livestreams, on the shared infrastructure our central team provides.
Shared Operations
Our central team — they provide the shared infrastructure every campus runs on, and they're your primary partner throughout this project.
Campus pastors weigh in on design, and our executive pastor holds final approval on budget and design.
A complete redesign, led by design.
We're completely redesigning our main website. We want a partner who is exceptionally strong in design and can deliver a clean, well-branded site that isn't overly cluttered — and that's easy to manage. Historically our brand is clean and simple, photo- and video-driven, with room to breathe. We're open on the platform — a modern JS framework with a CMS, WordPress, Rock, or something else — and want your recommendation.
The site's first job is to welcome new people. If sermons, events, and ministries are genuinely easy for someone exploring Bayside to find, our regulars will find them too — so we design for the newcomer first.
We're a growing, multi-campus church, so a strong approach to multi-campus is essential. A core goal is design alignment across our domains and platforms — most importantly bringing Rock in line with the new site, on whichever platform we land on. BEMA, our Rock support partner, helps on the Rock side.
Prior church experience isn't required, but a strong portfolio is essential. We're looking for an established firm — no solo freelancers.
- Design
- Clean, well-branded, uncluttered
- Audience
- New people first
- Platform
- Open to suggestions
- Campuses
- 10 today · +3 by 2027
- Partner
- Established agency
- Budget
- Flexible — let's talk
Four problems to solve.
At its core, this project comes down to four things.
A design that's over a decade old
The original site was built in 2012, with small revisions in 2020 — and no meaningful design update since.
A growing multi-campus footprint
10 campuses today and 3 more by the end of 2027, each currently its own microsite. We need a strong, scalable approach to multi-campus.
A backend that's hard to maintain
The WordPress site carries legacy plugins that need better management or updating, and the Multisite network adds challenges of its own.
The role of Rock
Some pages belong in Rock (forms, etc.), some don't — and Rock could even be the platform. We'll map the overlap and unify the design.
What we're working with today.
Today it's a main hub plus a templated microsite per campus, on WordPress Multisite. That works, but the multisite model brings its own logistical challenges — and we're not sure it's the right long-term approach. We're open to keeping multisite, moving to a more traditional single site, or something else.
This is our current structure — the starting point, not the target. We're open on where the platform goes next. (What connects to it is in the next section.)
- Platform
- WordPress Multisite — a main hub plus one templated microsite per campus. Every campus site shares a single theme.
- Templated campuses
- Campus sites share a common template — each has a hero image and generally the same homepage content, though campuses have some flexibility in which content rows they add.
- Domain
- On baysideonline.com today; we own bayside.church and are looking at moving to it — so plan for the domain change, redirects, and SEO.
- Content ownership
- Each campus has one or more people responsible for keeping their location's content up to date.
- Governance
- We want most pages centralized and NOT campus-editable, with the flexibility to spin up one-off pages.
- Video (Mux) Keeping
- Sermon and devotional video is hosted on Mux. We want to keep Mux as our video platform in the new site.
Each campus has its own set of pages — mostly ministry pages duplicated across locations (e.g. granitebay.baysideonline.com/kids vs blueoaks.baysideonline.com/kids). Upkeep is uneven: some ministries keep their content fresh, others let it sit for years. Many pages are outdated or poorly designed, and page-building is highly democratized — something we may want to rein in.
Roughly 90% of pages (everything but the homepages) use a single “Custom Layout” template: staff assemble a page from structured ACF sections — Traditional Content, Custom Rows, Events, People, Connect/Contact — rather than free-form. It gives some structure, but it's also what lets pages multiply and drift.
An open question for the redesign: do we even need a separate ministry page per campus? We may just need to surface each campus ministry's essentials simply — without a full page each.
The site doesn't stand alone.
A web of platforms and feeds depends on our content. Changing the CMS means re-pointing these — so the new partner needs to account for them. The chips below flag what we keep, what must be preserved, and what's still an open decision.
Livestream playback
We stream to YouTube, and each campus also streams at <campus>live.baysideonline.com on Sardius — essentially a calendar that plays a Resi feed. We use a sliver of the platform and may not renew it. Three paths for the new site:
- Bring livestream playback into the new site,
- Give us design direction to build a similar solution ourselves, or
- Keep Sardius, but provide design direction to bring it on-brand.
WordPress
Content sourceSermons, devotionals, and (today) event listings live here as post types — on a steady rhythm: a 3–5 minute devotional posts to the main site five days a week, and each campus posts its own weekend sermon (35–60 minutes) once a week.
Rock RMS
IntegrationEvents are the integration priority — pulled live via Rock's API, with other data available as needed. BEMA supports the Rock side.
Mux + bcc-mux plugin
Keep · plugin needs a planMux hosts all sermon and devotional video — we want to keep it. A custom WordPress plugin (bcc-mux) is how we manage and consume Mux assets: an ACF field type, an admin asset browser, and REST + webhook endpoints. It's essential, but it isn't currently maintained by any developer — the plugin needs a plan for updates and support. We're open to ideas or solutions.
Daily email — Mailchimp
Open decisionAn RSS feed from the Devotionals post type triggers a Mailchimp email — a daily devotional, 5 days a week. Mailchimp is the last thing we use it for, so we'd also consider having Rock send this email instead — though Rock may still need an RSS feed or API route to ingest the devotionals.
Podcasts — Apple & Spotify
Must preserveEach campus' sermons publish an RSS feed that feeds Apple and Spotify podcasts every week.
Subsplash — legacy video archive
Migration TBDWe moved sermon video to Mux in 2022, so only the last few years live on Mux today. Roughly 8 earlier years of sermon content are still on Subsplash — which we're still paying to host. If a viable migration path exists, we'd love to bring that older library over.
Bayside App — Differential
Under reviewThe mobile app pulls from Rock (accounts, soon events), WordPress (sermons, devotionals, events today), and Sardius (livestream calendar). We may discontinue it; if not, Differential migrates their connectors to new endpoints when the CMS changes.
We keep building around the main site.
Because the main site's design is so dated, we've gotten into the habit of building around it — one-off sites when something needs to look good, and a scattering of link-in-bio pages when a campus, ministry, or event needs something quick to share and easy to update. We'd rather not. A few examples of each:
The NXT Initiative
Built on FramerOur NXT capital-campaign site — built off the main site, on Framer, to get a modern look.
thenxtinitiative.com ↗
Folsom Prison
Built on RockA one-off campus page built directly in Rock.
connect.baysideonline.com/folsom-prison ↗The same instinct shows up at the ministry and event level. When a campus, ministry, or one-off event needs something quick to share — a link in an Instagram bio, or the page behind a text AUBURN to 56316 keyword — people reach for a link-in-bio tool instead of the main site. They're now scattered across at least three platforms — solo.to, Linktree, Flowpage — two of them paid, with no central ownership or analytics.
They're a mix: legitimate social-bio links, ministries quietly using one as an easier-to-update website, and short-lived seasonal or event pages (Easter, Trunk or Treat, camp sign-ups). The branding is all over the map, the naming is inconsistent (baysidestudent and baysidestudents both exist), and every page is hand-maintained.
Bayside Church
Bayside Auburn
Bayside Students
Thrive Women
Auburn Easter
Trunk or Treat
A representative few — dozens more exist across campuses, ministries, and one-off events.
- One home, not three
- At a minimum these need some guidance and a single, affordable, scalable home instead of three platforms — two of which carry a cost. Which platform or pattern would you standardize on?
- Why the event ones exist
- Some are genuine needs — a QR page for Easter or Trunk-or-Treat promoted from the stage. Others are really a ministry wanting an easier-to-update website. We'd want help telling these apart and giving each a proper home.
- How many survive a mobile-first site
- If the new site is genuinely mobile-friendly and easy to edit, how many of these go away on their own?
- Build it, or keep buying it
- We could build a lightweight link-page pattern on the new platform — on our own domain, pulling live info from Rock and WordPress — or keep using an external service. We're open, and want your recommendation.
- Stale by design
- Today these are hand-kept copies of service times, events, and links that already live in Rock and WordPress, so they drift out of date. A version built on our own platform could pull straight from the source instead — one of the upsides worth weighing against an external tool.
Our ~20 student ministries — a high-school and a middle-school ministry at each campus — design their own seasonal calendars as PDFs (here's Blue Oaks Middle School's spring). It's one easy place to drop a whole season of events, with full control over the layout — and you'll usually find them linked from one of the link-in-bio pages above.
They're a workaround for two things at once: design control, and speed — posting a season without filing an event request for each item and waiting on approval. Some events are approved; many are just the normal weekly rhythm (a Wednesday midweek) that wouldn't really need it, except that submitting a request would trigger approval anyway. The catch: those same events often never make it onto the website, so a parent or a new student checking the site can't find them.
No solution yet — and maybe that's fine. The question is whether we leave the PDF pseudo-schedule alone or plan for it. One possibility is a simple ministry schedule builder that turns a single entry into both a shareable layout and real events on the website. Worth working through, or worth ignoring.
Public Rock pages that need theme direction.
Some areas live in Rock RMS — because they're interactive for a logged-in account, or because they pull data from one. The pages below are a representative sample, not the full list: others already exist, and more will be added on an ongoing basis. Aligning all of them with the new design (on whichever platform we land on) is a core goal, so everything feels like one church. Rock work is supported by BEMA.
Member accounts
RockCongregants log into their accounts here to manage their profile, giving, groups, and events. This member experience needs theme direction too.
my.baysideonline.com ↗
Local Outreach
RockLives in Rock because it's interactive for a logged-in account.
connect.baysideonline.com/local-outreach ↗
Giving
RockOur giving provider is Simple, but the giving page will likely live in Rock so it can personalize for the logged-in user — pre-filling their info when they're signed in.
connect.baysideonline.com/giving ↗What we'll need, against the four problems.
The work maps to the four problems above — design, multi-campus, the backend & platform, and the role of Rock — with the rest of the ecosystem folded in.
Design
- A modern, polished redesign of the main site — design quality is the top priority.
- One consistent design across our domains and platforms (including Rock), so everything feels like one church.
Multi-campus
- A strong, scalable approach for a growing multi-campus church (+3 campuses by 2027).
- We're open on the model — keep the multisite approach, move to a more traditional single site, or something else — and want your recommendation.
- Rethink the per-campus ministry pages: we may not need a full page per campus, just a simpler way to surface each campus ministry's info — and we may want to rein in who can build pages.
Backend & platform
- Recommend the right platform — we're open (a modern JS framework with a CMS, WordPress, Rock…) and want your recommendation.
- Livestream playback in the new site, or design direction to build our own or to bring to Sardius.
- Keep the daily devotional email working (Mailchimp today, or have Rock send it) and preserve the podcast feeds (Apple/Spotify) and the Bayside App's data endpoints.
- We own the repo, with access to a CI/CD pipeline.
The role of Rock
- Map the overlap — which pages live in Rock today, which could move there, and which shouldn't (anything with forms or registration generally needs to be in Rock).
- Rock integration: pull live event data via Rock's API (the feed already includes links to registrations), with other data as needed. BEMA supports the Rock side.
- Events are mid-move: today they live in The Events Calendar (WordPress) plugin, but we're moving both the data and the listings front end to Rock. The data will stay in Rock; the listings may come back to the new platform if that makes sense.
- One unified design across the public site and Rock, so a logged-in Rock page feels like the same church as the marketing site.
The new site must be agent-ready.
A firm requirement for this build: the new site implements WebMCP, so AI agents can act on it through typed tools instead of guessing at the page. It's an emerging open standard — here's the short version for the team.
WebMCP (Web Model Context Protocol) is a proposed open web standard — developed by Google's Chrome team with Microsoft's Edge, incubated in the W3C Web Machine Learning Community Group, and announced at Google I/O 2026. It lets a website expose structured tools — annotated HTML forms and JavaScript functions — directly to browser-based AI agents through a navigator.modelContext API. The agent calls a typed, documented tool, the way it would a real API, instead of interpreting pixels or the DOM and guessing where to click.
For Bayside, that means the things people actually ask an assistant to do — find a campus and its service times, look up or register for an event, find a sermon, start giving — should be first-class WebMCP tools on the new site, working reliably within the user's own signed-in session.
Expose our core actions as tools
Find a campus and service times, browse and register for events, locate sermons and devotionals, start giving — each surfaced as a named WebMCP tool with a clear description and schema, not left for an agent to scrape.
Use both APIs where each fits
Declarative HTML attributes on existing forms for the simple cases; the imperative navigator.modelContext API for dynamic, multi-step flows.
Respect the signed-in session
Tools run inside the user's existing browser session, so anything gated to a logged-in Rock account works without a separate login. Plan this alongside BEMA on the Rock side.
Treat it as progressive enhancement
WebMCP is still early — an origin trial in Chrome, with Firefox and Safari following. Build it so it enhances capable browsers and changes nothing for everyone else.
How we expect the project to flow.
The phases we anticipate — we're open to your proposed plan and sequencing.
August 1, 2026
Signed contract & ideal start date — flexible.
Mid-2027
At the latest.
We're looking for a partner with strong design opinions, leadership, and project management. Our team will be running other projects at the same time, so we'll be leaning on you to keep things moving.
- 01
Discovery & Strategy
Stakeholder interviews, audit of the current sites, goals, sitemap, and content strategy.
- 02
Design
Brand-aligned visual direction, key page designs, and a reusable, multi-campus component system.
- 03
CMS Build
Build the public site on a flexible, easy-to-manage CMS with editor-friendly content models.
- 04
Rock Integration
In partnership with BEMA, pull live data from Rock RMS via its API (events first) and apply the design to Rock pages.
- 05
Launch
QA, accessibility + performance pass, content migration, redirects, and go-live.
How we want to work — now and ongoing.
We're open to a long-term relationship, but it starts from clear ownership: this is our code, and we need to be able to change it.
- We own our code outright, with the ability to make changes.
- The code lives in our GitHub repo and is hosted by our provider.
- A proper CI/CD pipeline, so changes ship safely.
- Campuses
- Make their own allowed content changes for their location.
- Comms director
- Make changes that affect all campuses at once — typically content, not code.
- Digital / Rock team
- Modify the code directly, through a proper CI pipeline.
If budget allows, we'd love an ongoing partner who co-owns the code with us — maintaining the code, plugins, and integrations, and making code changes as needed. We'd also bring you larger one-off projects (Christmas, Easter, kids camps, or future builds like the NXT capital-campaign site). In short, we'd love for you to be our main web partner.
Other Bayside-run sites — not in scope.
A few other sites in the Bayside family, here for context only. They're not part of this project, but there may be future opportunities — we'd love a partner we can grow with.
Thrive Conference
Out of scopeOur leadership conference — world-class resources to equip church and ministry leaders.
thriveconference.org ↗
Thrive Podcast Network
Out of scopeA network of shows for leaders — conversations that equip, inspire, and transform impact.
thrivepodcastnetwork.com ↗
Adventure Christian School
Out of scopeOur Roseville Christian school (preschool–12), affiliated with Bayside.
adventurechristianschool.org ↗
Bayside Counseling Center
Out of scopeProfessional counseling — individual, couples, family, and more — based in Roseville, CA.
counseling.baysideonline.com ↗
Thrive Worship
Out of scopeBayside's worship music ministry — original Christian worship written and recorded across our campuses.
thriveworship.band ↗
Thrive College
Out of scopeA 9-month discipleship program blending faith, academics, and internships to prepare students for their calling.
mythrivecollege.com ↗
Breakaway Kids Camps
Out of scopeOur high-energy summer day camps for kids (ages 5 through 6th grade) — art, water, sports, and Bible, run across several California locations.
breakawaykidscamps.com ↗Think you might be a fit? Say hello.
No formal proposal needed — we'd just love to hear from you and start a conversation with the right partner.
Send a quick note with a link to your work, and we'll take it from there. If it feels like a fit, we'll find time to dig into scope, timeline, and pricing together.