Case Study: Ōtorohanga Support House Whare Āwhina

A community support website built for people, staff and local history

A community support website built for people seeking help, the team providing it, and more than three decades of local history

• Client: Ōtorohanga Support House Whare Āwhina Trust
• Location: Ōtorohanga, Waikato
• Industry: Community & Social Services
• Project: Custom Website Design & Development
• Ongoing: Website Hosting & Lite Website Management
• Built by: DNP Marketing Ltd

The Client

Ōtorohanga Support House Whare Āwhina is a community support organisation based at 120 Maniapoto Street in Ōtorohanga.

The organisation provides a central place where individuals, whānau and families can access counselling, family support, community programmes and practical assistance, while also connecting people with other services available within the community.

But Support House is more than the services listed on a website.

Its history stretches back to 1991, when people within the Ōtorohanga community began working towards creating a central place where local support organisations could operate together.

More than three decades later, that created an unusual website challenge.

We weren't simply building a new website for a community organisation.

We needed to build something that could help a person looking for support today, give the Support House team practical control over its content tomorrow, and begin preserving an important piece of Ōtorohanga's community history for the future.

The Challenge

Community and social-service websites require a different approach from conventional commercial websites.

Someone visiting a builder's website may be comparing renovation options.

Someone visiting Support House may be looking for counselling, struggling financially, trying to help a family member, dealing with housing difficulties or simply unsure where to begin.

That changed how we approached the project.

There were several requirements to solve simultaneously.

The website needed to:

• make Support House's services easy to understand
• provide clear pathways for people seeking help
• avoid overwhelming visitors with the number of services available
• feel welcoming without trivialising difficult circumstances
• allow staff to manage everyday content themselves
• publish news, community notices and newsletters
• preserve and present more than 30 years of organisational history
• retain the source material behind historical claims
• provide controlled access for different website administrators
• recognise local businesses supporting the organisation
• integrate with the organisation's existing domain and IT infrastructure
• remain technically manageable after launch

That meant this couldn't simply be a collection of attractive pages.

The underlying website architecture needed to reflect how the organisation actually operates.

Starting With the Person Looking for Help

DNP Marketing commonly uses StoryBrand principles when structuring service-business websites.

For Support House, those principles needed to be adapted.

This wasn't a situation where aggressive conversion copy, urgency or a conventional sales funnel would have been appropriate.

Instead, we kept one of StoryBrand's most useful principles:

The organisation is the guide. The visitor is the person whose problem matters.

The homepage therefore wasn't built around telling people how good Support House is.

It was built around helping someone recognise that they had reached a place where support was available.

One of the central ideas became:

Support can take many forms, from someone to talk to, to practical help when it's needed most.

Another important piece of messaging was:

You don't need to have everything figured out before reaching out. Sometimes the first step is simply starting the conversation.

That second statement solves a very particular communication problem.

A person shouldn't have to diagnose their own situation, understand the organisation's internal service structure or know which programme they need before making contact.

The website's job is to make that first step easier.

Creating a Service Hierarchy

Support House provides access to a broad range of assistance.

Trying to present every service with equal prominence on the homepage would have created another problem: choice overload.

We therefore established a hierarchy around the organisation's principal areas of support, including counselling, family support, programmes and practical assistance such as food and budgeting support.

Additional services remain accessible through the wider Services structure.

This gives someone arriving on the website a relatively simple question to answer:

“Is there help here that might be relevant to me?”

Once the answer is yes, the website can progressively provide more detail.

Services were also built as structured data

Behind the public pages, services aren't simply hard-coded blocks of website copy.

The custom administration system stores service information as structured content, including its title, URL slug, category, summary, body content, imagery, publishing state, featured state and display order.

This gives Support House the ability to evolve its service information without rebuilding the website architecture each time something changes.

It also creates predictable, descriptive URLs for individual services rather than forcing all service information onto one generic page.

Designing for Trust

For this project, visual trust was just as important as written messaging.

We wanted to avoid two extremes.

The website shouldn't feel clinical or institutional.

But it also shouldn't use overly polished lifestyle imagery that bears little relationship to the organisation someone will encounter when they arrive.

