OVERBRING Labs continues the development of Breek.gr , the SaaS platform for everyone who manages properties in Greece.
Where we stand today (v2.11)
Since Breek.gr v2.9, Breek.gr runs on two backends / REST APIs: the legacy one, and a new one implemented in Elixir and Phoenix. Between v2.9 and the current v2.11, our Elixir/Phoenix REST API has gradually taken on more and more duties from the legacy REST API, making it possible to hydrate list views with many interconnected entities with a latency that the legacy backend could never match.
This shift has already delivered significantly faster and more responsive experiences for our users, especially when working with complex property data and interconnected information, such as the listing of properties, occupancies, finances and contacts.
The upcoming major upgrade to v3.0 relies on the “sister backend” that’s running Elixir, SQLite, Oban and various other solid Elixir libraries battle-tested in Breek.gr since v2.9 to deliver features such as: supplier business management, publication and connections, per-contact Payment Accounts, double-entry financial book-keeping, an improved contacts list, and the first inklings of a new feature tier that delives the lightweight real-estate CRM functionality that our customers have recently been asking for.
Breek.gr grows with our customers, and vice versa
As Breek.gr’s user base and number of properties managed on the app both keep growing, our architecture and tech stack grows with the needs of our users.
In a classic “Strangler Fig” migration pattern with some engineering twists that might one day be the subject of a blog post on overbring.com, already in the upcoming v3.0 the Elixir/Phoenix backend takes on even more responsibilities from the legacy backend.
Towards a monolithic Elixir application
The goal is to eventually (within 2026 or by end of 2027/Q1) move away from a split frontend/backend architecture and towards a monolithic Elixir app that serves a Phoenix REST API and uses Phoenix LiveView for the web app. Our internal experiments already demonstrated the many benefits of this approach compared to having NextJS consuming one or two REST APIs, in terms of performance, maintainability, and development velocity.
Agility means being responsive to a growing and changing market
In the past 9 months we have seen an influx of new customers who have kept providing us with requests for new features and adaptations to the current functionality of the web app to better serve their thus-far latent and increasingly recognized needs in their day-to-day of managing real-estate properties in Greece.
One notable recent example is the massively upgraded Dashboard feature that has turned from the working but unexciting v1.0 into the “second brain” of the property manager, with metrics and lists of things that require the manager’s attention, such as expiring occupancies, expired occupancies with outstanding rent payments, expired and expiring documents requiring renewal, tasks requiring acknowledgment, finalization or review, and financial transactions with deadlines that are looming or overdue.
As we have thus moved from developing 80% towards our product vision to 80% towards functionality that is market-led and still compatible with our original product vision (and even beyond that), maintainability and responsiveness of our internal software development to customer requests have taken on a paramount importance at this stage of Breek.gr’s business growth.
This evolution gives us much stronger foundations for the features our users are increasingly asking for: better collaboration tools between property managers, owners, and tenants; the involvement of suppliers in work-specific aspects of a property and tasks related to properties or their occupancies; clearer oversight of property groups (buildings and complexes); and more powerful reporting and automation, all while keeping the application fast and reliable as we scale toward evermore properties managed, owned, rented and supplied to on Breek.gr
Future-proof thanks to a better tech stack and architecture
Moreover, switching to Elixir and Phoenix LiveView will enable the implementation of features that support collaboration and communication between property stakeholders (managers, owners, tenants and service/equipment suppliers).
Phoenix LiveView in particular has proven to be a game-changer in our in-development clean-slate reimplementation of Breek.gr entirely in Elixir. It allows us to build highly interactive, real-time features with far better performance and much simpler code than our previous split setup. Because (just one example) having to duplicate business logic for web UI forms and REST route handlers is nonsense when Ecto.Changeset will do everything consistently, regardless of whether you’re using the Phoenix LiveView web app or the future Phoenix REST API (for Enterprise-tier customers).
It also matters because of security and our focus
It also helps that we won’t anymore have to deal with the steaming pile of garbage that the npm and JavaScript ecosystem have devolved into, with numerous fresh and worrying vulnerabilities every week and perennially-outdated and memory-leaking dependencies, plus NextJS’s constant changes that serve Vercel itself while detracting our development capacity from our key focus: the product itself and how it turns property management for our customers into a professional pillar of profitability.
Keeping our eyes on the ball
By building a true monolithic Elixir application and at our projected requirements for scale over the next 3 to 5 years, this new foundation gives us and our users confidence that Breek.gr will remain fast and maintainable for years to come, while we focus on what matters most: delivering the best property management user and customer experience in the Greek market (and beyond).
