Larasoft Insights

Taking a vibe-coded app to production: a 25-point checklist

2026-10-24T00:00:00Z

AI app builders and coding agents have made it possible to go from an idea to a working app in a weekend. That is a real change, and a good one: founders can now test ideas with real users before spending serious money.

The trouble is that "working" and "ready for customers" are not the same thing. AI tools are very good at producing code that does what you asked for in the demo. They are much less reliable at the things nobody asked for, such as stopping one customer reading another customer's invoices.

This is the checklist we use as the starting point for our vibe code reviews. Work through it before you launch, or before you start charging.

Security

These are the issues that can end a young business, so start here.

Every request checks who is asking. Open your app in a private window and try visiting a page you should only see when logged in. Then try the same with the API endpoints your front end calls.
Every record checks who owns it. Log in as one user, copy the URL of one of their records, then log in as a second user and paste it. If you can see the first user's data, you have an authorisation problem. This is the single most common serious issue we find.
No secrets in the browser. API keys for your database, payment provider or AI service must live on the server. Search your front-end code for strings like sk_, key and secret.
Database rules are switched on. If your app talks to a hosted database such as Supabase or Firebase directly from the browser, row-level security or equivalent rules must be enabled and tested.
Passwords and sessions are handled by a proven library. Hand-rolled login code is a red flag.
File uploads are restricted. Check file types and sizes on the server, and store uploads outside the public web folder.
Dependencies are real and current. AI tools sometimes suggest packages that do not exist, or very old versions of ones that do. Run your package manager's audit command and check anything unfamiliar.

Data

Backups run automatically, and you have restored one. A backup you have never restored is a hope, not a backup.
Personal data is mapped. Know what personal data you collect, where it is stored and who can access it. Under UK GDPR you need a lawful basis for each type and a privacy notice that explains it.
Deleting means deleting. When a customer closes their account, their data should go with it, or be anonymised.
Production data stays in production. Developers and AI tools should work with test data, not copies of real customer records.

Payments

Payment results are confirmed on the server. Never trust the browser to say a payment succeeded. Use your payment provider's webhooks.
Webhooks are verified. Check the signature on every webhook so nobody can fake a "payment succeeded" message.
Failed payments are handled. Decide what happens when a card is declined at renewal, and test it.
Prices live on the server. If the price is sent from the browser, someone will change it.

Reliability

Errors are tracked. Install an error tracking service so you hear about problems before your customers tell you.
Uptime is monitored. A simple external check that alerts you when the site goes down.
Slow work happens in the background. Sending emails, calling AI models and processing files should run in a queue, not while the user waits.
There is a staging environment. Somewhere to try changes before they reach customers.
Deploys are repeatable. You should be able to deploy with one command or one click, and roll back just as easily.

Maintainability

The code is in Git, in an account you own. Not only in the AI tool's workspace.
There are tests for the paths that make money. Sign-up, login, checkout and the core feature, at minimum.
The structure is consistent. AI tools often solve the same problem three different ways in one codebase. That makes every future change slower and riskier.
Someone can explain how it works. If the only explanation is "the AI wrote it", plan time to document it.
You know which parts are fragile. Every codebase has them. The danger is not knowing where they are.

What to do with the results

If you can tick most of these, you are in better shape than many funded startups. If you cannot, do not panic. Most of these problems are quick to fix once you know they are there, and fixing them before launch is far cheaper than after a breach or a lost customer.

There are three common routes from here:

Fix it yourself, using this list, if you or your team are comfortable with the code.
Get an independent review. Our vibe code review costs a fixed £395 and gives you a ranked list of what to fix, with the critical issues explained in plain English.
Rebuild the core properly, using the prototype as a detailed specification. For some apps this is the cheaper option, and our MVP development service is designed for it.

Whichever you choose, keep using AI tools. They are not the problem. The problem is shipping code that nobody with the right experience has checked. Our guide to AI-driven development guardrails explains how to keep the speed without the risk.

AI-driven development without the mess: the guardrails we use

2026-10-24T00:00:00Z

We use AI coding agents on almost every project now. They write code, tests, migrations and documentation, investigate bugs and do the repetitive parts of upgrades. Used well, they let a small senior team deliver what used to take a much larger one.

Used badly, they produce codebases that work for a while and then become impossible to change. We see the results in our rescue and vibe code review work every week.

The difference is not which tool you use. It is the guardrails around it. These are the ones we use on client projects.

1. Make the codebase easy for an agent to understand

AI agents copy what they see. If a codebase has three different ways of doing validation, an agent will happily add a fourth. So before we scale up AI-assisted work on an existing app, we spend time on consistency:

One way to validate input (Laravel form requests).
One way to authorise actions (policies).
One place for business logic (action or service classes, not controllers).
Clear naming that matches Laravel conventions.

