MeetFlowMeeting governance for municipalities and public boards
MeetFlow carries a board meeting from the first agenda item to the signed minutes, and keeps the decisions where anyone can find them later. We designed the product and built it as a modular .NET platform with a Next.js front end.
- Client
- Private client
- Sector
- Public sector software
- Year
- 2026
- Platforms
- Web app, Tablet, Mobile web
- Services
- Product and UX design, Web development
One workspace for the whole life of a board meeting: the agenda, the case files, the vote, the minutes and the record that follows. It is built for organisations whose decisions are public property.
Built for
- Municipal councils and their committees.
- Chairs and secretaries, who run the meeting and own the record.
- Board members, who read the papers and cast the votes.
- Administrators, who answer for who saw what and when.
The problem
A council meeting is a legal act, not a calendar entry. The agenda has to be published before it happens, the papers have to reach the right members and nobody else, the vote has to be countable afterwards, and the minutes have to be approved by a named person. Most of that work runs on email, a shared drive and a document template.
That arrangement fails quietly. Papers reach a member who left the committee in March. A vote is remembered differently by two people. The minutes exist in four versions with no way to tell which one the chair signed. None of it is visible until somebody asks for it under a freedom of information request.
The organisations that need this most are also the ones that cannot simply trust a supplier. Sensitive items have to be marked and limited, every action has to leave a trace, the data has to stay in the EU, and staff have to be able to work in their own language.
Goals
- 01Make the lifecycle of a meeting something the software enforces rather than something people remember.
- 02Give the chair and the secretary the powers their roles actually carry, and give nobody else those powers.
- 03Produce minutes that are a record, not a document: versioned, approved by a named person, and exportable.
- 04Keep confidential items confidential without hiding them from the people entitled to see them.
- 05Answer the question of who did what, to which item, at what time, from the product itself.
Our role
We designed the product and built both halves of it, and we work on the platform continuously.
What we delivered
- Product definition from the client's tender documents
- Full interface design and a component library the build follows
- Modular .NET back end, one module per part of the domain
- Next.js front end, designed for desktop, tablet and phone
- Role and permission model, multi-factor authentication and audit
- Translation system covering nine languages
- Billing, trials and plan changes
How we worked
- 01
Read the tender
The client's requirement documents were turned into a traceable scope, so every screen could be pointed back at the clause that asked for it.
- 02
Design the whole product
Screens, states and interactions were designed before the build, including the ones nobody enjoys drawing: a vote where a member has declared a conflict, minutes returned for changes, a board a user is no longer on.
- 03
Build it as modules
Auth, boards, meetings, documents, voting, minutes, notes, tasks, search, notifications, audit, translations and billing were each built as their own module with their own database schema, talking to each other over a message bus.
- 04
Make the rules refuse
The lifecycle and the roles are enforced in the back end, not the interface. A meeting cannot be released without an agenda item, a date and a participant, and the endpoints say so in plain language when you try.
- 05
Ship behind a gate
Every change runs through staging before production, and the production deploy needs a human to approve it.
Screens and features
A lifecycle the software holds
Draft, released, ongoing, completed. Releasing a meeting notifies its participants, starting it locks the agenda, and completing it hands the minutes to the secretary.
Chair and secretary as badges
They are marks on a board membership rather than separate accounts. Only a chair or secretary can create a meeting or set an agenda, and only the secretary finalises the minutes.
Votes with the awkward cases built in
A vote can be opened and closed on an agenda item, members can declare a conflict of interest or be marked not eligible, and the tally becomes the recorded decision.
Minutes that have to be approved
The secretary drafts and submits, the chair can return them with a written note saying what to change, and only then can they be finalised into a numbered record with a PDF.
Confidential items with a time limit
An agenda item can be classified, and a classified item can carry a visibility window in days, so sensitivity expires on a schedule instead of by memory.
Search that respects the walls
One search covers meetings, agenda items, documents, comments, private notes and minutes, and returns only what your board memberships entitle you to see.
Multi-factor authentication, not optional
An account cannot reach the workspace until an authenticator app is enrolled, and recovery codes are issued at enrolment.
Technical choices
What the product is built with, and why.
- .NET 10 with a module per domain
- Fifteen modules, each owning its own PostgreSQL schema and its own data context. The boundaries are real, so one module's migration cannot reach into another module's tables.
- Vertical slices over layered services
- Each endpoint is a slice holding its own request, validation, handler and authorisation rule. The permission that guards an action sits next to the action, which is where anyone looking for it will start.
- A durable message bus between modules
- Modules publish events instead of calling each other. Messages survive a restart, so the audit trail and notifications that follow an action are not lost when a process cycles.
- PostgreSQL with an append-only audit schema
- Every module's persistence pipeline writes into one audit schema. The audit screen is a read of that table rather than a separate log the application could forget to write.
- Next.js 16, server rendered
- The session is read on the server, so a protected page never renders before the permission check has run, and a member who has lost access to a board never sees its contents flash on screen.
- Translations held in the database
- Nine languages including Danish, Norwegian, Swedish, Icelandic and Faroese. Holding them as data rather than files means a wording fix does not need a release.
Building something that has to hold up to scrutiny?
Regulated work, audit trails and permission models are the part we like. Tell us what you are dealing with.