Client work
A parish website
built to be used.
We designed and built a new website for Paroisse Saint-René-Goupil in Montréal, bringing the parish’s schedules, events, services and community information into one place that is clear for visitors and straightforward for the people who keep it up to date.
- Client
- Paroisse Saint-René-Goupil
- Location
- Montréal, Québec
- Role
- Design and development
The need
A website that still works
a year from now.
A parish website is not one audience. It is a handful of people arriving with quite different questions, most of whom will decide within a few seconds whether this site is going to answer them.
And almost everything they came for changes. Mass times shift around special celebrations, events come and go, photographs are replaced, announcements are added. A site that only looks right on launch day would have been the wrong thing to build.
- Someone checking a Mass timeWants a schedule they can trust before getting in the car.
- Someone looking for an upcoming eventWants to know what is happening in the parish and when.
- Someone visiting for the first timeWants to know what to expect before walking in.
- Someone who needs to reach the officeWants contact details and the hours the secretariat is open.
- Someone exploring parish lifeWants to see the services, the community and the thrift shop.
From information to a site
Everything the parish does,
in one place.
Before any page was designed, the practical content had to be sorted into sections that match how someone actually looks for it — separating what a first-time visitor needs from what a regular parishioner needs, and giving schedules and events room of their own rather than burying them in a general information page.
That became a home page with what is coming up next, then schedules, events, the parish’s own history, a first-visit guide, parish life and services, the Au Coin de l’Entraide thrift shop, and contact — each with enough room to be read properly rather than squeezed into a sidebar.
Two of those sections carry most of the weight. Schedules is the page people check before leaving the house, so it has to look current and say when it last was. Events needs room to breathe as things are added and then pass.
After delivery
The parish does not need us
to change a date.
This was the requirement that shaped the most decisions. A parish office should not have to email a developer because a Mass time moved or a new event was announced, and it should not have to learn a technical tool to avoid that.
So the site’s text, images and events live in a content system the parish can open on its own. Editing works the way you would hope: you look at the page, click the thing you want to change, change it, and publish.
- 01
Open the page
The editor shows the site as visitors see it, not a wall of fields.
- 02
Click the text
Selecting something on the page opens the exact field behind it.
- 03
Publish
The change goes live on its own. Nobody has to run anything.
Drafts can be reviewed on a private copy of the site before anything is published, so a change can be checked in place rather than guessed at. Underneath, the content is structured — an event always has a date, a schedule always has its times — which is what stops the site drifting out of shape as people add to it over the years.
How it was built
Choices made for
this kind of site.
Each technology was chosen for the same practical reason: it suited a content-heavy community site that a small team needs to keep current.
The design follows the same logic. It is warm and considered, with real photography of the church and a typographic style that suits a parish rather than a software company. Every section shares one set of type, spacing and colour, which is what lets a site this size still feel like a single place.
Astro
A content-first framework
The site is mostly words and pictures, so it is built to load as finished pages rather than as an application the visitor has to wait for. Interactive pieces are added only where they earn it.
Sanity
The content system
Text, images, events and page content live somewhere the parish can reach without touching code. It is structured, so an event is always an event and nothing depends on remembering how a page was laid out.
TypeScript
Typed code
Required content is checked while the site is being built, so problems such as a missing date are caught before they appear on the live site.
Tailwind CSS
The design system
One consistent set of type, spacing and colour across every page, which is what keeps a site with this many sections feeling like one place.
Cloudflare Pages
Hosting and publishing
Publishing a change rebuilds and deploys the site on its own. Nobody has to run anything by hand for an update to appear.
Working with the parish
The first version
is never the last.
Plenty of what the site needed only became clear once there was something real to react to. Photographs were swapped for better ones. Wording was refined by the people who actually know the parish. Some sections turned out to matter more than we had assumed and moved up; others were simpler than planned. The editing experience was adjusted once we saw how it would really be used.
Requirements becoming clearer is a normal part of working with an organisation. Because the content had been organized before the pages were built, the site could absorb those changes without turning each one into a rebuild.
Delivered
Live, and
in the parish’s hands.
The site is online. Schedules, events, parish life, the thrift shop and contact information all sit in one coherent experience that works on a phone as well as a desktop, and the parish can keep it current without calling anyone.
What the project took
A project like this is not really about the number of technologies involved. It is about ending up with something shaped around how the organisation actually communicates — and leaving it in a state where they can carry on without us.
Design
A visual language that suits a parish — warm and considered, not corporate.
Frontend development
Twelve or so page types that stay coherent and work on a phone.
Content architecture
Deciding what counts as an event, a service or a schedule before building the pages.
CMS integration
Connecting those structures to an editor the parish can actually use.
Deployment
A publishing path that runs without anyone at a terminal.
Working with a client
Adjusting the system as the real needs became clearer.
If your organisation has outgrown the way its website works,
start with the problem.
You do not need to arrive knowing what should replace it. Tell us what is getting in the way and we will work out the rest together.