This pays off for human developers too, but it matters even more for agents.

2. Write the rules down

Most AI coding tools read a project instructions file, such as CLAUDE.md or AGENTS.md, before they start work. We keep one in every repository. It covers:

the commands to run tests, static analysis and code style checks,
the architecture and where different kinds of code belong,
conventions the agent must follow, such as "every new endpoint needs a policy and a feature test",
things it must never do, such as editing old migrations or adding packages without asking.

A good instructions file is short, specific and kept up to date. It is the cheapest quality improvement you can make.

3. Keep tasks small

Agents are at their best on tasks a person could review in a few minutes. "Add a CSV export to the orders page, with a test" works well. "Build the reporting module" does not.

Small tasks are easier to describe precisely, easier for the agent to get right and, most importantly, easier for an engineer to review properly. A 2,000-line pull request will not be reviewed carefully, whoever wrote it.

4. Tests first, or at least tests always

The best way to tell an agent what you want is often a failing test. The best way to check its work is a passing one. Every change we accept from an agent includes tests, and the full suite must pass before review.

For older codebases with few tests, our first job is usually to add tests around the most important behaviour. That makes every later change, by person or agent, safer.

5. Let the machines check the machines

Automated checks catch a surprising share of agent mistakes before a person ever looks:

Static analysis with Larastan finds type errors, missing methods and dead code.
Code style with Laravel Pint keeps formatting consistent, so reviews focus on substance.
Dependency audits with composer audit and npm audit flag vulnerable or suspicious packages.
CI runs all of the above on every pull request.

If the checks fail, the agent fixes them before anyone reviews the change.

6. A senior engineer owns every change

This is the rule that matters most. An agent can write a change, but a named engineer reviews it, understands it and is accountable for it. Reviews focus on what tools cannot check well:

Does it do the right thing? Not just what the ticket literally said.
Is it secure? Authorisation, data exposure and input handling in particular.
Does it fit? Is it consistent with the rest of the codebase, or a new pattern in disguise?
Will it scale? Query counts, memory use and behaviour with real data volumes.

If an engineer cannot explain a change, it does not ship.

7. Protect production and personal data

Agents work in development environments with test data. They do not get production database access, production secrets or real customer data. Where we use AI services for analysis or code generation, we check that the provider's terms fit the client's data protection obligations.

What this means for cost and speed

These guardrails take some effort to set up, but they are what make AI-assisted development cheaper over time, not just faster in the first week. A consistent, tested codebase lets agents do more of the work safely, which is how we keep our rates at £20 to £25 per hour while every change still gets senior review.

If you want to adopt AI-driven development in your own team, or want us to work this way on your project, see our AI-driven development service. If you already have an AI-built app and are worried about what is in it, start with our production checklist for vibe-coded apps.

Adding AI features to a Laravel app: a practical guide

2026-10-24T00:00:00Z

Most businesses we speak to want "AI in the product", but are not sure what that should mean. The good news is that the most valuable AI features are usually the least glamorous. They take a slow, repetitive task that a person already does and make it quicker.

This guide covers where AI features earn their keep in a Laravel application, how to build them so they are reliable, and the mistakes we see most often.

Where AI features actually help

The best candidates share three traits: the task is repetitive, the input is mostly text or documents, and a person can easily check the result.

Summaries. A long customer history, support thread or set of notes condensed into a few lines for the person about to call the customer.
Classification. Tagging support tickets, routing enquiries, flagging risky content or categorising transactions.
Extraction. Pulling names, dates, amounts and line items out of uploaded documents, emails or PDFs.
Drafting. First drafts of replies, descriptions or reports that a person edits and approves.
Search. Finding records by meaning rather than exact words, using embeddings and vector search.

A general-purpose chatbot is rarely the right first project. It is hard to make reliable, hard to measure and easy for users to push in directions you did not plan for.

Treat the model like any other API

From your application's point of view, an AI model is a third-party API that is slow, costs money per call and sometimes fails or returns something unexpected. Laravel already has good tools for that kind of service.

Use queues. Model calls can take several seconds. Run them in a queued job so the user is not left waiting, and update the page when the result is ready.

SummariseCustomerHistory::dispatch($customer);

Retry sensibly. Use the job's retry and back-off settings to handle rate limits and temporary errors without manual work.

Log every call. Record the prompt version, model, token counts, cost and outcome. When a user reports a strange result, you will want to see exactly what happened.

Use a package rather than raw HTTP calls. Laravel 13 introduced a first-party AI SDK, and community packages such as Prism give a consistent interface across providers. Either makes it easier to switch models later.

Ask for structure, then validate it

