DEV Community

Amin Haiqal
Amin Haiqal

Posted on

Building a Strata Finance System (Because the Current Way Isn’t Working)

There’s a quiet kind of chaos in how many strata communities manage their finances.

On the surface, everything looks fine. There’s a spreadsheet somewhere. Numbers are filled in. Rows are coloured. Someone is “handling it.”

But the moment you start asking simple questions, things begin to fall apart.

Who still owes money?

How much?

Since when?

Did they already send their payment?

Was it verified?

Who followed up last?

No one has a clean answer. Not immediately. Not confidently.

Because the answers don’t live in one place.

They live across spreadsheets, WhatsApp conversations, emails, and memory. Sometimes in someone’s head. Sometimes nowhere at all.


Over time, the system becomes less of a system and more of a patchwork.

A spreadsheet is used to track balances. Another column is used to mark who has paid. Colours are introduced to signal urgency. Green means safe. Red means overdue. Yellow means “needs attention,” whatever that means this week.

Meanwhile, payment proofs arrive through WhatsApp. Screenshots, bank slips, forwarded messages. They get buried under new messages, lost in group chats, or forgotten entirely.

Follow-ups happen, but inconsistently. One admin calls. Another sends a message. Someone promises to pay. There is no record of it. A week later, the cycle repeats.

Residents dispute their balances. Admins double-check manually. Time is spent verifying things that should have been obvious.

Nothing is technically broken. But nothing is reliable either.


At some point, it becomes clear that the problem is not effort.

It’s structure.

So I started thinking about what a better system would look like; not in terms of features, but in terms of clarity. What if there was a single place that could answer, without hesitation:

Who owes what, since when, and what has been done about it?

That question became the starting point.


The system I’m building is not meant to replace people. It’s meant to replace the uncertainty around the work they are already doing.

Every charge—maintenance fees, sinking funds, penalties—should be recorded clearly, tied to a specific unit, with a known due date.

Every payment should be traceable. If a resident submits proof, it should not disappear into a chat thread. It should enter a flow. It should be verified or rejected. It should leave a trace.

Balances should not require manual calculation. They should exist as a result of what has already happened—charges issued, payments verified. Nothing more, nothing less.

Overdue units should not be guessed. They should be classified automatically, based on how long they’ve been unpaid, or whether they’ve ever paid at all.

And follow-ups; arguably the most human part of the process—should still be tracked. Not to control people, but to ensure continuity. So that when someone looks at a unit, they don’t just see numbers. They see history.

What was said. What was promised. What comes next.


Some residents won’t be able to pay everything at once. That’s reality.

So the system needs to handle that too. Installment plans shouldn’t live in scattered notes or informal agreements. They should be structured, visible, and measurable. Something both sides can understand.


When all of this comes together, the goal isn’t complexity.

It’s clarity.

A dashboard that doesn’t try to impress, but simply shows what matters. Total outstanding amounts. Overdue units. Payments waiting to be verified. The cases that need attention today.

Not more data. Just the right data, in the right place.


This is not just software for the sake of it.

It’s an attempt to turn a fragmented, manual workflow into something dependable. Something that reduces doubt instead of adding to it.


I’m building this in public because I don’t think this problem is unique.

If you’ve ever had to manage payments, follow up on overdue accounts, or piece together financial records from different places, you’ve probably seen some version of this.

So this is as much an exploration as it is a build.

What does a reliable workflow actually look like?

And how do we get there, step by step?


That’s what I’ll be figuring out next.


If you're dealing with this kind of workflow and trying to make it more reliable, I’d be interested to hear how you’re approaching it.

I’m currently building in this space, and also open to working with teams that want to improve their internal systems.

You can reach me here:
https://axelyn.com/

Top comments (0)