The physical Support House building therefore became part of the visual direction.

Reference photographs of the actual premises at 120 Maniapoto Street were used during the development of the website's imagery.

The goal was familiarity.

A person who has seen the website and subsequently arrives at Support House should feel that these are two representations of the same organisation.

The broader design principles became:

• Approachable, not corporate.
• Community-focused, not institutional.
• Warm, without becoming sentimental.
• Clear, rather than clever.
• Local, rather than generic.

Those decisions influenced imagery, page hierarchy, calls to action and the language used throughout the website.

A Custom CMS Built Around Support House

One of the most important technical decisions was not visible on the homepage at all.

Rather than providing Support House with a generic page editor, we built an administration environment around the types of information the organisation actually manages.

The website is a custom React and TypeScript application supported by a separate Express API and PostgreSQL database.

The administration system includes dedicated management interfaces for content such as:

• services
• programmes
• news
• community notices
• newsletters
• team members
• historical timeline entries
• historical archive material
• impact statistics
• homepage content
• Local Supporters
• website users
• contact submissions
• feedback

This distinction matters.

If a staff member wants to publish a newsletter, they shouldn't have to understand page layouts.

If they want to add a historical event, they shouldn't have to construct a timeline component.

If a new service needs to be published, they shouldn't need to edit source code.

The administration interface asks them for the information relevant to the task, while the website determines how that information should be presented.

Preserving More Than 30 Years of Community History

This became one of the most interesting parts of the project.

Support House had retained a physical historical archive containing newspaper clippings, photographs, newsletters, council material, plans and other records documenting the organisation's development.

Some of the earliest material goes back to 1991.

Rather than reducing that history to a few paragraphs on an About page, we began developing a proper digital history.

The archive documents, among other things, the early community discussions around establishing a central support centre in Ōtorohanga and the later development of expanded premises.

Material from 2000 includes records associated with the move into the premises at 120 Maniapoto Street, including building plans, construction material and records surrounding the blessing of the new whare.

But digitising history introduces another problem.

How do you make historical material accessible without losing the evidence behind it?

Keeping the Evidence

We developed a three-layer approach.

1. Preserve the original source

The original scans remain the historical master.

They aren't replaced by rewritten website copy or cleaned-up reproductions.

2. Create curated source collections

Material relating to a particular historical event can be assembled into an event-specific archival PDF.

For example, records relating to the establishment of Support House in 1991 can be grouped together while preserving the original newspaper clippings, photographs and documentation.

This allows someone interested in that event to see the evidence without searching through an entire physical archive.

3. Present the story on the website

The public timeline provides the accessible layer.

Visitors can read a concise summary, explore the fuller story, view historical imagery and access supporting documentation.

That means the website can be enjoyable for a casual visitor without stripping away the provenance required by someone researching the organisation's history.

Building Provenance Into the Database

We took the same principle into the technical architecture.

A historical timeline entry isn't limited to:

Year + Title + Description.

The underlying content model can record:

• event title
• date
• year
• historical era
• summary
• full story
• historical image
• supporting document
• source name
• source date
• source URL
• people mentioned
• location
• verification status

The separate historical archive system can also record information including:

• archive item type
• source
• people pictured
• location
• era
• rights status
• caption
• verification status

That allows the website to distinguish between telling a story and recording the evidence for that story.

It also means future administrators can continue adding historical material using the same methodology.

For an organisation with decades of community history, we considered that substantially more useful than a conventional website timeline.

Historical Verification Matters

Another deliberate choice was not pretending that every old document tells us everything we'd like to know.

An old newspaper clipping may not contain a clearly identifiable publication date.

A photograph may contain people who haven't yet been identified.

A handwritten annotation may provide useful context without being sufficient evidence to establish a fact.

The content architecture therefore includes verification fields rather than forcing every archive item to appear equally authoritative.

Where a source hasn't been established, the appropriate approach is to record that uncertainty, not fill the gap with an assumption.

That principle has guided the digitisation work as well as the website itself.

News, Community Notices and Newsletters

The website also needed to remain useful after launch.

Support House regularly communicates information that doesn't belong permanently within the site's core service pages.

The CMS therefore treats news, community notices and newsletters as their own content types.