Free text is hard to use in code. Ask the model to return JSON that matches a schema you define, such as a category, a confidence score and a short reason. Most providers now support structured output directly.

Then validate the response exactly as you would validate user input. Check the category is one you recognise and the numbers are in range. If validation fails, retry or fall back to a person.

Keep a person in the loop

For anything that affects customers, money or legal obligations, the AI suggests and a person decides. In practice that means:

drafts that must be approved before sending,
suggested categories that a person can change,
extracted data shown for review before it is saved.

This is not only about safety. It also gives you a steady stream of corrections, which show you where the feature works and where it needs better prompts or examples.

Control the cost

AI costs are easy to ignore in development and surprising in production. From the first day:

record the cost of every call against the feature and the customer account,
set limits per account, especially on free plans,
cache results where the same input is likely to come up again, and
use smaller, cheaper models for simple tasks such as classification.

Protect personal data

Before sending customer data to a model, check the provider's terms on data retention and training, and whether processing happens in a region that suits your obligations under UK GDPR. Send only the fields the task needs. For some tasks you can strip or replace names and contact details before the call and add them back afterwards.

Update your privacy notice to explain how AI processing is used.

Measure whether it works

Decide how you will judge the feature before you build it. Useful measures include how often people accept a suggestion without changes, how much time a task now takes and how many results are corrected. Keep a small set of real examples with known good answers, and run them whenever you change a prompt or a model.

Getting started

A good first AI feature can often be built and in front of users within a few weeks. If you would like help choosing the right one and building it properly, see our Laravel AI integration service, or book a free call to talk it through.

Laravel security checklist for 2026

2026-10-24T00:00:00Z

Laravel gives you a secure starting point. It protects against cross-site request forgery, escapes output in Blade templates, uses prepared statements for database queries and hashes passwords properly. Most Laravel applications that get breached are not let down by the framework. They are let down by something the application itself does, or forgets to do.

This is the checklist we start from in our security reviews. It is not exhaustive, but if you can tick every item you will have closed the gaps we find most often.

Versions and patching

Laravel is on a supported version. As of October 2026, Laravel 13 is fully supported and Laravel 12 receives security fixes until 24 February 2027. Laravel 11 and older no longer receive security fixes. See our version support tracker.
PHP is on a supported version. PHP 8.1 is out of support, and PHP 8.2 reaches the end of security support on 31 December 2026.
Dependencies are audited. Run composer audit and npm audit regularly, and in CI. Our guide to patching Laravel dependencies explains a routine that works.

Authentication

Use a first-party starter kit or package for login, registration and password resets rather than custom code.
Rate-limit login and password reset routes. Laravel's rate limiter makes this a few lines of code.
Offer or require two-factor authentication for admin accounts and anyone with access to sensitive data.
Expire sessions sensibly, and invalidate other sessions when a password changes.

Authorisation

This is where we find the most serious issues.

Every action checks permission, not just login. Use policies and call them in controllers, form requests or Livewire components. Being logged in is not the same as being allowed.
Every query is scoped to the right owner. In multi-tenant apps, a user should never be able to load another tenant's record by changing an ID in the URL.
Admin routes are protected by both authentication and an explicit role or permission check.
API endpoints have the same checks as the web pages that use them.

Input and output

Validate everything with form requests, including data from your own front end and from webhooks.
Guard against mass assignment. Define $fillable on models, and never pass $request->all() straight into create() or update().
Be careful with raw queries. DB::raw(), whereRaw() and orderByRaw() with user input are injection risks. Use bindings.
Avoid unescaped output. Treat every {!! !!} in a Blade template as something to justify.
Restrict file uploads by type and size, store them outside the public folder and serve them through a controller that checks permission.

Secrets and configuration

APP_DEBUG is false in production. Debug pages expose environment variables, including your keys.
The .env file is not in Git and is not reachable from the web.
Secrets are rotated when a developer or supplier leaves, and after any suspected leak.
Each environment has its own keys, so a leaked staging key cannot touch production.
APP_KEY is unique per environment and never shared.

HTTP and browser security

HTTPS everywhere, with HSTS enabled.
Security headers are set, including a Content Security Policy, X-Content-Type-Options, Referrer-Policy and a frame policy.
Cookies are secure. Session cookies should be Secure, HttpOnly and have a suitable SameSite setting.
CORS is restricted to the origins that need it.

Servers and infrastructure

The operating system is patched automatically or on a schedule.
SSH uses keys, not passwords, and root login is disabled.
Only the ports you need are open. Databases and Redis should not be reachable from the internet.
Backups are encrypted, stored off the server and tested.
Access is reviewed. Remove former staff and suppliers from servers, Git hosting, DNS and third-party dashboards.

Our infrastructure management service covers this layer.

