Custom Software Development with Laravel

A business application is mostly not about the business.

Count the code in any system of this kind and the part that encodes how your company actually works is a minority of it. The rest is the apparatus every such application needs before it can do anything useful at all - and that distinction is the most useful thing to understand before commissioning one, because it is where budgets are won and lost.

The twenty per cent that is actually yours

The valuable part of a custom build is the part a product could never have given you: your pricing rules, your approval chain, the way a job moves from quoted to scheduled to invoiced, the exception that applies to one customer for reasons that go back a decade.

That is where the thinking should go, and in a badly-run build it is where the thinking runs out, because the budget was consumed getting the plumbing to work.

So the question worth asking a supplier is not which framework they use. It is what proportion of the estimate is spent on things that are identical in every application they have ever built.

What a Laravel business application needs before it does anything useful

The list is longer than most people expect and none of it is negotiable.

Somebody has to log in, and somebody has to be able to reset a password without a developer. Different people have to see different things, enforced somewhere better than a hidden menu item - authorisation is not authentication, and the difference shows the first time an export reaches records its operator should not see.

Work has to happen outside a web request. A document to generate, an email to send, a nightly import, a figure to recalculate. That means a queue, which means retries, which means jobs that are safe to run twice - and a queue built casually is how a customer receives the same invoice three times.

The schema has to have a history rather than a current state, so a change can be reviewed and rolled forward on another environment. Files have to be accepted from people outside the organisation without that becoming a security incident. And there has to be a test suite covering the paths where money and state change, or nobody will dare touch the system in year two.

Laravel supplies all of that as standard, at a quality most teams would not reach writing it themselves, and - importantly - in a shape the next developer will recognise. A bespoke framework invented four years ago by somebody who has since left is the most expensive form of custom software in existence.

Integration is usually the real scope

The part of these projects that overruns is almost never the screens.

It is that the application has to agree with an accounting system, an ERP, a payment provider, a courier, a CRM and a spreadsheet, none of which were designed to agree with anything. The engineering of talking to them is straightforward. The decisions are not.

Which system owns a customer's name, and what happens when it changes on the other side. Who assigns the invoice number. What a credit note does on both sides. How a part payment is applied. What happens when one system is down and the other has already committed.

Those are commercial decisions that look technical, and they are settled with your finance and operations people rather than estimated by us. Work of that kind is set out under integration engineering; on a custom build it is frequently half the project, and a plan that treats it as a line item at the end is a plan that slips.

How an engagement runs on a custom Laravel build

In phases, each ending with something deployed that people can actually use.

The opening phase takes one workflow from beginning to end - not the outline of five - because that is what forces the schema to meet real data. It is also what produces an estimate for the remainder that is worth anything, which a number given in week one is not.

Each phase is scoped in writing before it starts. Where you have engineers, they are in the pull requests from the first week; that is how conventions transfer, and it is the only arrangement in which the system is still maintainable after we stop working on it.

Migration of existing data runs alongside rather than at the end. The new system is reconciled against the old one, record by record, until they agree - disagreements are findings rather than bugs, and there are always more of them than anybody predicted.

What you receive from a custom Laravel build

At the close of each phase, a running application on infrastructure you control.

Alongside it: the repository and its full history, with a build and deploy that have no dependency on us. Migrations rather than a database dump. A written description of the data model, each constraint and what it prevents - because a constraint nobody can explain is one a future developer will delete. Tests over the paths that move money or change state. And the integration decisions recorded, including the ones we argued about, since those are what a new developer needs and what a handover document always omits.

Where buying beats building

This answer is sometimes no, and it is cheaper to hear now.

If a product does most of it and the gap is taste rather than process, buy the product and configure it. The honest comparison is five years against five years, not year one against year one, and configuration keeps winning on the longer view more often than people expect.

If the process is still being invented, a build will set in concrete a decision nobody has made. Keep it manual until the shape stops moving.

If the volume is low enough that the manual version costs an hour a week, automating it is a hobby rather than an investment.

And if nobody inside the business is better off when it works - no individual whose job gets easier - it will be abandoned no matter how good it is. That is the failure we have seen most often, and it is never a technical one.