The first commit in Hamsayeh is a readme, made at 15:20 Tehran time on 7 February 2026. Nine more commits of documents followed that afternoon. The first code arrived at 19:10, three hours and fifty minutes after the readme.
Hamsayeh («همسایه», "neighbour" in Persian) is a building management product for residential buildings in Iran: charges, payments, tickets, governance and the accounting behind them. It is still in development. It runs with Docker Compose and demo data, and online payments use a sandbox flow. Most of the commits are mine, and a few other contributors added smaller pieces.
The case study page describes the stack. These notes cover how the thing formed, and they are written from the repository's record, with no memories added on top. Where a commit or a document states a reason, I give it. Where none is recorded, I describe the change and say so.
Ten commits of documents
Between 15:20 and 18:39 the repository gained a phased roadmap, a product strategy, personas, epics, execution guardrails, stage gates, per-phase backend and frontend plans, and a unified roadmap. So documents did come before code, by under four hours.
The strategy documents name the competition as the mix of spreadsheet, Telegram group and paper notebook that a building already uses. One principle reads "every rial must be traceable". The anti-goals rule out real-estate buying and selling. Two personas get the highest priority: a professional manager running three to five complexes, and a volunteer manager who wants proof against accusations and an easy handover to the next manager. Part 2 covers the access model that has to support that handover.
The roadmap opens with Phase 0, a research phase of four to six weeks with at least 20 manager interviews and at least 100 resident survey responses. Four to six weeks do not fit between a readme and a first code commit on the same day, and the repository holds no output from that phase. Anything that happened before the repository existed is outside what it can show, so these notes start at that first commit.
The evening of 7 February
The first code commit implemented a Phase 1 API on .NET 10 in an onion architecture. Its headline size is misleading: 856 files and 35,525 lines, of which 797 files were bin and obj build output. The source in that commit came to 59 files and 2,073 lines. Thirteen minutes later the next commit deleted all 797 build files and added the RTL admin and building portals.
A Docker Compose file with one API container and one web container landed at 19:51. PostgreSQL and Redis support came at 22:10, with SQLite kept as an option. At 22:22 the panels got their first redesign. At 22:36 a commit restored Persian labels and messages in the dashboard panels, the first of the text repairs that part 5 covers. The day ended with 21 commits.
The shape of the history
The main branch holds 1,132 commits, from 7 February to 11 October 2026.
| Month (2026) | Commits |
|---|---|
| February | 84 |
| March | 1 |
| April | 311 |
| May | 470 |
| June | 235 |
| July | 0 |
| August | 30 |
| September | 0 |
| October | 1 |
The busiest day was 4 June with 61 commits, mostly one scenario test per commit, and 19 April came next with 50. Commit count is a weak measure of work, and these messages get shorter and less informative after late May, so the evidence thins out from June on. The log contains no git revert commits, yet plenty was reversed, always by a forward commit that removed or rewrote something.
Counting files at a few commits gives a second view:
| Date | xUnit attributes | Vitest files | Backend .cs files | Frontend source files | Migration files |
|---|---|---|---|---|---|
| 12 February | 3 | 0 | 188 | 26 | 0 |
| 10 April | 118 | 0 | 636 | 86 | 3 |
| 3 May | 125 | 53 | 674 | 767 | 6 |
| 16 May | 307 | 72 | 751 | 892 | 16 |
| 4 June | 363 | 85 | 785 | 919 | 38 |
| 24 June | 392 | 86 | 860 | 963 | 52 |
| 11 October | 392 | 97 | 860 | 1,029 | 53 |
The xUnit column counts [Fact] and [Theory] attribute lines, which is lower than the number of cases that run. Backend files exclude migrations, and migration files exclude designer and snapshot files. Frontend source files are all script files under front-end/src. The front end jumped from 86 files to 767 in about three weeks, during the re-architecture that part 6 covers. The xUnit count rose by 180 in one day on 16 May, when the accounting tests landed. These columns show size and say nothing about quality.
Where the months went
The rest of February was architecture churn and first-pass features: 63 commits, with an audit database, admin CRUD and the finance epics among them. April opened with 120 commits in nine days, closing gaps in governance, reservations, documents, tickets and identity, and that stretch ended with PostgreSQL schemas and the split into two API hosts.
From 15 April to 8 May the work centred on the front end: 323 commits covering a React Query migration, layer boundaries across 360 files, and a move to TypeScript that renamed 693 files in one commit. The backend had its turn from 9 to 16 May, with 81 commits that grouped persistence by schema and created the accounting projects. The second half of May, 257 commits, went to onboarding, portal redesigns and a first Android project. June's 235 commits narrowed to small-building work, including 48 scenario specs in one day and more finance depth such as expense control, opening balances and due dates.
August brought a two-day design system pass of 27 non-merge commits, and the single October commit is a visual pass over 44 files on the landing, authentication and dashboard screens. Sorted by the first word of the message, the log has 245 commits starting with feat, 187 with refactor, 151 with add and 83 with fix.
What happened to the roadmap
The roadmap estimated 6 to 12 weeks for each of Phases 1 to 4. The commits carrying those labels landed days apart: the finance epics all on 23 February, the Phase 3 service modules on 26 February, Phase 4 governance and assets on 27 February. The labels ran ahead of the code. A gap list added on 5 April still had late-penalty execution, ticket comment threads and SLA workflow actions open, and another commit that day replaced asset and document mocks with real API flows.
| Phase | Title | Status in the repository |
|---|---|---|
| 0 | Discovery | No output in the repository |
| 1 | Foundation MVP | Implemented |
| 2 | Finance and control | Implemented |
| 3 | Service and engagement | Implemented |
| 4 | Governance and assets | Implemented |
| 5 | Growth | Partly; subscriptions removed on 25 May |
| 5 extra | Onboarding and growth readiness | Added in May; wizard and Excel import done later, other items listed as missing at the time |
| 6 | Smart building | Plan only |
| 7 | Professional manager network | Plan only |
Implemented means the code exists in a product that is still in development. The documents also define stage gates between phases, a scope freeze before each release candidate, and KPIs per phase, all written as if for a company. The repository holds no KPI data, and as far as the history shows, work did not wait on those gates.
The Phase 5 document listed two relevant items as out of scope: full multilingual support, and a fundamental architecture redesign during growth. Both happened anyway, in May. Another contributor added English and LTR support, and the backend was split into modules, which part 4 covers.
Several large changes have no recorded reason. Subscription management was removed on 25 May: 74 files deleted, 4,195 lines removed, tables dropped, and the readme still mentions it. On 3 June a new backlog and a scenario document turned to an 8-unit building with one manager, while the strategy had aimed first at larger buildings. The documents describe the small building without explaining the move.
The architecture style also changed three times in 16 days: onion with repositories on 8 February, Clean Architecture with MediatR on 12 February, and a DDD restructuring on 23 February. Only the middle one records a motive, in its message: "Split monolithic services (~2400 lines) into 50+ focused MediatR handlers".
Smaller reversals run through the same months. On 9 April, 19 migration files were replaced by one, in a commit that removed about 30,000 lines; part 4 covers that. An onboarding draft that lived in browser storage moved to the server on 20 May, which part 3 covers. On 16 June a commit added installment plan CRUD and another titled "remove installment plan" followed the same day, although the feature folder is still there. That last change has no recorded reason either.
The solution today
The backend has 11 projects:
back-end/src Hamsayeh.Api.Admin Hamsayeh.Api.User Hamsayeh.Api.Shared Hamsayeh.Domain Hamsayeh.Application Hamsayeh.Infrastructure Hamsayeh.Accounting.Domain Hamsayeh.Accounting.Application Hamsayeh.Accounting.Infrastructure back-end/tests Hamsayeh.Application.Tests Hamsayeh.Api.Tests
There was a single API project until 10 April, then two hosts with shared plumbing. A twelfth project, Hamsayeh.Accounting.Contracts, was created on 16 May and deleted as unused on 21 May. Of the 860 .cs files outside migrations, 494 are in Hamsayeh.Application. Infrastructure has 111, Domain 92, the two API hosts 46 between them, and the three accounting projects 105.
That layout makes accounting look more separate than it is. Its domain and persistence have their own projects, but most accounting commands and handlers still live in Hamsayeh.Application/Features: Charges has 28 files, PenaltyRules 18, Funds 15, InstallmentPlans 14 and Payments 13. Hamsayeh.Accounting.Application holds abstractions and ledger postings. As far as the code shows, the boundary is firm for domain and persistence and softer for use cases.
Part 2 takes one early assumption from this history, that a person has a single role, and follows what it took to replace it.
This note is also available in Persian: read the Persian version.