Monitoring and response

Errors are tracked, so unusual failures are spotted quickly.
Important events are logged, such as logins, permission changes and exports, without logging passwords or full card numbers.
You know who to call. Have a short written plan for what happens if you suspect a breach, including how to meet the ICO's 72-hour reporting window for personal data breaches.

Getting help

If working through this list raised more questions than it answered, our security review covers all of it and more, with a written report, a free retest once fixes are in and the option of a monthly patching plan afterwards.

How to keep Laravel and its dependencies patched

2026-10-24T00:00:00Z

Your application code is only a small part of what runs in production. A typical Laravel application pulls in well over a hundred Composer packages and often hundreds more JavaScript packages, plus PHP itself, the web server and the operating system. Any of them can have a security flaw discovered tomorrow.

Patching is not exciting, but it is one of the most effective security measures there is. This is the routine we use on our security patching plans, and you can run it yourself.

Know what you depend on

Start by looking at what is installed:

composer show --direct
composer outdated --direct
npm outdated

composer show --direct lists the packages you chose. Everything else is a dependency of those. composer outdated shows what has newer versions available. Look out for packages that have been abandoned or have not been updated in years, as they will not get security fixes either.

Check for known vulnerabilities

Composer and npm can both check your installed packages against public security advisories:

composer audit
npm audit --omit=dev

Run these now, and then make them part of your CI pipeline so a pull request fails if it introduces a known vulnerability. For extra protection, the roave/security-advisories package stops Composer installing versions with known issues in the first place.

Automate the routine updates

GitHub's Dependabot, or a similar tool, can open pull requests when new versions of your dependencies are released. Configure it to group minor and patch updates together, so you get one tidy pull request a week rather than dozens.

Automated pull requests are only safe if you have tests. Each update should run through your test suite in CI before anyone merges it.

A monthly routine

Once a month:

Update minor and patch versions of Laravel and your packages with composer update, and the same for front-end packages.
Run the full test suite, static analysis and a build of your front-end assets.
Deploy to staging and check the critical paths: login, checkout, the main features your customers use.
Deploy to production at a quiet time, with a way to roll back.
Update the operating system and PHP minor version on your servers.
Write down what changed, so you can trace any issue back to a specific update.

For most well-tested applications, this takes an hour or two a month.

When an urgent advisory lands

Sometimes a critical vulnerability is announced in a package you use, and waiting for the monthly cycle is not an option. Have a faster route ready:

Subscribe to security advisories for Laravel, PHP and your key packages, or use a monitoring service that alerts you.
Decide in advance who can approve an emergency deploy.
Apply the single patched package with composer update vendor/package, rather than updating everything at once.
Test the affected area, deploy and then return to normal.

On our patching plans, critical patches are applied within one working day.

Major versions need a plan

Minor and patch updates should be routine. Major versions, of Laravel itself or of big packages, usually include breaking changes and need more care. Laravel releases a new major version every year, each with bug fixes for 18 months and security fixes for two years. Plan your upgrade well before your current version's security support ends.

Our Laravel 13 upgrade guide covers what is involved, and our Laravel upgrade planner shows each step from your current version.

Do not forget the servers

PHP versions and operating systems have their own support windows. Check your PHP version against the dates on php.net, and make sure your servers apply operating system security updates automatically or on a schedule.

If this sounds like a lot

It is less work than it looks once the routine is in place, but it does need to happen every month, without fail. If you would rather not think about it, our security patching plans start at £149 per month per application and include monthly updates, advisory monitoring, emergency patches and a short report.

Laravel 13 upgrade guide for business owners

2026-10-24T00:00:00Z

Laravel 13 was released in March 2026. If your application runs on Laravel, you are probably wondering whether you need to upgrade, how risky it is and what it will cost. This guide answers those questions without assuming you are a developer.

Do you need to upgrade?

Laravel supports each major version for a fixed period: bug fixes for 18 months and security fixes for two years. After that, if a security flaw is found in the framework, your version will not be patched.

As of October 2026:

Version	Status	Security fixes until
Laravel 13	Fully supported	17 March 2028
Laravel 12	Security fixes only	24 February 2027
Laravel 11	End of life	Ended 12 March 2026
Laravel 10 and older	End of life	Ended

So:

On Laravel 12? You have until February 2027. Plan the upgrade for the next few months, while it is still a small job.
On Laravel 11 or older? Your framework no longer gets security fixes. Upgrading should be a priority.
On Laravel 5, 6 or 7? You are several years out of support, and probably on an unsupported PHP version too. This is a bigger project, but a very common one.

Our Laravel version support tracker has the full list of dates.

What Laravel 13 requires

