Laravel in Melbourne
Laravel development for Melbourne companies
A Laravel development company working with Melbourne teams. Health, education and research data, where consent has a version and deletion has to actually delete.
Melbourne work skews toward health, education and research, and that changes which parts of an application are difficult. Not the screens. The obligations that reach into the data model and stay there.
The buyers here mostly have their own small engineering team, so the engagement is usually a specific gap closed inside their process rather than a project handed over.
A Melbourne consent is a Laravel record, not a flag
The question nobody is ever asked is "did this person consent". The question that actually arrives is "what did they consent to, when, and under which version of the wording".
A boolean on the user row answers none of that, and the answer cannot be reconstructed later because the old terms are no longer anywhere. So consent is a row of its own: the subject, the purpose, the version of the document, the timestamp, and how it was given. When the wording changes, a new version is published and existing consents reference the old one, because that is what was agreed.
This costs almost nothing at the start. Retrofitted, it is an exercise in inventing history, and the honest version of that exercise is admitting you cannot.
In Melbourne, deletion has to delete
A soft delete is a filter, not a deletion. The row remains, readable by anything that forgets the scope - and eventually something forgets, usually a report or an export written in a hurry.
More to the point, the row is rarely the only copy. The same personal data is in the search index, in an analytics export, in last night's backup, in a CSV somebody generated for a meeting, and in the application's own log lines if a payload was ever dumped. A deletion that handles the database and nothing else is an answer that does not survive the first real question about it.
So deletion is designed as a process with an inventory behind it: where does a copy of this exist, which of those can be purged immediately, which expire on a backup rotation, and what is the documented answer for the gap between.
The same discipline makes retention enforceable rather than aspirational. A policy that says records are kept for seven years is a cron job and a schema that can identify what is older than seven years - which means the dates have to mean something precise, and date handling is one of the decisions that is hard to undo.
Access is enforced at the data, not in the controller
In health and research there is usually an approval boundary: who may see identifiable records, under which approval, for how long.
Enforcing that in the interface is not enforcing it. The interface is not what an export script, a scheduled report or a support tool goes through, and those are exactly the paths that leak. Authorisation belongs at the data, applied by the query rather than by the controller, so that a new code path inherits it instead of having to remember it.
Working with your team
A domain team that knows what the data means plus an outside team that knows the framework covers more than either alone - as long as yours is in the reviews rather than receiving the result.
The engagement is better when it is narrow and has an end: a specific thing the team already knows is wrong and has not had a free quarter to fix.
A Melbourne audit trail somebody can actually read
Most audit implementations record every change to every column and are therefore useless, because the question people ask is never "what changed" in the abstract.
The questions are specific. Who altered this price, and when. Why does this customer's status say closed. Who exported the member list last Tuesday. Those are answerable from events that were recorded as events - a price was changed by this person for this reason - and nearly unanswerable from a table of column diffs, which records that a value moved without recording what the person thought they were doing.
So two things get built, not one. An event log of meaningful actions, named in the language of the business, which is what a screen shows a user. And, where it is genuinely needed, a change record at the column level, which is what an investigation reads. They serve different readers and conflating them produces something neither reader can use.
Reads matter as much as writes in any application holding personal information. An export is the event most worth capturing and the one most commonly missing, because exporting feels like looking rather than doing. Recording who exported what, with which filters applied and how many rows came back, costs very little and is the first thing anybody asks for after an incident.
Laravel background work your Melbourne engineers can see into
When a client's own team will run this, observability is part of the handover rather than an operational nicety. Their engineers have to be able to answer "what happened to this order" at ten at night without calling us.
That starts with jobs that are named after what they do and carry the identifiers of what they were working on, so a queue dashboard reads as a list of business operations rather than a list of class names. A job that processes an order records the order; a failure then shows which order failed, in the dashboard, without anybody decoding a payload.
Logs get a correlation identifier that follows a request into the jobs it dispatched and the jobs those dispatched in turn. Without it, tracing a multi-step process across a queue means guessing from timestamps. With it, one search returns the whole chain, which is the single highest-value thing to add to an application that does work asynchronously.
Scheduled work gets a run record - started, finished, what it processed, what it skipped. The most common silent failure in a Laravel application is a scheduled command that stopped running weeks ago and nobody noticed, because success is invisible and so is absence. A table with the last successful run of each task, and an alert when one is overdue, closes that gap permanently and takes an afternoon.
Commercially
The invoice comes from Codefacture Yazılım A.Ş., registered in Türkiye, in US dollars by bank transfer. No Turkish VAT appears on it, under the export-of-services exemption. Everything that applies nationwide rather than here is set out on the Australia market page.
