Property Management Software: From a Specification of Hundreds of Items to a Sprint Plan

On the table there is a technical specification with hundreds of items. From request management to dues accrual, from visitor registration to license plate recognition, from an AI assistant to disaster and emergency management: 13 main headings and dozens of sub-requirements. All of them are important, and all of them will go live one day. A project that sets out with such a document faces two traps: trying to do everything at once, or losing months in a prioritization debate.

In Property Management Software, our first job was not to write code but to turn this document into an executable plan.

The project in brief

Property Management Software is an operations platform we developed for a client that manages a large number of very different residential complexes under one corporate roof. It consists of a web admin panel and the resident, field and manager mobile apps. The request and complaint, fault–maintenance–work order, dues and finance, common area reservation, visitor, parcel, announcement, inventory and meter modules all run on the same data backbone. External systems such as ERP and accounting, bank POS, e-Invoice, SMS, IoT meters and license plate recognition are connected through a separate integration layer.

From the specification item to the acceptance criterion

In the first step we divided the specification into eight core module groups: identity and authorization; complex, block and physical structure; request and complaint; visitor and guest; resident services; communication and notification; mobile and panel foundations; technical infrastructure and security. Then we broke each group into submodules and wrote a document in the same template for each submodule:

• Which specification item it corresponds to and which phase it belongs to,
• Business rules, main scenarios and exceptions,
• Data fields, screen requirements and dependencies,
• Acceptance criteria, open points and assumptions.

These documents turned into sprint-based work packages. Every specification item was tied to a module document, and every module to a sprint package, and acceptance checks were carried out along this chain. The answer to the question of why a screen exists or where a rule comes from was always an item number.

The sprint order of the first phase reflected this logic: first the technical foundation and the identity model, then the physical structure backbone, the panel and mobile sign-in interfaces, the request flow and notifications, visitor and resident services; and last, the hardening of the security, audit and permission layer and acceptance preparation.

Leaving each phase ready for the next

We built a three-phase plan. In the first phase, identity, authorization, physical structure, requests and resident services went live; in the second phase, finance, dues, maintenance, reservations and field mobile were added; in the third phase, the platform was completed with advanced modules such as IoT, access control, staff shifts and the AI assistant. Each phase went live with its own acceptance criteria, and the next was built on top of the same backbone.

One of the most useful parts of the plan was the “out-of-phase but dependent areas” list that appeared in each phase's document. In the first phase, hardware-dependent access systems, the full flow of the financial integrations and meter data were not delivered; but the data model and architecture were built with these areas taken into account. When license plate recognition arrived in the third phase, the foundation that matches vehicle information to the physical structure had been in place since the first phase.

We applied the same logic to external systems. Bank, e-Invoice, ERP, license plate recognition and meter devices came into service on different timelines. Because we connected the integrations through a separate adapter layer that does not touch the business rules, a delay in one integration did not hold up the product. API keys and service statuses are also managed from the panel; each connection, such as bank or ERP, has its own key, and which complexes and which scopes it is used in is kept on record.

Security from the ground up, distinctions in writing

The role–permission matrix, audit logs, KVKK (Turkish Personal Data Protection Law) consent management and API key management were not left for later; they went live as part of the first phase. We saw the benefit of writing business rules in such detail in the documents most in authorization design. The same person can be an owner in one complex and a tenant or a consultant in another. That is why the user was kept as a single record; permissions are granted through the complex link and on a role basis. Request teams and job teams were also defined independently of each other.

One distinction that made it into the document closed a hole that could have appeared later, right from the start: record type and application role are not the same thing. Selecting the “consultant” tag in the registration form gives nobody any complex permissions; permission opens only with the role added to the complex link. Risks such as a label silently opening up permissions become visible only when such a distinction is put into writing.

What we learned in the field

• Do not shrink the specification; make it traceable. Instead of cutting the scope, tying every item to a document and a sprint package took prioritization out of the realm of debate.
• Write the acceptance criteria at the start of the work. Knowing from the outset what counts as done and when made it possible to take each phase live with its own acceptance.
• Design today the work that will not be done today. Taking out-of-phase but dependent areas into account in the data model allowed later phases to be built on the same backbone.
• The integration calendar should not be the product calendar. The adapter layer did not turn delays in external systems into delays in the product.

A large specification is not an obstacle; read well, it is the most detailed roadmap. All it takes is that every item has a phase, a document and an acceptance criterion.

How can your specification turn into a plan?

If you are about to set out with a broad specification, or you do not know where to start with the requirements you have, we can work together from the planning stage. You can examine the modules on the Property Management Software project page and schedule a meeting with us through our contact page.