This allows current information to be published without continually altering the site's permanent pages.

Newsletters can also be retained as part of the organisation's developing digital record rather than disappearing after their immediate purpose has passed.

Over time, this creates a useful bridge between current communication and future organisational history.

Role-Based Administration

Giving an organisation control over its website doesn't mean every user should have unrestricted control over everything.

The administration system therefore includes role-based access.

The application distinguishes between administrative, editor and viewer roles, allowing access to be controlled according to responsibility.

Authentication is handled through the application's API rather than relying on a publicly exposed editing interface.

The implementation includes:

• bcrypt password hashing
• signed JWT sessions
• HTTP-only authentication cookies
• secure production cookie settings
• login rate limiting
• account and IP-based login protection
• password-change functionality

These aren't features a visitor should ever notice.

That's the point.

They form part of the infrastructure required to give staff practical website access without treating administration security as an afterthought.

Handling Images and Documents

A content-managed website also has to account for what happens when someone uploads a 5MB photograph straight from a phone.

Admin-uploaded imagery is processed server-side using Sharp before storage.

Images are constrained to a maximum 2000 × 2000 dimensions without upscaling and converted into compressed progressive JPEG files for web delivery.

The implementation uses an image quality setting of 82, balancing visual quality against unnecessary file size.

Documents can use presigned upload URLs so files can be sent directly to object storage rather than unnecessarily travelling through the application server.

The application also distinguishes between public and authenticated asset delivery where appropriate.

This was particularly relevant to a website expected to accumulate newsletters, historical documents, photographs and other media over time.

Technical SEO Was Part of the Build

SEO wasn't treated as something to bolt onto the website after development.

The site's architecture creates distinct public routes for important content, including individual services.

Public pages use page-specific titles and meta descriptions, while individual service metadata can be derived from the service itself.

The site also provides an XML sitemap covering important public sections such as:

• services
• Our Story
• historical timeline
• archive
• news
• newsletters
• team
• Local Supporters
• contact

Crawler controls explicitly prevent /admin/ routes from being indexed while allowing the public website to be crawled.

That matters because technical SEO isn't simply about adding keywords.

It is also about making the relationship between the organisation, its services and its information understandable to search engines.

We also avoided claiming technology that wasn't implemented

As part of the project review, we audited the actual application rather than relying on assumptions about what a modern website “probably” contains.

For example, the implementation contains page-level metadata, crawl controls and sitemap support, but we haven't treated that as evidence of JSON-LD structured data where the code doesn't support that claim.

That same evidence-first approach is important to how DNP approaches SEO generally.

Local Supporters

A later addition to the website was a dedicated system for recognising local businesses and organisations supporting Support House.

Again, this wasn't implemented as a hard-coded wall of logos.

A supporter can be managed through the administration system with information such as:

• business name
• logo
• description
• category
• location
• featured status
• publishing status
• display order

Links are stored separately from the supporter record.

That allows the system to distinguish between a business homepage and individual service links, provide meaningful link labels and control their order.

The admin interface can enforce the intended limit of one homepage link and up to three relevant service links without baking four URL fields permanently into the database design.

Where the relationship constitutes commercial sponsorship, outbound links can also be identified appropriately as sponsored rather than attempting to pass a paid relationship off as an editorial backlink.

The public page closes with a deliberately low-pressure invitation:

Interested in supporting Ōtorohanga Support House?

We welcome support from local businesses and organisations that want to contribute to the wellbeing of our community.

The call to action is simply:

Talk to Us About Supporting

That leaves room for financial support, donated goods, professional services, fundraising and other forms of community involvement.

Deploying the Website Without Breaking Email

Website projects often involve systems the web developer didn't build.

Support House already had email operating through its existing domain and an established IT relationship.

That meant connecting the website wasn't simply a matter of replacing the domain's DNS configuration.

We coordinated the website DNS requirements while ensuring the records responsible for existing email remained intact.

That included treating existing MX, SPF, DKIM and DMARC configuration as infrastructure that should not be casually altered during website deployment.

It's not an exciting feature to put on a homepage.

But a website launch that accidentally stops an organisation receiving email isn't a successful launch.