The most important requirement is PHP 8.3 or newer. If your servers run PHP 8.2 or older, they will need upgrading as part of the project. Laravel 13 supports PHP 8.3, 8.4 and 8.5.

Laravel 13 itself has relatively few breaking changes. Most applications on Laravel 12 can move across with modest effort, as long as their packages support the new version.

What usually causes the work

In our experience, the framework is rarely the hard part. The work comes from everything around it.

Packages. Every third-party package in your application must support Laravel 13. Popular, well-maintained packages usually update quickly. Abandoned packages do not, and need replacing or rewriting.

PHP versions. Jumping several PHP versions at once can surface deprecated functions and changed behaviour in your own code.

Missing tests. Without automated tests, the only way to know whether the upgrade broke something is to check every feature by hand. We usually add basic tests for the most important paths before upgrading.

Skipped versions. Laravel has to be upgraded one major version at a time, because each step has its own changes. Going from Laravel 8 to 13 means five upgrades in a row, each one tested.

How long does it take?

As a rough guide, for a typical business application:

Laravel 12 to 13, well tested, few packages: often a day or two.
Laravel 10 or 11 to 13: usually a few days.
Laravel 5.x to 8 to 13: typically one to two weeks, mostly because of packages and PHP.

Large applications, unusual packages and very thin test coverage all add time.

What does it cost?

Our core framework upgrades start at £195 per codebase, excluding VAT. A short assessment of your code, packages and tests gives you a fixed quote before work starts. Work on bespoke or abandoned packages is quoted separately, so there are no surprises. See our Laravel upgrade service for details.

How a safe upgrade works

Assess. Review the current version, PHP version, packages and test coverage, and list the risks.
Prepare. Add tests for critical paths and make sure staging matches production.
Upgrade step by step. One major version at a time, following the official upgrade guides, with tests run at every step. Automated tools such as Rector, and AI coding agents, handle much of the repetitive editing, with an engineer reviewing every change.
Upgrade PHP on staging, then production.
Check on staging. You test the key features yourself.
Release at a quiet time, with a rollback plan ready.

Is it worth it if everything works?

Usually, yes. Beyond security fixes, staying current means packages keep working, developers are easier to find and future upgrades stay small. Our Laravel upgrade planner shows every step from your current version, with notes on what changes along the way.

Once you are on Laravel 13, a support and maintenance plan keeps you current, so you never face a big catch-up again.

12 signs your Laravel app needs rescuing

2026-10-24T00:00:00Z

Software projects rarely fail all at once. They drift: releases slow down, bugs come back, and the people who understand the system become harder to reach. By the time it feels like a crisis, the warning signs have usually been there for months.

These are the signs we hear about most often from businesses that come to us for a project rescue. If several of them sound familiar, it is time to act.

Warning signs about people and access

1. Your developer has gone quiet. Replies take days, estimates keep slipping and you are not sure what is being worked on. Sometimes there is a good reason. Often it means the project has become hard to work on, or has been quietly deprioritised.

2. You are not sure you own everything. Is the code in a Git repository in your company's name? Are the server, domain, DNS and email accounts yours? If a supplier holds the keys, you are exposed.

3. Only one person understands it. If one developer left tomorrow, could anyone else deploy a fix? Knowledge held by a single person is a risk, however good that person is.

Warning signs in the software

4. Every release breaks something. Fixing one bug creates another, and releases have become stressful. This usually means there are few automated tests and the code is tightly tangled together.

5. Simple changes take weeks. A new field on a form, a tweak to an email or a small report should not be a project. When they are, technical debt is slowing everything down.

6. It is getting slower. Pages that were fast at launch now take seconds, or time out, as data grows. Common causes are missing database indexes, inefficient queries and heavy work done during page loads.

7. Errors are discovered by customers. If you hear about problems from support tickets rather than alerts, there is no error tracking or monitoring in place.

8. It is stuck on an old version. The app runs on Laravel 5, 6 or 7 and an old PHP version, and every attempt to update packages fails. Those versions no longer get security fixes. Our version support tracker shows the dates.

9. Nobody understands the code. This is increasingly common with applications built quickly using AI tools. The app works, but it grew without a plan, and now nobody can safely change it.

Warning signs in operations

10. Deploys are manual and scary. Releasing means someone logging into a server and running commands by hand, and only at weekends.

11. You have never restored a backup. There may be backups, but nobody has checked they work, or where they are stored.

12. Security questions get vague answers. When you ask about patching, access control or data protection, the answers are not specific. That is often because nobody is actively looking after it.

What to do next

If several of these sound familiar, these steps will make things better, whoever ends up doing the work.

Secure access first. Make a list of every account the application depends on: code hosting, servers, domain registrar, DNS, email sending, payments, storage and any third-party services. Make sure each one is in your company's name, and that you can log in.

