Laravel & Node

Custom application work starts with a subtraction: authentication, payments, email, storage and reporting are solved problems, and integrating them beats rebuilding them every time.

What is left is what is worth building

Usually one screen, one rule set and one scheduled job, the part of the process that is genuinely yours. That is the scope we quote, and it is why the first deliverable on a software engagement is a written buy-versus-build split rather than a proposal.

When the answer really is to build it

Most requirements that arrive described as custom software are not. They are a process that an existing tool already does, described in the language of the business rather than the language of the tool. Writing code for those is the most expensive way to get a worse result, which is why the first deliverable on this work is a written buy-versus-build split.

What genuinely needs building is the part that is specific to how this business works — the logic nobody sells, sitting between the systems that already exist.

Laravel and Node, in practice

• A buy-versus-build split written down before any code is estimated
• Integration boundaries defined first, because that is where builds overrun
• Deployment, backup and rollback treated as part of the build

See custom software development for how a build is scoped. Laravel’s documentation and the Node.js docs cover the platforms themselves.

How this work usually starts

A custom software engagement starts with the buy-versus-build split, written down and costed. Most of what arrives described as a build turns out to be a configuration, an integration, and a small amount of genuinely bespoke logic — and knowing which is which before anybody estimates is what keeps the number real.

Two documents keep a custom build honest: the buy-versus-build split, and the list of integration boundaries. Projects overrun at the seams far more often than in the logic, and both documents exist to make the seams visible before anybody commits to a date.