Electrical engineer and construction project manager in Halifax, Nova Scotia π¨π¦
I write Python and TypeScript to take the grunt work out of estimating, and I'm studying blockchain because I think it can fix how construction gets paid.
π alimazloum.com Β· π¦ @AliMazloum3
- Estimating and takeoff automation β CLIs and web apps that turn drawings and specs into quantities, costs and labour hours faster than a spreadsheet can.
- Change management as one flow β Change Ledger: RFI β CCN β subtrade pricing β estimate β CO β forecast, starting from the joins existing tools handle badly.
- Blockchain for construction β progress payments, holdback release and change orders still run on paper trust. I'm learning smart contracts to see how much of that can become code.
- Learning by building β the wallet tracker, the educational blockchain and the test token below are deliberate steps: understand wallets, then chains, then tokens, before designing anything for a job site.
- AI-assisted engineering β agent workflows and skills that speed up estimating and document review.
The problem is trust, not software. In construction, money flows from owner to contractor to subtrade to supplier, and every hand it passes through holds it a little longer. Prompt-payment laws now say when money must move. Nothing enforces them except lawyers.
Existing tools can't fix this, because one party owns them. The contractor who runs the software is also the one holding the money. A record only one side can audit is a promise, not a record.
That is the one thing a blockchain does well. A shared ledger that the owner, the contractor, the sub and the surety all read from, and none of them can quietly edit, with rules that run themselves:
- Work is certified, and the payment releases. No chasing.
- Holdback is calculated and released by the rule, not by memory or leverage.
- Change orders and back-charges are stamped where nobody can rewrite them.
I know where the line is. Someone still has to walk the site and certify the work. That stays human. Subs want dollars, not tokens. Lien law can't be contracted out. So the design is a hybrid: the chain keeps the record and triggers the payment, and the bank moves the money.
Why me. I'm the person who signs the payment certificate. I know which parts are judgment and which are arithmetic, and the arithmetic is the part worth turning into code.
The plan, tracked on my Open Source Roadmap: records first with no money, then escrow on a testnet, then one pilot with one subtrade. The repos below are the groundwork: wallets, then a chain, then a token.
Change Ledger is the day job problem. The three below it are rungs on the ladder toward construction payments on-chain.
| Project | What it is | Stack |
|---|---|---|
| change-ledger | Construction change management as one Change Event flow, from RFI to revised contract and forecast. Spec first, code next | Spec / Python |
| wallet-tracker-bot | Step 1, wallets: Telegram bot that tracks BTC, ETH, BSC and SOL balances and generates BIP39 multi-chain wallets | Python |
| TinyCoin | Step 2, chains: educational blockchain with proof-of-work mining, ECDSA signing, transaction validation and consensus | Python |
| tigercoin-token-list | Step 3, tokens: token-list infrastructure for a test token on Base, served via GitHub Pages | JSON / Pages |