Get the facts. An independent code review, or a vibe code review for AI-built apps, tells you what you actually have, what is urgent and what can wait. It costs a few hundred pounds and gives you a basis for every decision that follows.

Stabilise before you rebuild. It is tempting to start again from scratch. Sometimes that is right, but most struggling applications can be stabilised step by step: add monitoring and backups, fix the critical issues, add tests around the most important features and then improve the code area by area. That is usually faster and cheaper than a rebuild, and you keep a working product throughout.

Put maintenance in place. Once things are stable, a regular support and maintenance plan stops the same problems coming back.

How we can help

We take over Laravel projects in every state, from a tidy handover to a supplier who has disappeared. The first step is always a free call to understand what is going on. From there, our Laravel rescue service gets you back in control.

Laravel hosting in 2026: Forge, Laravel Cloud or AWS?

2026-10-24T00:00:00Z

Where your Laravel application runs affects how much it costs, how well it copes with busy periods and how much work it takes to keep running. The good news is that the Laravel ecosystem now has excellent options for almost every situation. The challenge is picking the right one.

This guide compares the main choices we recommend to clients, and when each one makes sense.

Option 1: Laravel Forge and a cloud server

Laravel Forge is a server management service from the Laravel team. You connect it to a cloud provider such as DigitalOcean, Hetzner, Vultr, Akamai or AWS, and it sets up and manages servers configured for Laravel: PHP, Nginx, databases, queues, scheduled tasks, SSL certificates and deployments.

Good for: most business applications, SaaS products in their first few years, internal tools and marketing sites.

Strengths:

Predictable monthly costs: a Forge subscription plus the servers you choose.
Full control. It is your server, and you can install what you need.
Simple deployments from Git, with zero-downtime options.
A large community and plenty of experience to draw on.

Trade-offs:

You are responsible for the servers. Operating system updates, PHP upgrades, monitoring and backups still need someone to look after them.
Scaling beyond a few servers takes planning, such as load balancers, separate database servers and queue workers.

This site is deployed with Forge.

Option 2: Laravel Cloud

Laravel Cloud is a fully managed platform from the Laravel team, launched in 2025. You push your code, and Cloud runs it. There are no servers to manage, and it can scale up and down automatically, with managed databases, caches and object storage available alongside.

Good for: teams that do not want to manage servers at all, applications with spiky or unpredictable traffic, and new projects that want to move quickly.

Strengths:

No servers to patch, monitor or upgrade.
Automatic scaling, and options to reduce cost when traffic is low.
Built specifically for Laravel, so queues, scheduling and deployments work as you expect.

Trade-offs:

Usage-based pricing is harder to predict than a fixed server, so set budgets and alerts.
Less low-level control than your own server, which matters if you need unusual software or system settings.

Option 3: Laravel Vapor and AWS Lambda

Laravel Vapor runs Laravel serverlessly on AWS Lambda, inside your own AWS account. It suits applications that need to absorb very large traffic spikes and teams that are already committed to AWS. It adds some constraints of its own, such as how files and long-running tasks are handled, so it is worth planning for those from the start.

Option 4: AWS or another cloud, directly

Some organisations run Laravel directly on AWS, Azure or Google Cloud, using containers or virtual machines with their own tooling.

Good for: strict compliance or data residency requirements, organisations with an existing cloud team, and very large or complex systems.

Trade-offs: much more to set up and run. Without people who know the platform well, this is the easiest option to get expensive or insecure.

How to choose

A few questions usually settle it:

Who will look after the servers? If nobody, choose Laravel Cloud, or Forge with a managed service on top.
How predictable is your traffic? Steady traffic suits fixed servers. Large, sudden spikes suit Cloud or Vapor.
Do you need a predictable bill? Fixed servers are easier to budget for.
Do you have compliance requirements? Some contracts specify where data must be stored, or which certifications a provider must hold.
What does your team already know? The best platform is often the one your team can run confidently.

For most of the UK businesses we work with, Forge on a well-sized cloud server, with a separate managed database for larger applications, is the best balance of cost, control and simplicity. Laravel Cloud is an increasingly strong choice for teams that never want to think about servers.

What matters more than the platform

Whichever option you choose, these make the biggest difference to how reliable your application is:

Accounts in your name. Your hosting, domain, DNS and Git accounts should belong to your company, not your supplier.
Backups that have been restored. Test restoring a backup at least every few months.
Monitoring and alerts for uptime, errors and disk space.
Patching. Operating systems, PHP and dependencies kept up to date.
Staging. A copy of production where changes are tested first.
Documentation, so someone else can take over if they need to.

Getting help

