Indian Township Housing Authority, a full website rebuild for a tribal government

Context

Indian Township Housing Authority

Role

Lead engineer and primary contact

Stack

Next.js · TypeScript · Tailwind CSS · Vercel

Problem

ITHA needed a website that reflected the seriousness of a tribal government services organization. Easy to navigate for residents looking up housing programs, professional enough to support the authority's external relationships, and maintainable by a small team after launch.

Constraints

→Government context. Accuracy, accessibility, and clarity over visual flourish
→Limited internal technical capacity. The client team needed to maintain content after handoff
→Real budget, real timeline. Not a portfolio piece, a working asset for an active organization
→Mobile-first. Significant fraction of community access is via phone

Architecture

Static site generation on Next.js, deployed to Vercel

whyContent is informational and changes infrequently. SSG gives the fastest possible page loads, zero server costs at this scale, and the simplest possible operational model: just a git push to deploy.

tradeoffAdding dynamic features (forms, member portals) later requires more work than if I'd started with a fuller backend. Acceptable. Those features weren't in scope, and adding them when they're actually needed is cleaner than maintaining infrastructure for hypothetical use.

Built the content structure around the authority's existing program taxonomy, not a generic CMS schema

whyThe site exists to help residents find specific programs and services. Mapping the information architecture onto the way the authority actually describes its work, rather than forcing it through a generic 'page/post' model, meant residents could navigate by the words they already used.

tradeoffContent authoring is slightly more constrained. Worth it; the structure matches the mental model of both staff and residents.

Tailwind for styling rather than a component library

whyTribal government context calls for restraint and consistency, not the visual character of an off-the-shelf component library. Tailwind let me build a small, tight system of components that matches the authority's visual identity rather than retrofitting one.

tradeoffMore upfront component work. Pays off in maintenance; there's no library version to track, no dependency surface to manage.

Outcomes

Project lifecycle managed

End-to-end

Proposal, scoping, design, build, launch, and handoff documentation

Hosting cost

$0/month

Vercel free tier handles the traffic comfortably; custom domain only.

Why this project mattered

ITHA serves an active tribal community with real housing needs. The website isn't a marketing piece. It's how residents find out about programs they qualify for, how external partners learn what the authority does, and how the authority presents itself to other organizations.

That framing changed every decision. The site couldn't read as a generic templated agency project. It also couldn't be a designer's exercise. The bar was: would the people this site is for find what they need quickly, and would the people the authority works with come away taking ITHA seriously.

The lifecycle

I led the project from initial proposal through launch:

Proposal. Wrote the scope, the timeline, the deliverables, the price. Negotiated terms. Got a signature.

Scoping. Worked with the authority to map their existing programs and services onto a navigation structure. The right information architecture for this site was not "Home / About / Services / Contact." It was the program taxonomy the authority actually uses internally, exposed to residents in plain language.

Design. Established a visual system: type scale, color, spacing, component shapes. Restrained on purpose, given the government services context.

Build. Next.js with the App Router, static generation, Tailwind for styling. Components built to be reused; content authored in a way the client team could update after handoff.

Launch. Domain, DNS, redirects, SEO checks. Walked the client team through deployment so a content update is git push from their end.

Why static generation was the right call

The site is fundamentally an information site. Programs, eligibility, contact info, document downloads. None of this changes every hour. Most of it doesn't change every month.

That profile is exactly what static generation is for. The whole site builds at deploy time into static HTML and assets, served from Vercel's edge cache, which means:

Every page loads in well under a second from anywhere
Hosting costs round to zero at this traffic level
The operational story is "git push and you're live." No servers to maintain, no databases to back up, no security patches to apply.

The alternative, a CMS-backed site with a database, would have added meaningful operational complexity for no benefit the authority would notice.

What the project taught me

The two skills I underestimated coming in: writing proposals and writing handoff documentation. Both are forms of writing for an audience that isn't going to read your code.

A proposal isn't a feature list. It's a story about what the project is, what it isn't, what success looks like, what could go wrong. I rewrote the ITHA proposal three times before the version that the authority's leadership read and immediately understood. That version was shorter than the first.

Handoff documentation has the same character. The audience isn't a future engineer. It's the staff member who needs to update a page next month and doesn't want to learn Git to do it. The version of the handoff doc I shipped opened with a step-by-step walkthrough using their actual content as the example, not a generic one. The hours spent on that doc have paid for themselves in support questions I haven't had to answer.

What I'd do differently

I'd push harder on shared content review during the build, not just at the end. We did content review as a separate phase after the design was largely set, and a couple of programs ended up needing layout adjustments because the actual copy didn't fit the placeholder shape. Reviewing real copy alongside design from the start would have avoided two minor rebuilds.

What I learned

Client work is half engineering, half communication. The biggest risk in this project wasn't technical. It was making sure the authority's leadership and the engineering decisions were lined up on what we were building and why.
Restraint is a deliverable. A government services site needs to feel trustworthy, which means resisting most of the visual moves a designer would default to on a startup site. Less personality is more credibility.
Handoff documentation is part of the project, not a postscript. The hours spent writing the content update guide and the deployment notes have made me a better contractor for every project since.