A housing cooperative website the board can run itself.
A housing cooperative needs three things from a website: documents that open, news the board can post without a developer, and shared equipment that can be booked without anyone keeping a list. Everything else is decoration.
What a housing cooperative actually needs
The documents, and they have to open. Bylaws, house rules and application forms are why people come. A resident applying to build a terrace is not looking for a news item, she is looking for one form.
News the board posts itself. An information letter that has to go through a developer does not get posted. It ends up in a group on a social network instead, and a page nobody updates is a page people stop visiting.
Booking for what is shared. Trailer, function room, laundry. Without a system it is a message thread, and a thread is not an overview.
And one address that survives a change of board. A board sits for a few years at a time. The website should not belong to a person.
What is hard here in particular
A housing cooperative has no operations department, and that is the whole difference from an ordinary client.
The password is the problem, not the solution. Nobody administers users. A shared password meant to last four years circulates in an email thread, and a password field in front-end code is no barrier at all: anyone can read it in the browser.
Everyone should be able to use what is shared, but nobody should need an account. A neighbour booking the trailer for twelve minutes will not create a user. Require it, and the trailer gets booked in a message thread again.
What gets posted stays posted. An information letter from last year still sitting at the top says more about the cooperative than its contents do.
And document links rot quietly. Nobody gets an error when a link stops working. The resident simply does not find what she is looking for, and calls the board instead.
Where the boundaries are set
Two decisions make the rest simple, and both are about where a rule lives.
Sign-in with no account to administer. A one-time link sent to an address on a list is a sign-in nobody can forget the password to, nobody can pass on, and nobody has to create. The list is the board’s addresses, and it changes when the board does.
Access that lives in the database. If a neighbour is to delete their own booking and nobody else’s, that rule cannot live in the interface: an access rule that exists only in the front end is a recommendation, and it can be read and worked around by anyone with a browser. At row level in the database it is a boundary, whoever is asking and however they ask.
It is the same rule the studio applies everywhere else, and it is why a housing cooperative can let neighbours touch data without hiring someone to watch it.
The project as evidence
Varingskollen Borettslag is a client project. The sentences below are the register’s own, taken from the project list and not rewritten for this page.
The document links to bylaws, house rules and application forms pointed at nothing. The news items lived in the browser’s own memory, behind a password field in the frontend code. The shared trailer had no booking system.
I ported the site to Next.js and built the board’s tooling: one-time-link sign-in locked to the board’s five addresses, an admin panel for news and notices, and trailer booking against a database with row-level security, where a neighbour deletes their own booking with a key instead of having to sign in. The conditions at the top of the page are pulled from three sources: Fnugg supplies lifts, slopes and snow depth, MET supplies the forecast, and Frost supplies the station’s measurements. Fnugg’s terms require the credit to sit with the data, so it renders only on the page that shows the conditions, and disappears if a source is down.
The database layer is built, but waiting for the board to switch it on.
Note that none of this is a result figure. The studio does not publish traffic, time spent or savings on this site, for any project.
The way onward
The scoping call is free, and it is a conversation about what the cooperative actually needs rather than a tour of what a website can contain. A written quote afterwards.
Book a scoping call