Training the People Who Will Manage It

Building an administration system is only half the job.

People have to know how to use it.

DNP therefore created practical website administrator how-to videos based on the actual Support House administration environment.

Training covers the tasks administrators will perform rather than providing generic instructions about how a CMS works.

For example, adding a historical timeline event involves completing fields such as:

• Title / Event Name
• Year
• Era
• Summary
• Full Story
• Historical Image
• Supporting Document

Demonstration content is deliberately identified as fictional so training material isn't accidentally confused with genuine organisational history.

The objective is straightforward:

Support House shouldn't have to contact its web developer every time someone wants to publish routine content.

The Outcome

The finished website has been designed to work on three different timescales.

Right now

Someone looking for support can understand what Support House does, explore the help available and find a clear pathway to contact the organisation.

Over the coming years

Staff can maintain services, publish news and notices, upload newsletters, recognise community supporters and continue adding organisational history through the administration system.

Over the long term

The website can become an increasingly valuable digital record of an organisation that has been part of the Ōtorohanga community since 1991.

That was ultimately the goal.

Not simply to replace an old website.

To create a platform that could continue serving the organisation.

Hosting & Lite Website Management

DNP Marketing's involvement doesn't finish at launch.

The website continues under an ongoing hosting and lite website management arrangement.

There is an important distinction here.

We didn't deliberately make routine website changes difficult so the client would remain dependent on us.

Support House has the administration tools and training required to manage appropriate day-to-day content internally.

DNP remains responsible for the technical relationship with the website and is available for ongoing assistance, maintenance and smaller changes where required.

It creates a balance between client ownership and professional support.

The people at Support House remain in control of the information they know best.

DNP remains available to look after the technology behind it.

What the Client Said

Shortly after completing the project, Shelley from Ōtorohanga Support House left DNP Marketing the following Google review:

“Damien from DNP Marketing helped design and develop our website for the Ōtorohanga Support House Whare Āwhina Trust. From the outset, Damien was extremely helpful and brought a range of great ideas to the project. He took the time to understand our organisation's needs and worked closely with us throughout the process. His professionalism, creativity, and attention to detail resulted in a website that we are very proud of. We highly recommend Damien and DNP Marketing to anyone looking for quality website design and development services.”

Shelley, Ōtorohanga Support House Whare Āwhina Trust

I would reproduce “Damien” exactly as Shelley wrote it, despite your name being Damian. It's an authentic Google review, so silently correcting her spelling would mean it was no longer an exact quotation.

Behind the Build

• Frontend React + TypeScript
• API Express
• Database PostgreSQL + Drizzle ORM
• Content Management Purpose-built administration system
• Validation Zod
• Authentication Role-based authenticated administration
• User Roles Admin, Editor, Viewer
• Image Processing Sharp
• Media Managed object storage
• Historical Content Timeline + source-aware digital archive
• Current Content Services, programmes, news, notices and newsletters
• Community Team, impact statistics and Local Supporters
• SEO Page metadata, descriptive routes, XML sitemap and crawler controls
• Training Custom administrator how-to videos
• Ongoing DNP hosting + lite website management
• The Bigger Lesson From This Project

There is a temptation in website development to start with pages.

Homepage. About. Services. Contact.

This project reinforced why we prefer to start somewhere else:

What does the organisation actually need the website to do?

For Support House, the answer wasn't simply “generate enquiries”.

It needed to help people find support.

It needed to communicate services without making people understand the organisation's internal structure first.

It needed to give staff control without requiring them to become web developers.

It needed to preserve historical evidence rather than merely retell history.

It needed to work alongside existing IT infrastructure.

And it needed to remain useful after the day it launched.

Once those requirements were understood, the technology became a means of solving them rather than the point of the project.

That's the part of this case study I'd want a prospective DNP client to take away.

Key Outcomes

• Someone looking for support can understand what Support House does, explore the help available and find a clear pathway to contact the organisation.
• Staff can maintain services, publish news and notices, upload newsletters, recognise community supporters and continue adding organisational history through the administration system.
• The website can become an increasingly valuable digital record of an organisation that has been part of the Ōtorohanga community since 1991.