Skip to content

Case study

A facility management platform that replaced spreadsheets and phone calls

A company running many buildings had no single view of open work, who owned it or what it cost. We are building one platform for requests, vendors, inspections and expenses, and the first modules are in daily use.

Quick facts

Industry
Construction and facilities
Product type
Web application
Platform
Web, works on phones
Timeline
Ongoing, first modules in use
Status
In active development

At a glance

What changed

One place for every request

Maintenance requests from every building land in one queue with a status, an owner and a history.

Open work by building

Managers can see what is open in each building and who is responsible, without calling around.

Reporting as a filter

Monthly reports are a filter and an export instead of a spreadsheet built by hand.

The right access for each role

Admins, managers, staff and occupants each see only what they need.

The client

The client and the situation

The client is a company that operates and maintains several buildings and facilities, with a mix of in-house staff and outside vendors. Each building has its own spaces, occupants, recurring inspections and running costs. A small operations team coordinates all of it.

The company had grown building by building. Each new site brought its own way of working, its own spreadsheet and its own group of contacts. By the time they came to us, the operations team knew the work was getting done, but could not easily prove it or see it as a whole.

The challenge

The challenge

Requests, vendors, inspections and expenses were spread across spreadsheets, messaging groups, email and phone calls. Nobody had one view of what was open, who was responsible and what it cost. When an occupant asked about a repair, staff had to search messages to find out. When a manager asked what a building cost to run last month, someone spent a day assembling the answer.

The risk was not only lost time. Recurring inspections could slip without anyone noticing. Vendors could be paid twice, or not at all, because invoices were matched to work by memory. And when a dispute came up, the history of a request was scattered across several phones.

Before

How the work was done before

An occupant reported a problem by phone or message to whoever they knew. That person told the operations team, who added a line to a spreadsheet for that building, if they remembered. A vendor was called and the job was agreed by phone. Photos of the finished work stayed on the vendor's phone or in a chat group.

Inspections lived on a separate calendar. Expenses were typed into another spreadsheet when invoices arrived. At month end, a manager combined the sheets by hand to report on each building. Each step worked on its own, but nothing connected them.

Objectives

What the project had to achieve

  • Put every maintenance request in one queue with a status, an owner and a full history.

  • Give managers a live view of open work and costs for each building.

  • Track vendors, recurring inspections and expenses in the same system as the requests they belong to.

  • Give each role, from admin to occupant, the access it needs and nothing more.

  • Make monthly reporting a filter and an export, not a day of spreadsheet work.

The solution

What we built

We are building a web application that holds the whole operational picture: buildings, units and spaces, occupants, maintenance tickets, vendors, inspections, expenses and documents. It works in a desktop browser for the operations team and on phones for staff and occupants. It is designed from the start for many buildings, with role-based access that controls who sees what.

The platform is being delivered in modules, so the team gets value early. Every module sits on the same shared structure of buildings, units and users, so each new part connects to the data that is already there.

  • Buildings, units and spaces

    A clear structure for every site, down to the unit or room, so each request and cost has a home.

  • Occupants

    Occupant records linked to their units, with a simple way to raise and follow requests.

  • Maintenance tickets

    Tickets with priority, status, assignment, comments, photos and a full history.

  • Vendor management

    Vendor records, the work assigned to each one and the documents they provide.

  • Recurring inspections

    Inspection schedules that create tasks automatically and flag anything overdue.

  • Expense tracking

    Costs linked to buildings, tickets and vendors, ready for reporting.

  • Document storage

    Contracts, certificates and photos stored against the building, ticket or vendor they belong to.

  • Role-based access

    Admin, manager, staff and occupant roles with different views and permissions.

  • Reports

    Filters by building, period and category, with exports for accounting and owners.

UX and UI

The UX and UI approach

Operations staff spend their day in this tool, so the desktop views are built for speed: tables that show many records at once, and filters by building, status and vendor. The ticket detail page shows everything about a request on one screen: the unit, the occupant, the vendor, the photos, the costs and the timeline.

Occupants and field staff use phones. For them, the same screens collapse to simple lists and large buttons. Raising a request takes a category, a short description and an optional photo. The goal is that nobody needs training to report a broken light.

Architecture

How the pieces fit together

Staff,managers and occupantsWeb appNext.jsApplicationserverNode.jsDatabasePostgreSQLDocumentstorageReports andexports

The platform is a Next.js web application with a Node.js application layer and a PostgreSQL database. Every record belongs to a building, and access rules are checked on the server for every request, not only hidden in the interface. Documents and photos are stored separately from the database and linked to their records. The whole system runs on a self-managed server with Coolify, which keeps hosting simple and costs predictable.

AI-accelerated

Where AI sped up the build

Honest about what AI did, and what people did.

  • Planning: AI helped turn workshop notes into a first list of modules, user stories and edge cases, which we then reviewed with the client.

  • Data model: first drafts of the database schema were generated with AI and then reshaped by our engineers around real buildings and roles.

  • Screens and forms: AI generated much of the repetitive code for lists, forms and detail pages. Engineers reviewed every change.

  • Tests: AI drafted tests for permissions and ticket status changes, which we extended with the cases that matter most.

  • Documentation: AI drafted user guides for each role from the finished screens, edited by the team before release.

Integrations

Integrations

  • Document storage

    Files and photos attached to buildings, tickets and vendors.

  • Exports for accounting

    Expense and report exports that the finance team can use without retyping.

  • Role-based sign-in

    One sign-in for every role, with permissions checked on the server for each request.

Screens

Concept screens

Simple mockups of the described interface. Real screenshots will replace them.

app.example.com/tickets
DashboardTicketsBuildingsVendorsInspectionsExpensesReportsSearchNew ticketOperations dashboardAll buildings, this monthOpen tickets24Urgent3Inspections due7Costs this month$18,420BuildingOpenOldestOwnerStatusBuilding A86 daysOperationsReviewBuilding B52 daysSite staffOn trackBuilding C711 daysOperationsOverdueBuilding D41 daySite staffOn track
Operations dashboard with open tickets by building
app.example.com/tickets
DashboardTicketsBuildingsVendorsInspectionsExpensesReportsSearchNew ticketMaintenance ticketsTicketBuildingUnitVendorStatusWater leak in kitchenBuilding A4BPlumbing vendorUrgentDoor closer brokenBuilding CLobbySite staffIn progressLight out in stairwellBuilding BStair 2Site staffDoneAir conditioning noiseBuilding D12AHVAC vendorWaitingLift inspection follow-upBuilding ALift 1Lift vendorOpenBroken window latchBuilding C3CSite staffDone
Maintenance ticket list with status and assignment
Water leak in kitchenBuilding and unitBuilding A, unit 4BPriorityUrgentAssigned toPlumbing vendorPhoto from siteAdded by site staffTicket createdOccupant, 08:12Vendor assignedOperations, 08:30Work startedVendor, 10:05In progress

Concept screen

Ticket detail on a phone, with photos and history
app.example.com/tickets
DashboardTicketsBuildingsVendorsInspectionsExpensesReportsSearchExportReportsCosts by building, last six monthsMaintenance costs per monthAprMayJunJulAugSepCategoryBuilding ABuilding BBuilding CPlumbing$2,140$860$1,420Electrical$980$1,210$640Inspections$1,500$1,500$1,500
Monthly cost report by building and category

Results

The results

The first modules are in daily use. Every maintenance request now lands in one place with a status, an owner and a history, instead of in a phone or a chat group. Managers can open a building and see what is open, who is working on it and how long it has been waiting.

Monthly reporting has changed from a manual build to a filter and an export. Because costs are linked to tickets and buildings as they happen, the numbers are ready when the month ends. We do not yet have measured before and after figures to share. When the client has them, they will appear here.

What the team can do now

  • See every open request across all buildings on one screen.

  • Answer an occupant's question about a repair in seconds, from the ticket history.

  • Assign work to staff or vendors and follow it to completion.

  • Produce a monthly report for any building with a filter and an export.

  • Give occupants, staff and managers the access that fits their role.

Before and after

Before and after

Before

Spreadsheets and phone calls

  1. Requests arrive by phone and message to whoever the occupant knows.

  2. Each building keeps its own spreadsheet, updated when someone remembers.

  3. Photos of finished work stay on personal phones.

  4. Inspections live on a separate calendar and can slip unnoticed.

  5. Monthly reports take a day of copying between sheets.

After

One platform for the whole operation

  1. Every request lands in one queue with a status and an owner.

  2. Buildings, units, vendors and costs are linked in one system.

  3. Photos and documents are attached to the ticket they belong to.

  4. Inspections create tasks automatically and flag anything overdue.

  5. Monthly reports are a filter and an export.

Technology

Technology stack

  • Next.js
  • Node.js
  • PostgreSQL
  • Tailwind CSS
  • Coolify

What comes next

What we would do next

Once the current modules are complete, we would extend the platform into planned maintenance and budgets, so managers can compare actual costs with plans for each building. We would also add automated approval steps for larger expenses, so spending above a set limit waits for a manager before it goes ahead.

We would add AI later, and only where it helps: reading vendor invoices into expense records and sorting incoming requests by category and urgency. Those match our data entry automation and workflow approvals solutions, and they make sense once the core data is complete and trusted.

Solutions in this project

Problems this project solved

Approval workflows

Requests, approvals and reminders in one place, with clear owners and deadlines instead of long email threads.

Automated reporting

Reports that build themselves from your systems on schedule, with a plain-language summary of what changed.

AI automation and integrations

Connect the tools you already use so data moves once, correctly, and AI reads the parts that arrive as text or documents.

Keep exploring

Start a project

Have a similar problem? Tell us about it.

Send a short brief. We reply with questions, a suggested plan and an estimate you can compare with other offers.

Your privacy choices

We use necessary storage to run this site. With your permission we also use Google Analytics to see which pages help people, and load maps from Google. You can change this at any time. Read the cookie policy.