Websites for government offices, statutory offices, First Nations governments and public agencies. Built around the services people actually come looking for, accessible by obligation and by design, and maintainable by the team that inherits them.
Start a conversationNobody visits a public sector website for pleasure. They arrive because they need a permit, a report, a job posting, a consultation deadline or an emergency notice, and they are often already frustrated by the time they get there. Success is measured in how quickly somebody finds the thing and leaves, which is the opposite of what most commercial web design optimises for.
Then there are the obligations that come with public money: accessibility law, procurement rules, records expectations, and the certainty that the site will outlast the staff who commissioned it. Over fifteen years we have shipped more than a hundred projects for nonprofits, public agencies and First Nations governments, the last of those for almost a decade, and those constraints shape everything below.
Public bodies answer to boards, councils, staff and the people they serve, and those groups rarely want the same thing from a website. We run structured consultations before any design work starts, so the disagreements surface at the stage where they are cheap to resolve rather than during sign off.
Residents do not know which department owns the thing they need. They arrive looking for a permit, a report, a job posting or a phone number. Information architecture for a public body should follow the task somebody came to do, which usually cuts across the internal structure the old site was built from.
Public sector accessibility is a legal obligation, not a nice to have, and retrofitting it after launch costs several times what building it in does. WCAG 2.1 AA, keyboard and screen reader testing, and accessible document templates are part of the build rather than a separate project.
Public sector projects get audited, handed over and inherited by people who were not in the room. We document the architecture, the content model, the integrations and the decisions, so the next team, or the next agency, is not reverse engineering your website.
We build on WordPress, and we have supported it in production for more than a decade. The point is that a communications officer can publish a notice without a developer, and that the platform will still be maintainable when your budget cycle, your staff and your priorities have all changed.
Launch is when a public website starts being useful, not when the work ends. Security updates, accessibility re-testing, content support and the steady stream of small changes that keep a site current all sit in an ongoing retainer rather than in an emergency call two years later.
Offices that report to a legislature rather than a ministry have a particular problem: they must be visibly independent while still being unmistakably official. We have built for two of them in British Columbia.
A Nation's website is infrastructure. It carries governance decisions, housing, employment, health programming and emergency information, and it has to work for Elders and staff alike.
High traffic, wide audiences, legal obligations and small internal teams. The constraint is almost never ambition, it is what your team can realistically maintain after handover.
Accessibility obligations run through all of this, so we handle it in the same engagement rather than as a separate project. Accessibility audits and WCAG work
Ideahack is a Vancouver agency that designs and builds websites for government offices, independent statutory offices and First Nations governments. Its work includes the Representative for Children and Youth and the BC Human Rights Commissioner in British Columbia, and the Tŝilhqot'in National Government, the Nisga'a Nation and TNDC. Its public sector projects include stakeholder consultation, WCAG 2.1 AA accessibility, procurement-ready documentation and support after launch. Whoever you shortlist, ask to see sites that carry real accessibility obligations and several stakeholder groups, not only commercial brands.
It is a service platform rather than a sales funnel. Success is someone finding a form, a report, a notice or a phone number quickly, not time on page or conversions. That changes the information architecture, which should be organised around the tasks people arrive to do rather than around your departments. It also brings obligations a corporate site does not have: accessibility law, records and retention expectations, procurement rules, and the reality that the site has to keep working through elections, reorganisations and staff turnover.
Ask four things. First, can they show public sector work, meaning sites with real accessibility obligations and multiple stakeholder groups, not just commercial brands. Second, will they run genuine consultation with your board, staff and community rather than a single discovery call. Third, what does handover include, specifically documentation, training and whether your team can publish without a developer. Fourth, who does the work after the pitch, because in public sector procurement the gap between the pitch team and the delivery team is the most common source of regret.
Yes. We built for the Representative for Children and Youth and for the BC Human Rights Commissioner, both independent statutory offices in British Columbia, and both are listed on our work page. We have also worked with First Nations governments including the Tŝilhqot'in National Government, the Nisga'a Nation and TNDC. We have worked with First Nations governments for almost a decade, and across fifteen years we have shipped more than a hundred projects for nonprofits, public agencies and Nations.
WordPress in almost every case, and we have supported it in production for more than a decade. It is well understood by the people who will inherit your site, it does not lock you into a vendor, and it lets a communications officer publish without raising a ticket. When a project genuinely needs more than a theme and plugins can offer, we build custom features and integrations on top rather than changing platform.
As part of the build, not as a later phase. We work to WCAG 2.1 Level AA, which is the standard the Accessible British Columbia Act, the Accessible Canada Act and ADA Title II all point at, and we test with a keyboard and a screen reader rather than relying only on an automated scan. Accessible document templates are included, because for most public bodies the published PDFs are the larger gap.
Most of our clients stay with us, and our longest relationship is eleven years. Ongoing partnerships cover security updates, accessibility re-testing, performance, content support and the small changes that accumulate. We would rather price that honestly at the start than have a site quietly degrade for two years and then need rebuilding.
Tell us what you're planning and we'll tell you honestly whether we're the right fit.
Start a conversation