✳Project snapshot
Product Designer and Product Builder
DiscoveryField researchWorkflow designPrototypingUX and UIProduct strategy
Excel MVP to Windows desktop application
AS-HAL V1 launched 2021In use as of 2026
From one Excel file to twelve generator businesses.
The case study answers three questions: what operational problem did AS-HAL solve? How did research and prototype testing shape the product? And did the solution change the work enough to sustain adoption?
80%
Faster invoice and receipt preparation in the original 400-subscriber prototype after two real billing cycles.
documented
12
Generator businesses adopted AS-HAL V1, primarily in Beirut and surrounding suburbs.
reported
2021
to 2026
The product remained embedded in recurring monthly work.
behavioral
A paper process inherited with the business.
A generator owner had unexpectedly inherited his father's business. He also inherited a paper process with no structured accounting system.
Monthly dues were first written on small pieces of paper and then transferred one by one into standard receipt books. Every copy created another opportunity for an amount, name, or status to change or disappear.
The owner asked me to make the work manageable. That request became the starting point for AS-HAL.
Paper records before AS-HAL
Receipt preparation was visible. The deeper problem was not.
Keeping each subscriber, invoice, payment, and outstanding balance connected from one month to the next was the harder challenge.
Validate subscriptions
Set monthly pricing
Calculate bills
Print receipts
Distribute receipts
Collect payments
Reconcile amounts
2 min
Approximate time to calculate one bill and prepare one handwritten receipt.
observed estimate
13+ hrs
Receipt preparation alone for 400 subscribers, excluding distribution, collection, and reconciliation.
calculated estimate
How might we preserve the relationship between a subscriber, what they should pay, what was invoiced, what was collected, and what remains outstanding?
Three owners, about 2,000 subscribers, one full working day in the field.
I interviewed three generator owners managing about 2,000 subscribers combined, spent a full working day with operators, and shadowed the invoicing-to-collection workflow.
What I found
Most businesses relied on handwriting or spreadsheets; a minority used an accountant.
Generic accounting systems were too broad and complex for these small operators.
Most owners used smartphones, but fewer than roughly 10 percent owned or regularly used a computer for work.
Available computers were often old and ran outdated software.
Operators resisted cloud storage and wanted business data kept locally.
The physical system behind the business
The least software complexity that could still control a complicated operation.
These constraints ruled out a generic accounting interface. AS-HAL had to match the sequence, language, and exceptions operators already used in their monthly work.
Low computer literacy
Familiar business terms and visible task-based navigation.
Older hardware and software
Lightweight Windows desktop application.
Resistance to cloud storage
Locally installed operational data.
Multiple billing models
Explicit Metered, AMP, and Flat Price subscription types.
Paper-based collection
Connected receipt printing, collection, and outstanding balances.
A six-sheet Excel system to test business rules, not preview the interface.
I built a six-sheet Excel system with formulas, macros, and VBA. The prototype linked subscriber records, changing monthly rates, receipt generation, collection status, expenses, profit and loss, reconciliation, and reporting. It gave us a fast way to ask a practical question: does this operating model hold up when real customers, exceptions, and payments interact?
400 real customers. Operators working normally. Me shadowing end to end.
The first owner used the prototype with about 400 real customers. Operators completed their normal work while explaining decisions and exceptions, and I shadowed the sequence from start to finish.
Testing showed why invoice automation alone was insufficient. The product needed to preserve the relationship between subscriber, pricing, bill, printed receipt, collected amount, forgiven amount, outstanding balance, and history.
80%
Reduction in invoice and receipt preparation time observed with the original 400-subscriber prototype.
documented
Low-fidelity wireframes first. Then a locally installed Windows application.
I used low-fidelity wireframes to explore hierarchy, navigation, and content modules before the interface was implemented as a locally installed Windows application.
The shipped interface used a functional, control-led Windows style because the product was built in C# for local installation. The goal was dependable performance and compatibility with the older computers found during research, while keeping controls familiar to users with limited desktop software experience.
C# did not dictate the appearance by itself. We chose standard Windows patterns and a restrained visual layer so implementation effort could stay focused on billing rules, validation, receipt printing, collection, and reconciliation.
Work organized around recognizable operator tasks.
Three subscription models
Metered
Subscription plus consumption calculated from meter readings.
AMP
Fixed subscription based on the number of amperes purchased.
Flat Price
Negotiated fixed monthly amount.
Rules the system had to preserve
Individuals, organizations, and shared services such as elevators.
Monthly pricing changes and seasonal AMP changes.
Shared bills with several payers whose percentages must total 100 percent.
Prepaid subscribers, discounts, offline lines, and forgiven amounts.
Receipt dependencies, collection status, and historical customer activity.
Five screens that covered the full monthly cycle.
Client Overview
Subscriber status made visible
The first operational view combined subscriber identity, subscription characteristics, and outstanding amounts. Operators could search, add, edit, deactivate, and retrieve customers without navigating ledgers.
The underlying model also supported Individual, Organization, and Shared clients, including payer relationships for shared services.
Pricing and Invoicing
A controlled start to every billing cycle
Clients could not be invoiced until the operator set the month's AMP price, energy rate, subscription prices, and exchange rate. Once required values were valid, AS-HAL could invoice eligible AMP and Flat Price clients automatically; metered subscribers still required a current reading.
This moved repeated arithmetic into reusable rules while preserving operator control. Editing a saved monthly price triggered reinvoicing for that month's clients, keeping calculations consistent.
Collection
Stayed connected to the bill
Only clients with a printed receipt appeared in Collection. The operator entered the full amount received, while AS-HAL calculated the relationship between bill, collection, forgiven amount, and outstanding balance.
The system prevented collection above the bill amount and supported a controlled forgiven balance. This directly addressed the paper process in which invoices, receipts, and returned collection amounts were easily separated.
Client History
The monthly record, preserved
Structured transactions remained available after the monthly cycle ended. Operators could retrieve a subscriber's subscription, bill, dependent bill, and collection history by reference number.
Summary
Records turned into oversight
Information that previously disappeared into receipt books could now support follow-up, reconciliation, and operational decisions.
Automation saved time. Connected records made the operation controllable.
The documented early result is an 80 percent reduction in invoice and receipt preparation time. Additional figures below are directional internal estimates based on observation and customer feedback, not instrumented analytics.
~85%
Fewer operational mistakes.
directional internal estimate
~90%
Improvement in reconciliation and identifying unpaid subscribers.
directional internal estimate
Correct information entered once, flowing consistently through the cycle.
Before AS-HAL, mistakes could enter repeatedly at subscription, calculation, handwriting, copying, collection, and reconciliation.
With AS-HAL, correct subscriber and pricing information could flow consistently through the rest of the cycle. The product did not remove every mistake. It concentrated risk near the point of entry, where operators could detect and correct it before it propagated.
Input
Invoice
Receipt
Collection
History
Error risk concentrated at input
Why this mattered
One corrected record could update the downstream workflow.
Invoices and collections remained attached to the same subscriber.
Outstanding balances no longer depended on reconstructing a paper trail.
AS-HAL V1 launched in 2021. As of 2026, it remains in use.
Customers continued paying, requested additional functionality, incorporated AS-HAL into monthly operations, and did not return to their previous manual workflows. For a product supporting a recurring monthly cycle, sustained use is the clearest validation that the workflow created durable value.
400–600
Subscribers managed by most adopting businesses.
reported
~1,500
Subscribers managed by the largest operator.
reported
2
New customers generated directly by existing users.
reported
How product design can begin with a working model of a business system.
AS-HAL shows how product design can begin with a working model of a business system, then earn the right to become software through observation and measured operational value.
My contribution
Framed the problem around the full invoicing and collection cycle.
Conducted field research and contextual workflow observation.
Built and tested the Excel MVP with real subscribers.
Translated domain rules into product structure and interaction logic.
Designed the desktop experience around low computer literacy, old hardware, and local storage requirements.
The lasting product lesson
The strongest design decision was to keep the product close to the operators' existing mental model while making the underlying information reliable. Automation saved time, but connected records made the operation controllable.
The remaining case-study gap is the placeholder for two or three specific observed X to changed Y stories that explain how individual interface decisions evolved during testing.