OVERBRING Labs continued the development of Breek.gr , the SaaS platform for property management in Greece. The version 2.5 update has been a huge release, after three months of user feedback and development efforts.

More product-related information on this release can be found in Greek in the latest post of the Breek.gr blog .

This update primarily enhances tenancy/occupancy management and task handling, with additional improvements in UI/UX, performance, and new features. Its focus is on refactoring core subsystems for better usability, data validation, and scalability, while integrating modern UI patterns like modals and Kanban boards. Key development highlights include improved modularity, real-time search implementations, automated state transitions, and backend optimizations for faster data loading.

The biggest changes, however, are below the surfaces of the beautiful UI: almost half of the PHP backend has been refactored, leading to immense code deduplication and a cleaner business logic. The biggest changes include:

• A PHP re-implementation of Ecto.Schema and Ecto.Changeset in Schema and Changeset classes, though without Ecto’s change tracking. Even so, this has made the REST API responses cleaner and more predictable.

• Despite the lack of change-tracking, the Changeset->getChanges() method has made it possible to log changes to data and the user who made the changes to the database, enabling traceability per record, for which the UI is still in development.

• Wrapping of each entity’s business in classes derived from an abstract class, and the implementation of interfaces and traits, so that the code becomes less repetitive, more readable, and easier to review. Inspired from “schema modules” in Elixir codebases, every entity’s class implements its own set of changeset functions targeting each subset of data to be changed from the UI’s panes.

• Implementation of a “master query” abstract class with derived entity-specific classes that rely on each entity’s schema using the Schema class. This is the foundation of the upcoming improved filtering of any kind of entity on the UI.

• Implementation of “ledger accounts” for the upcoming massive upgrade to the finances subsystem with double-entry bookkeeping.

• Consistent use of a Result class with Err and Ok subclasses that can wrap results, error messages, exceptions… anything, really. Each subclass implements methods that transform the result into an HTTP response, with optional HTTP status modification. This has been the biggest boon to the PHP codebase, as it keeps the code concise and deals with the prior excessive null-checking.

• Automatic reporting of Err instance creation to our self-hosted ntfy.sh instance, making it possible to receive real-time notifications about errors encountered in production.

• Use of OVERBRING Labs’ multi-site self-hosted OpenStreetMap Nominatim API for supplementing the (often, surprisingly low-quality) data that the Google Maps API returns for locations in Greece, especially if those locations are remote.

• A revamp of the recording of geolocations through database normalization, making it simpler to check for properties in the same postal code, municipality, area, and division of Greece.

• Improved generation of occupancy “heatmaps” per property.

• Reimplementation of various API routes with a truly RESTful route-naming scheme, as a precursor to eventually providing API access to Enterprise customers.

• Implementation of a polymorphic association scheme for assignments of records to other records, with optional choice of role, expiration durations, and public slugs for sharing. This will soon make it possible to share documents and other information with property stakeholders who are not yet members of the platform. This functionality has been inspired by the “share” functionality of File Browser , thanks to the ongoing work on Elixir Software Engineering , which implements a REST API client in Elixir for File Browser.

• Gradually expanding use of caching with automatic invalidation using Redis tags. This has drastically improved response times for queries involving lists and especially for queries with associations, such as “properties that user X owns/manages/rents”, etc.

The web app has also seen significant improvements:

• Extensive modularization of the UI with components and diligent use of TypeScript types. Though TypeScript has its detractors, in Breek.gr’s case the switch from JS to TS has been a major boon for static code analysis and the early identification of errors.

• Improvements to the new occupancy creation modal, including components that show a heatmap of utilization of the selected property using SVG.

• Implementation of a componentized list and kanban view of tasks across all properties, and for a specific property. This component is now part of each Property page, fetching data asynchronously and autonomously from the backend.

• Improvements and componentization of the list view of financials across all properties, and for a specific property. This component is now part of each Property page, fetching data asynchronously and autonomously from the backend.

• Transition from single pages for creation of new records to using modals that can be triggered from any page using the “Quick Add” button on the navbar, preventing the break of a user’s flow for adding new occupancies. Soon to be expanded to properties and tasks.

• Continued improvements to the responsive layout of the web app, so that it becomes increasingly usable in viewports as small as that of iPhone SE.

• Deprecation of the v1.0 approach to horizontally laid-out filter drawer that was causing display issues on smaller viewports without enough space to afford for a drawer.

Work continues on the upcoming v2.6 release, which will tackle:

• The implementation of teams per “head account”, and the possibility of assigning contacts to teams and permissions for entities and their associated records to teams or individual team members.

• A foundational improvement of the task-management subsystem, with the possibility of assigning the roles of “executor” and “reviewer” to contacts.

• The ability to assign contacts to various roles depending on the entity type, such as a “responsible lawyer” and “responsible engineer” for a property, with corresponding access rights to subsections of a record’s data, including its documents depending on category and subcategory.