Our infrastructure planning service gives you a fixed-price hosting plan with costs, a backup and recovery plan and a migration path, and our managed infrastructure plans look after servers on Forge, Laravel Cloud or AWS each month, with the accounts always in your name.

How much does custom software cost in the UK?

2026-10-24T00:00:00Z

"How much will it cost?" is the first question almost every client asks, and the honest answer is that it depends. That is not very helpful on its own, so this guide explains what it depends on, gives realistic ranges and shows how to keep the cost under control.

What drives the cost

Custom software is priced by the time it takes to design, build, test and launch. Four things decide how much time that is.

Scope. How many types of user, screens, features and rules the software has. This is by far the biggest factor.

Integrations. Each connection to another system, such as payments, accounting, a CRM or an AI model, adds work, and some third-party systems are much easier to work with than others.

Complexity of the rules. A booking system with simple time slots is very different from one with resources, discounts, cancellation rules and multiple locations.

Quality expectations. Accessibility, performance targets, security reviews, audit trails and high availability are all worth having, and all take time.

Typical ranges

These are rough guides for UK businesses, assuming a competent team and a reasonably clear brief. Your project could be smaller or larger.

Type of project	Typical scope	Indicative time
Internal tool or admin panel	A few user roles, forms, reports, one or two integrations	3 to 8 weeks
Customer portal	Logins, account management, documents, notifications, integration with your systems	6 to 12 weeks
SaaS product, first release	Multi-tenant accounts, billing, onboarding, core feature set, admin panel	8 to 16 weeks
Marketplace or platform	Several user types, payments between users, reviews, search, mobile app API	4 to 9 months

To turn time into money, multiply by the team's rate. At Larasoft, that is £20 per hour for engineers and £25 per hour for senior engineers, excluding VAT. Many UK agencies charge several hundred pounds per day or more, so the same weeks of work can cost very different amounts.

Why the cheapest rate is rarely the cheapest project

A low hourly rate does not help if the work takes twice as long, needs redoing or leaves you with code nobody else can maintain. When comparing quotes, look at:

Who does the work. Ask who will write and review the code, and how experienced they are.
What is included. Testing, project management, deployment and documentation are sometimes extra.
Who owns the result. You should own the code and every account from day one.
What happens after launch. Ask about support, response times and the cost of changes.

Our guide on how to choose a Laravel agency has a full list of questions to ask.

How AI changes the numbers

AI coding tools have genuinely changed the economics of software. Experienced teams using them well can deliver the same scope in less time, especially the repetitive parts: forms, admin screens, tests, integrations with well-documented APIs and documentation.

What AI has not changed is the need for judgement. Someone still has to design the system, decide what to build, check that the code is secure and correct, and take responsibility for it. Projects that skip that step tend to cost more later, often in a rescue.

That is why we pair AI-assisted delivery with senior review on every change. It is how we keep our rates low without passing risk on to clients.

How to keep the cost down

Build less first. Launch the smallest version that is genuinely useful, then add features based on what users actually do. This is the single most effective way to save money.
Use what exists. Well-maintained packages and services for login, payments, email and admin panels are cheaper than building your own.
Be clear about rules. The more precisely you can describe how things should work, the less time is spent on rework.
Choose fixed prices for well-defined work and time-based billing for discovery and changing requirements.
Make decisions quickly. Waiting for decisions is one of the hidden costs of any project.

Running costs after launch

Software needs looking after once it is live. Budget for:

Hosting, which for most business applications is tens to a few hundred pounds a month. See our hosting comparison.
Third-party services, such as email sending, error tracking, payments and any AI usage.
Maintenance, to keep the framework, packages and servers up to date and secure. Our support plans start at £200 per month.
Improvements, because once people use the software, they will have ideas.

Getting an accurate figure

The fastest way to an accurate number is a short conversation about what you need. Book a free call and we will give you either a fixed price or an estimate range for each milestone, with the assumptions written down. See our bespoke software development service and our pricing for more.

How to choose a Laravel development agency

2026-10-24T00:00:00Z

Choosing a development partner is one of the most important decisions you will make about your software. A good one can save you months and a lot of money. A poor one can leave you with a codebase that has to be rescued, or rewritten.

This guide covers what to look for in a Laravel agency, the questions to ask and the warning signs to watch for. We are a Laravel agency ourselves, so we have tried to keep it fair: these are the questions we would want a client to ask us.

Start with specialism

Laravel is a large ecosystem, with its own tools for queues, payments, admin panels, testing and deployment. An agency that works with Laravel every day will know the right tool for each job, and the pitfalls of each.

Look for:

A clear focus on Laravel and PHP, rather than Laravel as one of twenty listed technologies.
Case studies with real Laravel applications, ideally ones you can visit.
Evidence of community involvement, such as open-source packages, talks or writing.
Certifications, such as the Laravel Certified company programme, as one signal among several.

