Laravel development for Glasgow councils and housing associations

Glasgow's public service systems have a problem that commercial software rarely faces at the same severity: the data is older than every system that has ever held it.

A housing association's records go back decades, through two or three platform migrations, a merger, a reorganisation and a period when things were kept on paper. The same person appears several times under variations of their name, at addresses that have since been renumbered, with a tenancy that was transferred and a repair history attached to the wrong record. None of that is anybody's fault and all of it is now the application's problem.

Deciding that two Glasgow records are one person

This is the central task, and the instinct - find the duplicates and delete the extras - destroys exactly the history the organisation needs.

The arrangement that works introduces a person record that the existing records point at. Every tenancy, payment and repair stays attached to the record it was created against, so nothing in the past changes, while reports and screens resolve through to the person. A merge is then a statement rather than a deletion, and crucially it is reversible, because some merges are wrong and the discovery usually comes months later.

Matching itself should produce a score, not a verdict. An exact match on a strong identifier can be automatic. A near match on name, date of birth and address gets proposed to somebody who knows the tenants. Automatic merging at a confidence threshold sounds efficient and produces the single worst outcome in a housing system - two tenancies on one record, a rent account that cannot be reconciled, and a letter sent to the wrong person about an eviction.

A Glasgow case is measured in months

The second structural difference is lifespan. A repair, an application or a tenancy dispute can remain open for a year, and that changes what the data is for.

When a case lives a long time, its current status is the least informative thing about it. Every question that gets asked later is about elapsed time and sequence. How long before anybody attended. How many times was it reassigned. When was the tenant last contacted, and by whom. Was the delay ours or the contractor's.

A single status column answers none of those. A transitions table - from, to, when, who, why - answers all of them, with the current status derived from the most recent row rather than maintained separately where the two can disagree. It is slightly more work to write and it is the difference between a system that can account for itself and one that can only describe the present.

Laravel batch runs that affect real people

Rent charges, arrears calculations, notice generation - these run in bulk and their output goes to people in letters.

Two properties matter more here than in commercial batch work. It has to be possible to run the calculation without committing it, so somebody can look at the result before four thousand letters exist. And it has to be possible to say, for any one of those letters, which inputs produced it - which means the figures are stored with the run rather than recalculated when somebody queries it.

That is the same reasoning as everywhere else on this page: the system's job is not only to be right but to be able to show why. Being safe to run twice is part of it, because a charge applied twice is a complaint and a refund.

A Glasgow housing repair is an appointment and an obligation

A repair has two clocks running on it and they are not the same clock.

One is the appointment - a contractor arrives on Thursday afternoon. The other is the statutory obligation, which says a repair of this category is completed within a set number of working days or it is reportable. Systems that model only the appointment report cheerfully on attendance while quietly failing the obligation, because attendance is not completion.

The obligation clock also pauses, and the pause rules are where the modelling work is. No access on arrival pauses it. A part on order pauses it, if the policy says so. A tenant who cancels pauses it; a contractor who cancels does not. Each of those is a recorded event with a reason code, and the elapsed time is derived from the event sequence rather than stored as a number that somebody has to remember to update.

Getting that right has a consequence worth naming. Once elapsed time is derived, the question "how many repairs are currently out of target" has one answer that the system can compute, rather than four answers from four spreadsheets. That question is asked by a regulator, and the organisation either has one answer or it has a problem.

What a Glasgow committee needs out of the Laravel data

Reporting to a committee is not the same job as reporting to a manager, and the difference is that a committee report has to agree with the last one.

A live query does not do that. Run it again next quarter and the figure for last quarter has moved, because cases were reclassified, duplicates were merged, and a record was backdated. All of those changes are correct. The report is still wrong, because it now contradicts a document that was formally received.

So the figure is stored. A reporting period closes, the numbers for that period are computed once and written to their own table with the date and the code version that produced them, and the report is rendered from that table afterwards. A restatement is a new row that says what changed and why, not an overwrite.

This is unglamorous and it removes an entire category of argument. When somebody asks why the figure differs from the one in the minutes, the answer is a row with a reason on it rather than a developer re-running a query and hoping.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - UK data protection, procurement, invoicing in pounds - is on the United Kingdom market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in pounds by bank transfer, with no Turkish VAT under the export-of-services exemption.