Stuff we built ourselves

What it does

If you speak for a living, you know the drill. Hours go into digging up events, then you paste the same bio into form after form. Digital Speaker Agent does the digging for you, fills in the forms, and keeps every submission in one list so nothing slips.

What was hard

No two event sites use the same form. The agent had to cope with all of them, so part of it lives in a Chrome extension that works right on the page, with our backend running alongside. The forms live in the browser, so the agent has to live there too.

What it does

A diner scans the code on their table and orders from as many stalls as they like, all in one go. Each counter gets only its own tickets on its own panel and never sees anyone else's orders. The food court operator sees the whole day in a single settlement.

What was hard

Payments, honestly. Stall owners can't agree on them. Some want the money before they start cooking. Others have taken cash at the window for fifteen years and aren't about to stop. So we let each stall decide: pay while ordering, pay at the counter, or let the diner choose. The diner's cart simply follows whatever that counter picked. Every ticket arrives either marked PAID or with the exact amount to collect at handover.

What it does

Channel partners check what's available on their phone and hold a unit for a fixed window. The sales office watches every hold count down on one board. The developer sees absorption, realisation per sq ft, and which partner is really selling. No more five versions of the same Excel sheet.

What was hard

Holds that run out. Say a partner locks a unit for 24 hours and it doesn't convert. The unit frees itself and goes back to every partner at the same moment. Nobody has to remember to release it, and two brokers can never be promised the same flat. We also lock attribution when the hold is placed, not at booking. That one choice settles most commission arguments before they start.

What it does

A coaching institute could not answer a simple question without opening three files: who has paid and who has not. Fees were in one place, attendance in a register, marks in a third book, and the only person who knew where everything lived was the one at the front desk.

So the whole thing got rebuilt as one system with three roles.

The office sees every student on record, fees tracked per subject rather than per student, exams and results, the timetable, and the money moving both directions, fee collection set against rent, electricity, printing and staff salaries.

A teacher logs in and sees only their own batches. They take attendance for a class, set assignments for it, and check their own payment record. They cannot open another teacher's batch or anybody's fees.

A student opens one page and knows where they stand: attendance, upcoming exams, performance across tests, results paper by paper, and what is still to pay, instalment by instalment.

What was hard

Role separation that holds all the way down to the query. It is easy to hide a menu item and call it access control. Every list in the teacher and student portals is filtered at the data layer by who is asking, so a teacher pulling the attendance screen only ever receives their own batch, and a student only ever receives their own results and their own fee ledger.

The second thing was where the data lives. Before this, parent phone numbers, fee status and marks sat in WhatsApp groups and on one person's laptop. Now it is one database the institute owns, and when a staff member leaves you remove a login instead of chasing a phone.