Forem: Amin Haiqal

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

Amin Haiqal — Wed, 29 Apr 2026 17:29:30 +0000

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/

From Inventory Chaos to a Real-Time Command Center

Amin Haiqal — Mon, 27 Apr 2026 09:40:32 +0000

A system that doesn’t exist yet but probably should

At some point, every growing eCommerce system hits a strange wall.

Not traffic.
Not sales.
Not even infrastructure.

Just… inventory.

It usually starts small.

A product goes out of stock on one platform but still shows as available on another. An order slips through. Then another. Someone from operations jumps in, exports a CSV, fixes a number, uploads it back and by then those problems solved.

Until it happens again.

Now imagine that but across:

Shopify
multiple marketplaces
warehouse systems
internal spreadsheets

And none of them agree with each other.

The Moment Things Stop Making Sense

There’s a point where teams stop asking:

“Why is this wrong?”

…and start asking:

Which system is correct?

That’s when you know the problem isn’t operational anymore. It’s architectural. Because under the surface, every system believes it owns the truth.

A System With Too Many Writers

Inventory updates are happening everywhere:

orders reduce stock in Shopify
warehouses adjust quantities
internal tools override numbers manually

Each system writes data and none of them coordinate. From a distributed systems perspective, this is almost guaranteed to fail not because of bugs but because there is no single authority over state.

The Hidden Cost

At first, it looks like noise:

a few mismatches
some manual fixes
occasional refunds

But over time, the system starts leaking:

overselling becomes normal
stockouts happen while inventory still exists
operations slow down
decisions rely on outdated data

Eventually, growth itself becomes constrained. Not by demand. But by uncertainty.

The Shift in Thinking

At this point, it’s tempting to patch things:

add more sync jobs
increase polling frequency
introduce more scripts

But those don’t solve the problem. They just move it around. The real shift comes from re-framing the question and not

“How do we sync systems better?”

but

“What if no system is allowed to update inventory directly?”

That’s where this design begins.

A Different Approach: Treat Everything as an Event

Instead of letting systems mutate inventory freely:

Every change becomes an event.

an order is placed
stock is adjusted
a warehouse update happens

Nothing updates inventory directly anymore. Everything reports that something happened.

That single constraint changes everything.

Introducing a Controlled Flow

Once everything is an event, the system can enforce a pipeline:

Event → Queue → Processing → Central State → Sync Out

Instead of chaos, there is flow we can do and instead of conflict, there is order we can make.

Where the Real Control Happens?
At the center of this design is something intentionally restrictive:

A central inventory service.

It has one job which is maintain the only version of truth. No marketplace. No warehouse system. No internal tool. None of them are allowed to write inventory directly anymore. They can only send signals.

But why This Matters More Than It Seems?

This isn’t just about structure, it’s about control over state because once there is only one place where inventory can change:

conflicts can be detected
duplicates can be ignored
rules can be enforced consistently

Without that, consistency is mostly luck. Speaking reality, things will still go wrong even with this design. The system has to deal with:

duplicate events
delayed updates
simultaneous changes

So the pipeline need to include safeguards:

idempotency (so the same event doesn’t apply twice)
timestamps (to reject stale updates)
versioning (to prevent overwrites)

The Subtle but Important Flip

Before:
Every system tries to stay in sync with every other system.

After:
Every system stays in sync with one system.

That shift reduces complexity more than any optimization ever could then something interesting happens.Everything will became simpler once the central state is reliable

syncing outward is predictable
dashboards reflect reality
operations stop guessing

For the first time, someone can ask:

“What’s our stock right now?”

…and actually trust the answer.

This System Doesn’t Exist (Yet)

This is still a design.

A proposal. A system on paper.

But the problems it addresses are very real and I believe very common.

And the pattern shows up everywhere, whenever multiple systems are allowed to mutate the same data independently…

…consistency becomes an accident.

Final Thought

Most inventory problems don’t come from bad tools. They come from systems that were never designed to agree. Fixing that isn’t about adding more logic, it’s about deciding very clearly where truth is allowed to live.