How Managing a Wedding Fund Taught Me About Friction Discovery, Combinatorial Explosions, and Building Software

How Managing a Wedding Fund Taught Me About Friction Discovery, Combinatorial Explosions, and Building Software

Most software ideas do not arrive as flashes of inspiration.

Sometimes they arrive disguised as responsibility.

For me, one of those moments came when I was tasked with managing contributions for a family wedding.

At first, it sounded simple.

People pledge money.

People send money.

Record payments.

Generate reports.

Simple.

Or so I thought.

The First Encounter With Friction

Very quickly, I discovered that I was not managing money.

I was managing chaos.

Contributions came from every direction imaginable.

Some came directly from family members.

Some came from friends of family members.

Some came through mobile money agents.

Some came through relatives.

Some came in cash.

Some contributors paid everything at once.

Others paid in installments.

One person might contribute in three separate transactions over several weeks.

Another person might use two different phone numbers.

Another might send money using somebody else’s phone.

Another might be known in the records as “Mrs. Anna Mwakalinga” but appear in a transaction message as “Mama John.”

The complexity was growing rapidly.

Cross-Term Frictions

The most important lesson I learned was that friction points do not exist independently.

They interact.

If there are ten friction points, there are not merely ten problems.

There are combinations.

A contributor pays in installments.

The contributor uses a different phone number.

The contributor’s name appears differently in the transaction message.

The contributor expects immediate acknowledgment.

The contributor later disputes the balance.

Each friction point combines with every other friction point.

The number of possible scenarios becomes much larger than the number of individual problems.

It becomes a combinatorial explosion.

I started calling these interactions “cross-term frictions.”

Just as in algebra, the cross terms often become more important than the original variables.

The Human Side of the System

The money was only one part of the problem.

The emotions were another.

When people contribute money toward a wedding, they do not merely expect their money to be recorded.

They expect to be recognized.

They expect accuracy.

They expect fairness.

They expect visibility.

One day, somebody sent proof of payment into the WhatsApp group.

Everyone saw the screenshot.

Everyone assumed the payment had succeeded.

Later, the transaction was reversed.

The money never arrived.

Now there were two realities:

The social reality.

And the financial reality.

Meanwhile, I continued posting contribution updates.

Soon the phone started ringing.

“Why haven’t you included so-and-so?”

“They already paid!”

“Get serious!”

Sometimes it was the contributor calling.

Sometimes it was a father.

Sometimes it was a mother.

Sometimes it was another relative advocating on behalf of someone else.

The accounting system and the social system had become tightly coupled.

The Day Excel Saved Me

At one point I can honestly say:

“Nisinge toboa.”

I would not have survived.

More accurately:

“Nisingemudu. Bali wangenimudu.”

I would not have managed the system.

The system would have managed me.

This is where Excel became my lifeline.

What started as a simple spreadsheet gradually evolved into a miniature information system.

A contributor sheet.

A transaction sheet.

An expenditure sheet.

A report sheet.

A duplicate detection system.

A phone number normalization system.

A name normalization system.

An installment aggregation system.

A reconciliation system.

The workbook eventually grew to around ten sheets.

Each sheet solved a specific problem.

Together they formed something much larger.

Discovering the Power of Structure

One lesson became obvious.

The report is not where the work happens.

The work happens before the report.

Committee members were often surprised by how quickly I could generate reports.

They would ask for an update.

A few moments later, I would export a sheet and send it.

It looked effortless.

But the speed did not come from working quickly.

It came from structuring information correctly.

The report was simply a view into a system that was already maintaining itself.

I had created a centralized point of truth.

A quasi-relational database disguised as an Excel workbook.

Duplicate Detection: A Small Feature That Felt Like Magic

One feature I became unexpectedly grateful for was Excel’s duplicate highlighting.

People underestimate how powerful it is.

When you are dealing with hundreds of records, duplicates become difficult to see.

Computers excel at this.

A machine can instantly highlight potential duplicates.

Suddenly your eye has an anchor point.

Instead of scanning every record manually, you focus only on suspicious records.

The computer performs the searching.

The human performs the interpretation.

That division of labor is beautiful.

Name and Phone Number Normalization

I also learned that data is messy.

Very messy.

Rather than storing names in a single field, I separated:

  • Prefix
  • First name
  • Middle name
  • Other names

Then I generated the full name automatically.

Similarly, I created phone number cleaning formulas.

Whether someone entered:

  • 074…
  • 25574…
  • +25574…

The system normalized everything into a consistent format.

This dramatically improved duplicate detection and matching.

It taught me another lesson:

Many business problems are not really business problems.

They are data quality problems.

The Last Sheet

The most interesting sheet appeared near the end.

I think it was around the tenth or eleventh sheet.

At first glance it looked insignificant.

It was simply a place where I experimented with regular expressions.

I started extracting values from transaction messages.

Names.

Amounts.

References.

Phone numbers.

Instead of manually reading transaction notifications, I began teaching Excel to understand them.

This felt different.

The previous sheets were helping me survive complexity.

This sheet was helping me eliminate complexity.

It felt like a different level of abstraction.

The Introduction to Calculus

Looking back, that final sheet reminds me of calculus.

Before calculus, people could still calculate areas.

But they often required numerous approximations, geometric tricks, and repetitive procedures.

Calculus introduced a higher abstraction.

The problem did not disappear.

The representation changed.

Many lower-level operations became unnecessary.

The regex sheet felt similar.

Instead of manually parsing transaction messages over and over again, I could express the extraction logic once.

Then reuse it infinitely.

It was my first glimpse of a more general solution.

The Birth of a New Application

That final sheet eventually sparked an idea.

What if transaction parsing did not belong in Excel?

What if it belonged in a dedicated application?

That idea became the foundation of a transaction management system that I have already started building.

The system is not limited to weddings.

The same friction appears everywhere:

  • Wedding contributions
  • Community fundraising
  • Retail shops
  • Clothing businesses
  • Small enterprises
  • Event management

Everywhere there are transactions, there is reconciliation.

Everywhere there is reconciliation, there is friction.

And everywhere there is friction, there is an opportunity for abstraction.

The user should be able to paste a transaction message.

The system should automatically extract:

  • Amount
  • Sender
  • Reference
  • Phone number
  • Date

Then connect that information to a contributor, customer, or account.

What took minutes should take seconds.

What required attention should become automatic.

The Real Lesson

The most important thing I learned was not about Excel.

It was not about wedding funds.

It was not even about software.

It was about friction discovery.

Many opportunities are hidden inside responsibilities.

You only see them after you are forced to carry the burden yourself.

From the outside, managing wedding contributions looked simple.

From the inside, it was a distributed system involving money, identities, emotions, trust, accountability, reporting, and reconciliation.

The friction was real.

The pain was real.

And because the pain was real, the solution was valuable.

Sometimes the birth of software is not a brilliant idea.

Sometimes it is simply the moment when you become tired of doing machine work as a human and decide to teach the machine to do it instead.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *