Case study
A full CMS, built end to end, in one weekend.
A custom Rails CMS for West Baton Rouge Presbyterian: content models for events, galleries, and pages, a Cloudinary media pipeline, staff authentication, and an accessible public site, owned from the data layer to the last rendered page. Proof of range and speed.
Receipts
- Skills proven
-
- Data modeling
- Media pipeline integration
- Authentication
- Accessible frontend
- Full-stack ownership
- Rapid delivery
- Stack
-
- Ruby on Rails
- Cloudinary
- Quality
-
- Accessible public site
- Staff-managed content
- End-to-end ownership
- Outcomes
-
- Volunteer work
- End-to-end ownership
- Accessible public site
- Staff can self-manage content
On the docket
West Baton Rouge Presbyterian needed a site its own staff could run (publish an event, post a gallery, edit a page) without a developer in the loop. The answer wasn't a template or a plugin stack. It was a custom Rails CMS, built end to end in a single weekend: data models, media pipeline, authentication, and an accessible public site, all owned by one person, all the way down.
Step 01
One weekend, one owner
The fastest way to ship a complete product is to have one person who can hold the whole thing in their head: from the shape of the data to the focus order on the public page. This build was exactly that. No handoffs, no waiting on another team to model the schema or wire the uploads. The range is the point: back end, media, auth, and front end are not four specialties here. They're one continuous decision.
A weekend is a constraint that exposes whether someone actually owns the full stack or just a slice of it. There's no time to coordinate across roles. You model the content, you build the pipeline, you ship the site. And the only way that fits in two days is if the same person is making every call in sequence.
The constraint
A single weekend
Two days, start to finished. No room for handoffs, flags, or a second pass that never gets scheduled.
The proof
End-to-end range
Data models, media pipeline, authentication, and an accessible public site, owned by one engineer, top to bottom.
Step 02
From data models to a media pipeline
A CMS is only as good as the content models underneath it. This one is built on Rails, with first-class models for the things the church actually publishes: events, galleries, and pages. Get those right and the editing experience falls out of them naturally: staff manage real concepts, not rows in a generic table.
Images are their own problem, so they get their own solution. A Cloudinary media pipeline handles uploads, storage, and delivery, so the galleries stay fast and the staff never have to think about resizing or hosting. Authentication gates the editing surface: staff sign in to manage content, and the public never touches the admin.
Owned end to end
- Content models: events, galleries, pages
- Cloudinary media pipeline
- Staff authentication
- Accessible public site
Range isn't a list of technologies. It's being able to own every layer at once and still ship something finished.
Step 03
An accessible site the staff can run
Speed is only worth bragging about if what you shipped is actually good. The public site was built to be accessible, not just functional: the finish that decides whether a product works for everyone or only for the average visitor on a fast connection. That standard held even under a weekend deadline, because it was part of how the site was built rather than a pass bolted on at the end.
The other half of "finished" is who can run it afterward. Because the content models map to the things staff actually publish, and because authentication keeps the editing surface theirs, the church can self-manage its own content. The handoff isn't a pile of instructions. It's a working tool the people who own it can keep using.
Accessible by build
The public site works for everyone, because accessibility was part of the build rather than a later remediation pass.
Self-managed content
Staff sign in and publish events, galleries, and pages on their own. No developer required in the loop.
Shipped, then theirs
Delivered in a weekend and left in the hands of the people who run it, finished rather than half-done.
Product engineering
I build complete products, end to end.
A full CMS in a weekend is the same skill at a different scale: own the whole thing, ship it finished, leave it accessible. If that's the work, let's talk.