Questions to ask before you sign

About the people

Who will write the code, and who will review it? Ask for names and experience, not just "our team".
Will the same people work on my project throughout? Constant changes of developer slow projects down.
How do you use AI coding tools? Every serious agency uses them now. The important part is how changes are checked before they ship.

About the work

How do you handle testing? Expect automated tests for the important features, not just manual checking.
How will I see progress? Look for regular releases to a staging site you can try yourself.
How do you estimate? Good agencies explain their assumptions and break the work into milestones.
What happens when requirements change? They will. Ask how changes are priced and agreed.

About ownership

Who owns the code? The answer should be you, from the first commit.
Whose name are the accounts in? Hosting, domain, Git repository, payment and email accounts should all belong to your company.
Could another developer take over? Ask about documentation and coding standards.

About support

What happens after launch? Ask about support plans, response times and the cost of small changes.
How do you handle security updates? Laravel and its packages need regular patching.
What would you do if our project was in trouble? A good partner tells you early and honestly.

About fit

What projects like ours have you done? Similar size, sector or technical challenge.
Can I speak to a client? References from current clients are more useful than logos on a website.

Warning signs

Very low prices without explanation. Ask what is excluded and who does the work.
Reluctance to give you access to the code or hosting during the project.
No staging environment, or no way for you to try features before launch.
Vague answers about testing and security.
Pressure to sign a long contract before any work has been delivered.
A recommendation to rebuild everything before anyone has properly reviewed your existing code.

Start small

The best way to judge a supplier is to work with them on something small and paid. A code review, a short discovery phase or a single well-defined feature will tell you more about their communication, quality and honesty than any sales call.

How we answer these questions

We publish our prices, explain how we work and show our case studies. Every change we deliver is reviewed by a senior engineer, you own the code and accounts from day one, and our fixed-price reviews are a low-risk way to see how we work. If you are comparing agencies, book a free call and ask us anything on this list.

What is Laravel? A guide for business owners

2026-10-24T00:00:00Z

If you have been talking to developers about a new web application, there is a good chance someone has mentioned Laravel. This guide explains what it is, why it is so popular and what it means for your business if your software is built on it.

Laravel in one paragraph

Laravel is a free, open-source framework for building web applications with PHP, one of the most widely used programming languages on the web. It was created by Taylor Otwell in 2011 and is now maintained by a company, Laravel, alongside a very large community of contributors. A framework is a set of ready-made building blocks and conventions that developers use, so they do not have to solve the same common problems from scratch on every project.

What Laravel is used for

Laravel is used to build almost any kind of web software:

SaaS products, such as subscription software for businesses or consumers.
Customer portals and member areas.
Marketplaces and booking platforms.
Internal tools, CRMs and admin systems.
APIs that power mobile apps and connect systems together.
Ecommerce with custom rules that standard shop platforms cannot handle.

Our case studies include a security operations platform, a travel review app for airline crew, a digital credentials platform and a self-updating film and TV database, all built on Laravel.

Why businesses choose Laravel

It is quicker to build with. Laravel includes well-tested building blocks for logins, password resets, email, file storage, scheduled tasks, background jobs and subscription billing. That means more of your budget goes on the features that make your product different.

It is secure by default. Laravel protects against many common attacks out of the box, such as cross-site request forgery and SQL injection, and the team releases security fixes for each version for two years.

It is easy to find developers. Laravel is among the most popular frameworks in the world, so you are never stuck looking for rare skills, and you are never tied to a single supplier.

It has a complete ecosystem. First-party tools cover hosting and deployment (Laravel Forge and Laravel Cloud), admin panels, testing, real-time features and more, all designed to work together.

It keeps moving. A new major version is released every year, with a predictable support policy. Laravel 13, released in March 2026, added first-party tools for building AI features.

What to consider

No technology is perfect for everything. Before choosing Laravel, consider:

Upgrades. Each major version is supported for two years, so plan to upgrade regularly. It is cheap when done routinely, and expensive when left for years. See our version support tracker.
Simple websites. For a brochure site or blog that marketing staff edit, a content management system or a static site may be simpler. Our comparison of Laravel and WordPress covers this.
Quality varies. Laravel makes good software easier to build, but it does not guarantee it. The experience of the team matters more than the framework.

Laravel and AI

AI coding tools work particularly well with Laravel. Its strong conventions and excellent documentation mean AI agents can produce consistent code, as long as experienced engineers set the structure and review the results. That combination is how we build: see our AI-driven development service.

Next steps

If you are deciding whether Laravel is right for your project, or you have inherited a Laravel application and want to know what state it is in, we are happy to help. See our Laravel development services or book a free call.