DEV Community: Kavita Systems

Software Development Trends Beyond Websites: What the US and Europe Expect in Q3 2026

VitaliiK — Wed, 15 Jul 2026 11:44:24 +0000

A company asks an agency to build a dashboard.

The brief includes twenty screens, several charts, an AI assistant, and a preferred technology stack. It looks like a straightforward design-and-development project.

Then discovery begins.

Customer data is copied manually between the website, CRM, ERP, and spreadsheets. Employees correct mismatched records. Managers receive reports too late to act on them. Customers contact support because they cannot see order statuses or download documents themselves.

The requested dashboard would make the process look more modern. It would not fix the process.

The useful product is an operational system connecting data, people, rules, and decisions.

That example captures the central market shift entering Q3 2026:

Standard code is becoming cheaper to produce. Understanding what should be built—and making it reliable in production—is becoming more valuable.

AI can generate layouts, components, tests, and significant parts of an application. Cloud platforms already provide authentication, payments, storage, analytics, messaging, and infrastructure.

Custom software has not disappeared. Demand has moved deeper into the business: customer portals, internal tools, B2B commerce, integrations, workflow automation, AI-assisted operations, and legacy modernization.

For buyers, this changes how software should be purchased. For developers, it changes which skills create a lasting advantage.

Data note: This outlook is based on information available in July 2026. The latest complete US quarterly e-commerce figures cover Q1 2026; the Q2 release is scheduled for August 18.

One term, two very different markets

“Web development” now describes two increasingly different categories of work.

The first includes marketing sites, landing pages, content platforms, standard stores, and early prototypes. These projects still matter, but production is becoming more standardized. Templates, low-code products, AI builders, and mature SaaS tools reduce delivery time and technical differentiation.

The second category includes software that runs in a browser but is embedded in business operations:

customer and partner portals;
internal workflow systems;
B2B ordering platforms;
SaaS products;
document-processing applications;
CRM and ERP integrations;
modern interfaces for legacy systems.

The cost of these systems is not determined by page count. It depends on roles, permissions, data ownership, integrations, migration, security, and the consequences of failure.

What happens when an API is unavailable? Which platform contains the correct customer record? Who can approve an order? Which actions require an audit trail? How much would an hour of downtime cost?

A business-critical platform cannot be planned as a “large website.” It also requires process analysis, architecture, testing, observability, documentation, infrastructure, and post-launch support.

A polished interface can hide a broken process.

It cannot repair it.

The United States: buyers expect proof of value

The United States remains one of the most attractive software markets, but it is also one of the most competitive.

The US Bureau of Labor Statistics projects 15% employment growth for software developers, quality assurance analysts, and testers between 2024 and 2034. Web developers and digital designers are projected to grow by 7%, while computer programmers are expected to decline by 6%.

The figures do not measure agency revenue, but they show a structural change. The market is placing less value on isolated programming tasks and more on complete engineering responsibility: understanding requirements, designing systems, integrating platforms, protecting data, and operating software after launch.

The same pattern is visible in e-commerce. Seasonally adjusted US retail e-commerce sales reached $326.7 billion in Q1 2026, up 9.8% year over year, and represented 16.9% of total retail sales.

Yet the opportunity is not simply to build more stores. Much of the valuable work sits behind the storefront:

account-specific pricing and B2B ordering;
subscriptions and recurring purchases;
ERP, warehouse, and inventory synchronization;
fulfillment and returns automation;
customer self-service;
checkout and performance optimization.

A commerce website is rarely an isolated sales channel. It is an interface connected to payments, logistics, accounting, inventory, and customer service.

US buyers frequently evaluate projects through time-to-value. They want to know when the first usable release will appear, which process it will improve, how it will affect cost or revenue, and who will own the system in production.

Compare these two proposals:

“We will build a modern customer portal with a TypeScript frontend.”

And:

“We will give customers direct access to invoices, documents, delivery updates, and order history, reducing routine requests handled by support.”

The first describes implementation.

The second describes a business result.

A framework is not a strategy, and a technology list is not a business case.

Europe: one region, many software markets

Europe presents a different type of complexity.

The European Union is a shared economic and regulatory space, but its companies vary greatly by country, industry, size, and digital maturity. The United Kingdom adds a separate commercial and regulatory environment.

Eurostat reports that 53% of EU businesses purchased cloud services in 2025. Around 20% used AI, up from 13% in 2024. Adoption remained uneven: 55% of large businesses used AI, compared with 19% of SMEs.

That gap creates two parallel opportunities.

Digitally mature organizations need stronger integrations, data platforms, AI governance, automation, and legacy modernization. Other companies still need to replace spreadsheets, repeated data entry, shared inboxes, and fragmented reporting.

In both cases, rebuilding everything is rarely the best answer.

A company may already use a CRM, accounting platform, commerce system, document service, and industry-specific ERP. The missing product is often the layer connecting them: a portal, workflow application, integration service, API, or shared operational view.

This is why hybrid architecture is becoming the default:

Standard capabilities are purchased. Differentiating workflows are built.

European expansion also introduces product decisions earlier. A system may need different languages, payment methods, invoices, tax rules, accessibility behavior, and legal content in each market.

Localization is not always translation. Sometimes it changes the workflow and architecture.

Why Q3 2026 matters for AI governance

August 2, 2026 is one of the quarter’s most important dates for European software teams.

The EU AI Act becomes broadly applicable on that date, with exceptions and later timelines for some high-risk systems. Relevant transparency obligations for certain AI interactions and generated content also begin to apply.

Not every internal assistant or support chatbot becomes a high-risk system. However, “we call an API from a major model provider” is no longer an adequate governance strategy.

Teams need to understand:

what operation the AI performs;
which personal or confidential data it can access;
where information is processed and retained;
how users are informed that AI is involved;
who can review or override the result;
what happens when confidence is low;
how important actions are logged.

These questions influence UX, architecture, permissions, observability, model selection, and vendor management.

Accessibility is following a similar path. The European Accessibility Act has applied to selected products and services since June 28, 2025, including e-commerce, consumer banking, electronic communications, and ticketing.

Accessibility therefore belongs in component libraries, design systems, acceptance criteria, and testing—not in an audit performed several days before release.

For developers, regulation is becoming an engineering constraint.

For buyers, compliance is becoming part of product quality.

What businesses are funding

Across the US and Europe, investment is concentrating around software that changes a measurable process.

Portals and workflow automation

A portal creates value when it moves routine interactions away from phone calls, email, and manual support.

Customers may track orders, access invoices, exchange documents, make payments, and review service history independently. Success is not “twelve screens delivered.” It may mean fewer support requests, shorter order cycles, or fewer errors.

Internal tools offer similar value. Many companies still run critical processes through spreadsheets, inboxes, messaging platforms, and repeated exports.

A weak automation project digitizes an existing form.

A stronger project asks:

Which steps can disappear?
Which decisions follow predictable rules?
Where does the necessary data already exist?
Which exceptions require a person?
Where do delays and errors occur?

Automating a bad process can make waste move faster.

Redesigning the workflow can remove it.

Integrations and legacy modernization

The existence of an API does not guarantee a safe integration.

Data may be duplicated, identifiers inconsistent, webhooks unavailable, and limits poorly documented. Legacy applications may also contain years of undocumented business rules.

Replacing such a system in one “big bang” release may appear elegant while being operationally reckless.

A safer strategy is progressive: document existing rules, identify authoritative data sources, expose selected capabilities through APIs, introduce a modern interface, replace modules gradually, and migrate users in controlled stages.

The key buyer question is not:

“Can you rewrite our platform?”

It is:

“How will you modernize it without interrupting our business?”

B2B commerce and AI operations

Standard consumer stores can often be launched on existing platforms. Custom development becomes valuable when commerce includes negotiated prices, company accounts, credit limits, approval chains, distributor roles, ERP-controlled inventory, or specialized fulfillment.

In B2B commerce, the catalog is often the easy part. The real product is the commercial logic behind it.

“AI chatbot development” is also becoming too generic to be meaningful. Useful AI may extract data from invoices, classify requests, search documentation, prepare response drafts, verify applications, summarize case files, or transfer approved information into a CRM.

The most reliable pattern is controlled automation:

AI handles common cases, a person approves important decisions, and unusual cases are escalated.

Teams must understand how outputs will be verified, how much each completed operation will cost, and what happens when the model fails.

Four development trends shaping Q3 2026

1. AI agents are entering delivery

GitHub moved Agentic Workflows into public preview in June 2026, supporting reasoning-based repository tasks such as issue triage, CI-failure analysis, and documentation updates.

The important change is not simply that AI can produce more code. Repositories must become understandable and safe for both humans and agents.

That increases the value of explicit architectural boundaries, typed contracts, automated tests, reproducible environments, structured logs, restricted permissions, and mandatory review.

A capable agent working in a chaotic repository produces chaos faster.

2. Strong constraints matter more

Type systems, static analysis, tests, and clearly defined APIs become more valuable as more implementation is generated automatically.

The right buyer question is not:

“Which language do you use?”

It is:

“What prevents a change in one module from silently breaking another?”

The answer should include engineering practices, not only a technology name.

3. AI now has unit economics

GitHub moved Copilot to usage-based billing in June 2026, with usage calculated through AI Credits and token consumption.

That reflects a wider reality: multi-step AI work is a variable infrastructure cost.

A production feature may require spending on model calls, embeddings, search, storage, retries, monitoring, moderation, and human review.

Teams need to calculate the cost per completed business operation—not only the cost per API request. Model routing, caching, smaller models, budgets, and usage limits are becoming architectural decisions.

4. Production quality moves into the Definition of Done

A feature is not complete because it worked during a demo.

Teams need visibility into errors, slow requests, failed integrations, background jobs, AI quality, cost, and critical user journeys.

Security and accessibility also need to start early. The US Bureau of Labor Statistics projects 29% employment growth for information security analysts between 2024 and 2034—a wider signal that software risk is growing alongside software value.

Security requires permissions, audit logs, backups, API protection, dependency updates, incident response, and tested recovery.

Accessibility requires more than an automated scan. Keyboard navigation, focus behavior, screen-reader workflows, complex forms, and error recovery need human testing.

Observability, security, and accessibility are not final checkboxes.

They are properties of the system.

What developers and buyers should change

Developers are not becoming less relevant. The role is becoming wider.

As AI handles more implementation work, engineers create value by framing problems correctly, designing system boundaries, reviewing generated code, understanding business data, explaining trade-offs, and owning production outcomes.

The strongest developers will know where custom code is necessary, where an existing service should be reused, where automation is unsafe, and which shortcut will become expensive six months later.

Buyers also need a new evaluation model.

A long feature list does not guarantee value. A low hourly rate does not guarantee a low final cost. A fashionable stack or an AI claim does not guarantee maintainability.

Start with the process, not the requested interface.

Instead of saying:

“We need a dashboard.”

Explain:

“Managers spend two days combining reports from five systems, and the information is already outdated when they receive it.”

Instead of:

“We need an AI assistant.”

Explain:

“Support employees spend 40% of their time searching documents and preparing variations of the same answers.”

Then define the smallest measurable outcome for the first production release.

A sensible project structure includes:

Discovery to understand the process, users, systems, data, and risks.
A pilot that tests the assumption most likely to invalidate the project.
One complete production workflow with appropriate security and monitoring.
Expansion based on real usage, not assumptions.
Continuous operation after launch.

An MVP may be narrow.

It should not be careless.

The real outlook for Q3 2026

The US and European software markets are moving in the same broad direction.

Basic websites and standard interfaces are becoming faster and cheaper to produce. AI agents are taking over part of implementation. Cloud services are absorbing more standard functionality.

At the same time, serious software is becoming more integrated, regulated, and operationally important.

The US market tends to emphasize speed, measurable ROI, scalability, and production ownership.

European projects often introduce localization, accessibility, privacy, and AI governance earlier.

But both markets reward the same fundamental capability:

Turning a messy real-world process into a reliable digital system.

For developers, the opportunity is no longer only to write code faster.

For buyers, the goal is no longer to purchase the largest feature set at the lowest possible rate.

The goal is to build the smallest reliable system capable of producing a measurable business result.

AI can help a strong team deliver that system faster.

It still cannot decide which system is worth building.

This article was prepared by the Kavita Systems team.

Why Early MVPs Fail Before Launch

Ihor — Tue, 14 Jul 2026 09:26:23 +0000

Most MVPs do not fail because the first version is too small.

They fail because the first version is not focused enough.

A real MVP is not just a reduced version of a full product. It is a focused first version built to test the core product hypothesis with real users before the team spends too much time, budget, and engineering effort in the wrong direction.

A good MVP should help answer a few practical questions:

Does the problem really exist?
Do users understand the value?
Will they take the key action?
Is there a path toward a real product and a viable business?

Many early MVPs never reach that point. Not because the idea is always bad. More often, the team expands the product too early, adds too many features, underestimates the real cost of development, and starts building before there is a clear plan for reaching the first users.

The real problem is not the number of features

One of the most common mistakes at the beginning is trying to build a nearly complete product instead of an MVP.

Teams add dashboards, complex user roles, permissions, analytics, notifications, AI features, integrations, admin panels, filters, billing logic, settings pages, and multiple user flows before the core idea has been validated.

Each feature may look reasonable on its own. But together, they increase the budget, slow down development, complicate the architecture, and delay launch.

The first version should not prove that the team can build a lot.

It should test the riskiest assumptions behind the product.

Before development starts, the team should answer one simple question:

What is the smallest version of this product that still makes the core idea work?

That is the real MVP. Everything else belongs to later iterations.

AI can generate ideas, but it cannot replace product judgment

AI is very useful at the early stage.

It can suggest product structure, user flows, feature lists, monetization ideas, onboarding scenarios, landing page copy, technical approaches, and even prototype logic.

But there is also a risk: AI often expands the scope instead of narrowing it.

A founder can quickly receive a long list of useful features:

chatbots;
automation;
recommendations;
personalization;
dashboards;
content generation;
RAG;
integrations;
smart search;
reports;
workflow tools.

Some of these ideas may be valuable. The problem is that every feature has a cost.

It has to be designed, developed, tested, explained to users, maintained, and improved after launch.

That is why AI should not only be used for brainstorming. It should also be used for filtering.

A better question is:

Which 20% of the functionality creates most of the value for the first user?

If the team cannot answer that, the next step is not writing code.

The next step is sharpening the product focus.

Design in an MVP is not decoration

Some teams treat design as secondary during the MVP stage.

The logic is usually simple: the feature just needs to work.

There is some truth in that. A first version does not need complex animation, expensive branding, or a large visual system.

But that does not mean design can be replaced by a random set of screens.

Users experience the product through the interface. They judge the product through the first screen, the registration flow, the form layout, the button labels, the error states, the mobile version, the copy, and the overall feeling of trust.

Good design does not guarantee sales.

But weak design can make even a useful product feel confusing, unfinished, or unreliable.

For an MVP, design should be practical, clear, and system-based.

Good MVP design is a system, not a set of pretty screens

A weak MVP design process usually looks like this:

A few attractive screens are created quickly. They look good in a presentation, but they do not account for real data, empty states, validation errors, responsive behavior, user roles, or frontend implementation.

That approach creates problems during development.

The frontend team has to invent missing states in code. Buttons become inconsistent. Spacing changes from screen to screen. Components are recreated instead of reused. The product becomes harder to maintain before it even launches.

Good MVP design can be simple. But it should still be systematic.

It should include:

clear screen structure;
readable typography;
a limited but consistent color system;
reusable components;
button and form states;
error states;
empty states;
responsive behavior;
logic that can be translated into frontend components without constant redesign.

This is especially important for MVPs.

When design and frontend follow the same component logic, the product becomes easier to extend. A new screen is not designed and coded from scratch every time. It is assembled from patterns that already exist.

Do not over-engineer the architecture too early

Another common mistake is choosing an architecture for the future before the product has validated demand.

A separate frontend, separate backend, API-first architecture, microservices, multiple environments, and complex infrastructure can all be the right choice in the right context.

But they are not automatically the right choice for a first MVP.

If the product has not yet proven market demand, unnecessary architectural complexity can become a cost center instead of an advantage.

More moving parts usually mean:

more coordination;
more testing;
more DevOps;
more integration work;
more places where something can break.

That does not mean a monolith is always better.

It means the architecture should match the product stage.

For an early product, a better rule is simple:

Start with the simplest architecture that supports the product’s real needs, but keep the code modular enough to evolve later.

For many MVPs, Laravel can be a practical foundation for backend logic, authentication, user roles, permissions, data management, integrations, queues, payments, and admin functionality.

On the frontend, Vue or React can work well depending on the team and the product. Inertia can be a good fit when the team wants a more integrated full-stack approach.

Nuxt or Next.js may make sense when SEO, SSR, public pages, content-heavy sections, performance, or a more independent frontend layer are important.

The main principle is simple:

Choose the stack for the product, not for the trend.

A minimal product should not feel weak

Founders sometimes worry that a small product will not look impressive enough.

So they add more features, more pages, more edge cases, and more wow moments.

But users do not evaluate an MVP by counting screens. They evaluate whether the product clearly solves a problem.

A small MVP can still feel professional if it has:

clear positioning;
one strong core flow;
stable functionality;
clean UI;
good performance;
clear copy;
predictable behavior;
a simple path to the target action.

A large feature set with a messy interface often performs worse than a smaller product with a clear value proposition and a polished core experience.

The goal is not to make the product look bigger.

The goal is to make the main value easy to understand and easy to use.

Customer acquisition is not a post-launch task

Another serious mistake is assuming that users will appear after the product is launched.

Usually, they will not.

Even a strong MVP needs a distribution channel. That could be personal outreach, LinkedIn, niche communities, SEO, content, partnerships, paid ads, email outreach, direct sales, marketplace platforms, or an existing customer base.

But this channel should be considered before development, not after launch.

If the team does not know who the first user is, where to find them, what problem they already recognize, and why they should try this product, the MVP may become just another finished product with no traffic.

Before building, the team should understand:

who the first user is;
what specific pain point the product solves;
how that user currently solves the problem;
where they look for alternatives;
what would create trust;
what the main action in the MVP should be;
how the team will collect feedback.

An MVP is not just code.

It is a test of the entire system: the idea, the value proposition, the interface, the technology, the acquisition channel, and the market’s willingness to respond.

What teams should do before building an MVP

Before writing code, define the real size of the first version.

Not the full list of features that might be useful someday, but the minimum flow without which the idea does not work.

Then create a design system that is small but real. It should include reusable components, states, responsive behavior, and logic that can be implemented in the frontend without constant rework.

After that, choose technology based on the product’s needs.

If the first version does not require a complex distributed architecture, do not spend the budget on it just because it sounds modern.

At the same time, think about the first customers.

Not after launch. Before launch.

A strong MVP is not the biggest product a team can afford to build.

It is the most focused version that can test the main hypothesis, create a professional first impression, work reliably, and reach the first users.

The first step does not have to be big.

It has to be accurate.

If you need a practical consultation on how to plan, design, and build an MVP, the Kavita Systems team can help you define the right scope, choose a suitable architecture, create a system-based UX/UI foundation, and prepare the product for launch and first users.

Laravel Inertia Architecture: When to Use Vue and When React Makes Sense

VitaliiK — Mon, 29 Jun 2026 09:55:42 +0000

Modern web development often pushes teams toward separation. A product may have a separate backend, a separate frontend, a separate API layer, separate routing, separate deployment pipelines, and sometimes even separate teams responsible for different parts of the system.

That kind of architecture can be the right decision for large platforms, mobile-first products, public APIs, distributed systems, or products that need several independent clients. But not every web application needs that level of separation from the beginning.

For many SaaS platforms, CRM systems, booking platforms, dashboards, client portals, admin panels, internal tools, and MVPs, a fully separated frontend and backend can create more complexity than the product actually needs. More layers often mean more decisions, more coordination, more duplicated logic, and more places where things can break.

This is where Laravel + Inertia.js becomes a very practical product engineering option.

Inertia allows teams to build modern, SPA-like interfaces while keeping Laravel at the center of the application. Laravel still owns routing, controllers, validation, authentication, authorization, database logic, business rules, permissions, and server-side decisions. Vue or React powers the interface layer that users interact with every day.

The important question is not simply whether Vue is better than React or React is better than Vue. A better question is this: which stack will help the team build, launch, support, and grow the product with the least unnecessary friction?

This article compares Laravel + Inertia + Vue and Laravel + Inertia + React from both a developer and client perspective. We will look at architecture, developer experience, delivery speed, budget, support, scalability, risks, and long-term product direction.

The Core Idea Behind Laravel and Inertia

In a Laravel + Inertia application, Laravel is not just a backend API provider. It remains the core of the product. That distinction matters because Inertia is not designed to make Laravel disappear behind a frontend application. Instead, it allows Laravel to keep control over the server-side responsibilities while giving the interface a modern JavaScript experience.

Laravel continues to handle the parts of the application where consistency and trust are critical: routes, controllers, authentication, authorization, validation, database models, business rules, background jobs, queues, integrations, file handling, notifications, and admin workflows.

Inertia connects that Laravel backend with frontend page components. Instead of returning a traditional Blade view, a Laravel controller can return an Inertia page.

return Inertia::render('Dashboard/Orders', [ 'orders' => $orders, ]);

The frontend receives the page name and props, then renders the matching Vue or React component. This gives teams the feeling of a modern JavaScript application without forcing them to build and maintain a completely separate frontend application from day one.

In simple terms, Laravel owns the product logic, Inertia connects the backend and frontend layers, and Vue or React powers the user interface.

Laravel stays responsible for the rules. Inertia handles the bridge. Vue or React turns the product logic into usable screens.

Laravel + Inertia + Vue as a Clean Product Stack

Laravel + Inertia + Vue is often a very natural choice for Laravel teams that already enjoy the Vue ecosystem. A typical stack may include Laravel, Inertia.js, Vue, TypeScript, Tailwind CSS, Vite, Pinia when shared frontend state is needed, and a component system such as PrimeVue, shadcn-vue, or a custom design system.

On the backend side, the application may use PostgreSQL or MySQL, Redis, Laravel Queues, Horizon, Filament, Nova, and integrations with third-party services. The important point is that Vue does not replace Laravel. Vue simply becomes the interface layer that renders product screens.

A Vue page in this setup can be simple and readable.

<script setup lang="ts"> defineProps<{ orders: Order[] }>() </script> <template> <section> <PageHeader title="Orders" /> <OrdersTable :items="orders" /> </section> </template>

The biggest advantage of Vue in this architecture is clarity. The template shows the page structure directly. A developer can scan the component and quickly understand what the user sees. The logic stays close to the interface, but it does not overwhelm the component.

This is one reason Laravel + Inertia + Vue works especially well for dashboards, forms, filters, tables, settings screens, account areas, admin panels, approval flows, and internal business workflows. These screens usually need clarity, stability, and maintainability more than experimental frontend architecture.

For example, a Laravel + Inertia + Vue Developer stack is a strong fit when the product needs a Laravel-controlled backend, responsive Vue screens, reusable UI components, and a support-friendly architecture after launch.

Laravel + Inertia + React as a Flexible UI Stack

Laravel + Inertia + React follows the same backend idea but uses React as the frontend layer. A typical stack may include Laravel, Inertia.js, React, TypeScript, Tailwind CSS, Vite, React hooks, shadcn/ui, Radix UI, PostgreSQL or MySQL, Redis, Laravel Queues, Horizon, and Filament or Nova when an admin layer is needed.

The Laravel controller can look almost identical to the Vue version. The difference is not in how Laravel prepares the data. The difference is in how the frontend page component is written and maintained.

type Props = { orders: Order[] } export default function Orders({ orders }: Props) { return ( <section> <PageHeader title="Orders" /> <OrdersTable items={orders} /> </section> ) }

React gives teams a large ecosystem, mature component patterns, strong TypeScript usage, and a broad hiring market. It is especially attractive when the product team already uses React, has an existing React design system, or expects to connect the project with a broader React or Next.js roadmap.

A Laravel + Inertia + React Developer stack makes sense when a client wants Laravel to remain the application authority while React powers dynamic product screens, SaaS dashboards, complex interfaces, and reusable UI components.

React is not automatically more complex, but it gives developers more freedom. That freedom is powerful when the team has strong frontend discipline. Without clear conventions, however, React projects can become harder to read and maintain over time.

What Both Stacks Have in Common

The backend architecture is almost the same in both versions. This is important because clients sometimes assume that choosing React instead of Vue changes the entire product architecture. In most Laravel + Inertia projects, that is not the case.

The data model, access rules, permissions, queues, integrations, admin workflows, and deployment strategy are still mostly Laravel decisions. Vue or React affects the interface layer, component structure, UI patterns, and frontend ecosystem.

Area	Laravel + Inertia + Vue	Laravel + Inertia + React
Backend framework	Laravel	Laravel
Routing	Laravel routes	Laravel routes
Controllers	Laravel controllers	Laravel controllers
Authentication	Laravel auth	Laravel auth
Authorization	Policies, gates, middleware	Policies, gates, middleware
Validation	Laravel validation	Laravel validation
Database	MySQL or PostgreSQL	MySQL or PostgreSQL
Queues	Laravel Queues / Horizon	Laravel Queues / Horizon
Cache	Redis	Redis
Frontend bridge	Inertia.js	Inertia.js
Build tool	Vite	Vite
Styling	Tailwind CSS	Tailwind CSS
TypeScript	Supported	Supported
SSR	Possible	Possible

The practical difference is in the frontend experience. Vue uses a template-based approach that many Laravel developers find easy to read. React uses JSX or TSX, hooks, and a JavaScript-first component model that gives teams a lot of flexibility.

Both approaches can be excellent. The better choice depends less on framework popularity and more on team experience, project requirements, UI complexity, and future roadmap.

Developer Experience Inside Inertia

From a developer perspective, the right question is not which framework is better in general. The better question is which framework creates less friction for this team and this product.

Criteria	Laravel + Inertia + Vue	Laravel + Inertia + React
Best team fit	Laravel and Vue teams	Laravel and React teams
Component style	Template-based	JSX / TSX-based
Readability	Very clear for UI structure	Very flexible, but can become dense
Forms	Simple and ergonomic	Powerful, sometimes more verbose
State patterns	Refs, computed values, composables, Pinia	Hooks, context, external libraries
UI ecosystem	Strong	Very strong
Design system options	PrimeVue, shadcn-vue, custom UI systems	shadcn/ui, Radix UI, custom UI systems
Hiring market	Smaller	Larger
Risk of overengineering	Lower	Medium
Best use cases	Dashboards, portals, business apps	Complex SaaS UI, React-first teams

Vue often feels faster for classic product screens: forms, dashboards, filters, tables, account settings, permissions, and admin flows. These are the screens where clarity and consistency matter more than frontend experimentation.

React often feels stronger when the product has highly interactive UI, a mature React component system, or a roadmap connected to Next.js. It is also attractive for organizations that already hire React developers and want to keep the frontend ecosystem consistent across multiple products.

In other words, Vue is often a smoother fit for Laravel-first product teams, while React can be the better fit for React-first organizations that also want Laravel as a reliable backend core.

Speed of Development on the Same Project

For the same product scope, the backend timeline is usually very similar. Imagine a B2B SaaS MVP with authentication, user roles, a dashboard, customer records, project records, tables with filters, forms with validation, file uploads, email notifications, an admin area, responsive UI, and basic reporting.

Laravel handles most of that work in almost the same way in both versions. The database schema, routes, controllers, validation, authorization policies, jobs, integrations, and deployment logic do not change much just because the interface uses Vue or React.

Backend Work	Vue Version	React Version
Database schema	Same	Same
Laravel routes	Same	Same
Controllers	Same	Same
Authentication	Same	Same
Validation	Same	Same
Policies	Same	Same
Jobs and queues	Same	Same
Integrations	Same	Same
Deployment	Same	Same

The timeline difference usually appears in the frontend layer. A Vue-oriented Laravel team may build common business screens faster with Vue because the structure is clear, the templates are readable, and form-heavy interfaces are comfortable to implement.

A React-oriented team may move just as fast with React, especially if it already has reusable components, shared hooks, a design system, and frontend conventions in place.

Frontend Work	Laravel + Inertia + Vue	Laravel + Inertia + React
Layouts	Fast	Fast
Basic pages	Very fast	Fast
Forms	Very fast	Fast, sometimes more verbose
Tables and filters	Fast	Fast
Modals and UI states	Simple	Flexible
Complex UI patterns	Good	Very good
Design system integration	Good	Excellent
Onboarding new developers	Usually easier	Depends on React experience

For a team already strong in Vue, Laravel + Inertia + Vue may be around five to fifteen percent faster for common business applications. For a team already strong in React, Laravel + Inertia + React can be just as fast.

The framework is not the only multiplier. Team experience, reusable components, design quality, product clarity, and decision-making speed often affect the timeline more than the frontend library itself.

Budget and Business Impact for Clients

Clients rarely care about whether a component is written as a Vue template or a React TSX function. They usually care about launch speed, budget, support, future flexibility, and risk.

For the same scope, Laravel + Inertia + Vue and Laravel + Inertia + React often have similar backend costs. The budget difference usually comes from frontend velocity, reusable components, hiring expectations, team familiarity, and the complexity of the design system.

Laravel + Inertia + Vue may reduce cost when the delivery team already works with Vue, the product has many forms and dashboards, the interface is business-heavy rather than animation-heavy, and the client wants a practical MVP without unnecessary separation between backend and frontend.

Vue can help keep the interface layer simple, especially in products where clarity matters more than frontend experimentation. That makes it a strong choice for client portals, dashboards, admin areas, workflow tools, and SaaS MVPs that need to move quickly from idea to production.

Laravel + Inertia + React may be the better budget decision when the client already has React developers, owns React components, depends on React-first libraries, or expects the product roadmap to move toward a React or Next.js ecosystem.

React may cost more for a Vue-first delivery team, but it can be cheaper for a React-first organization. Budget is not only about the framework. It is about organizational fit.

A stack is cost-effective when the team can build with it confidently, support it consistently, and evolve it without fighting the architecture.

Support and Long-Term Maintenance

A product is not finished when it launches. After launch, the real work begins. A production application needs bug fixes, new features, UI improvements, dependency updates, security updates, performance tuning, monitoring, integrations, reporting, and refactoring.

Both Vue and React can be maintained well inside a Laravel + Inertia application. Both can also become messy if the team has no structure.

Vue is often easier to scan because the template clearly shows what the user sees. This can make business screens easier to support, especially forms, admin pages, account areas, approval flows, filters, tables, settings, and dashboards. For smaller teams, this readability matters. A developer can open a Vue page and quickly understand the structure.

React is powerful, but it requires more discipline. A React Inertia project should define clear rules for component structure, hooks, layouts, form handling, shared UI components, state boundaries, table patterns, error states, loading states, and naming conventions.

When those rules exist, React is excellent. When every developer invents a new pattern, the frontend can become difficult to maintain. React does not create chaos by itself. Unclear architecture does.

For long-term maintenance, the most important factor is not just Vue or React. It is consistency. The team needs clear conventions, reusable components, predictable data flow, and a shared understanding of where business logic belongs.

SSR and SEO Considerations

Inertia can support server-side rendering, and SSR can help when selected routes need better first-load delivery or more indexable HTML. It can be useful for public landing pages, product pages, marketplace pages, directories, documentation, and public content pages.

However, SSR is not always necessary. For private product areas such as admin dashboards, CRM screens, internal tools, authenticated SaaS pages, staff workflows, and client portals, SEO is often not the main priority. In those cases, the user experience, permissions, performance, and maintainability are usually more important.

A practical way to think about this is simple: use Laravel + Inertia for product application screens, and use SSR selectively when first delivery or search visibility matters.

If SEO is the primary goal of the entire frontend, Nuxt or Next.js may be a better public-facing layer. But for many product applications, Inertia keeps the architecture simpler and easier to maintain.

When Laravel + Inertia + Vue Makes Sense

Laravel + Inertia + Vue is a strong choice when the product needs fast MVP delivery, clear business workflows, dashboards, portals, CRM-style screens, forms, validation, tables, filters, admin panels, internal tools, and strong alignment with the Vue or Nuxt ecosystem.

This stack is especially useful when the team already works with Vue. The main advantage is balance. Vue gives the frontend enough power without pushing the product into unnecessary complexity. Laravel keeps the server-side rules visible. Inertia keeps the connection between the two layers clean.

For many product teams, Laravel + Inertia + Vue development is a practical choice for launching business applications that need to be maintainable, understandable, and easy to evolve after release.

It is not only a developer-friendly stack. It is also a client-friendly stack because it can reduce architectural overhead, simplify support, and keep the product moving without forcing a separate API-first frontend too early.

When Laravel + Inertia + React Makes Sense

Laravel + Inertia + React is a strong choice when the product needs the React ecosystem, shadcn/ui components, a larger hiring pool, complex product UI, reusable React patterns, analytics interfaces, advanced dashboards, React-first team collaboration, or possible Next.js alignment later.

React is especially useful when the organization already thinks in React. It is also a good choice when product UI complexity is high and the team has enough frontend discipline to keep the codebase consistent.

A Laravel + Inertia + React development approach works well when Laravel needs to remain the backend authority while React supports rich product interfaces and scalable UI systems.

The most important thing is to avoid turning a Laravel + Inertia project into an unnecessarily complex pseudo-SPA with duplicate APIs, scattered state, and unclear responsibilities.

If Laravel is the product core, let Laravel stay the product core. React should strengthen the interface, not pull the architecture into avoidable complexity.

Pros and Cons

Both stacks have strong advantages and real trade-offs. The right decision depends on the team, the product type, the future roadmap, and the client’s support strategy.

Stack	Strengths	Trade-Offs
Laravel + Inertia + Vue	Fast for Laravel/Vue teams, clear component structure, strong for forms, dashboards, admin panels, SaaS MVPs, and internal tools.	Smaller hiring market than React, fewer React-first UI libraries, less ideal for clients already standardized around React.
Laravel + Inertia + React	Large ecosystem, strong hiring market, excellent UI component options, great fit for React-first product teams and complex SaaS interfaces.	Can become verbose, requires clear frontend rules, higher risk of overengineering, may be slower for Vue-first Laravel teams.

Decision Matrix

A practical decision matrix can help simplify the choice. It should not replace technical judgment, but it can clarify which direction is more natural for a specific project.

Situation	Recommended Stack
The team is already strong with Laravel and Vue	Laravel + Inertia + Vue
The team is already strong with React	Laravel + Inertia + React
The product is a fast SaaS MVP	Laravel + Inertia + Vue
The client already has a React design system	Laravel + Inertia + React
The product has many forms, tables, and business workflows	Laravel + Inertia + Vue
The product has complex interactive UI	Laravel + Inertia + React
The project needs a smaller long-term support team	Laravel + Inertia + Vue
The client needs a larger hiring pool	Laravel + Inertia + React
The roadmap is connected to Vue or Nuxt	Laravel + Inertia + Vue
The roadmap is connected to React or Next.js	Laravel + Inertia + React

A Product Engineering Perspective

Technology decisions should not be made by trend alone. A better question is: what architecture gives this product the best chance to launch, grow, and stay maintainable?

For many web products, Laravel + Inertia is valuable because it removes unnecessary duplication. You do not need two routing systems if one is enough. You do not need a full API layer if the frontend only serves the same application. You do not need a separate frontend product if the business logic, user roles, and permissions all belong inside one Laravel product core.

That does not mean APIs are bad. APIs are essential when the product needs mobile apps, third-party clients, public integrations, multi-platform delivery, or independent frontend teams.

But if the goal is to build a focused SaaS app, portal, dashboard, internal platform, or MVP, Laravel + Inertia can keep the system lean and understandable.

The Vue vs React decision should come after the architecture decision. First decide whether a modern Laravel monolith fits the product. Then choose the frontend layer that best matches the team and the roadmap.

A Practical Recommendation

There is no universal winner between Laravel + Inertia + Vue and Laravel + Inertia + React.

Choose Laravel + Inertia + Vue when you want speed, clarity, lower complexity, and strong alignment with a Laravel/Vue team. This is often the smoother default for business applications, dashboards, portals, admin systems, MVPs, and products where long-term support matters.

Choose Laravel + Inertia + React when you need the React ecosystem, hiring flexibility, shadcn/ui, complex UI patterns, or a React-first product roadmap. This is often the safer long-term choice for organizations that already use React across their product ecosystem.

The best stack is not the one with the loudest community. It is the one your team can build with, support, and evolve without fighting the architecture every week.

A good Laravel + Inertia application should feel simple in the right places. Laravel owns the rules. Inertia connects the layers. Vue or React powers the screens. The product stays understandable.

That is the real advantage: less duplication, faster delivery, clearer ownership, and a product architecture that can grow without becoming unnecessarily complicated.

Questions for the Community

I would love to hear how other Laravel teams approach this decision.

Which stack would you choose for a new Laravel product today: Vue or React?
Have you used Inertia in a production SaaS, dashboard, portal, or internal tool?
Do you prefer keeping Laravel as the main product core, or do you separate the frontend and backend from the start?
Where do you think Inertia fits best: MVPs, admin panels, SaaS apps, portals, or long-term enterprise products?
If the backend is Laravel, would your team move faster with Vue, React, or Livewire?

Share your experience in the comments. The most useful stack decisions usually come from real production projects, not from framework debates.

Modernizing Legacy Laravel Apps with Figma Agents, and Smarter Tests

VitaliiK — Thu, 25 Jun 2026 13:36:32 +0000

The biggest AI opportunity in web development might not be the next shiny app.

It might be the old one your company is afraid to touch.

Every day, businesses run on software that still works but no longer feels modern: old admin panels, internal CRMs, Laravel dashboards built years ago, Blade views nobody wants to refactor, reporting tools with confusing filters, support screens with too many columns, and customer portals that still make money but slow down every new feature.

That is where things get interesting.

Most AI conversations focus on building something new from scratch. A founder has an idea, generates a prototype, writes code with an AI assistant, connects a model API, and launches an MVP.

That is a real use case, and it matters.

But most software work does not start with a blank repository. It starts with an existing product, existing users, existing data, existing bugs, existing business rules, and years of decisions that made sense at the time.

AI is not just a startup accelerator.

It is becoming a modernization engine.

The next wave of AI in web development will not only be about launching new products faster. It will also be about upgrading the products companies already depend on.

The real opportunity is not another chatbot

A lot of “AI-powered” products follow the same pattern: take an existing app, add a chat window, and call it innovation.

That is not enough.

A support dashboard does not need a chatbot in the corner. It needs ticket summaries, priority detection, suggested replies, and better routing.

A CRM does not need a generic assistant. It needs account summaries, follow-up suggestions, risk signals, and smarter search.

An accounting tool does not need AI decoration. It needs invoice classification, document extraction, anomaly detection, and review workflows.

The best AI features do not feel like separate products. They feel like the existing product got smarter.

AI should not sit next to the product. AI should make the product better.

That is the key difference.

AI should remove friction from the workflow people already use every day. It should reduce repetitive work, surface useful context, help users make decisions faster, and keep humans in control where judgment matters.

There are two AI development paths now

AI is changing product development in two very different ways.

The first path is greenfield development. This is the startup path. You begin with an idea, write a product brief, explore the interface in Figma, create a functional prototype, validate the flow with users, then build the real application with Laravel, an AI coding agent, and the Laravel AI SDK.

This is powerful because the cost of going from idea to working product has dropped dramatically.

The second path is brownfield modernization. This is the path most real companies need. You already have a working product. Maybe it is profitable. Maybe users rely on it every day. But the UI feels outdated, the codebase has too many patterns, the product is hard to extend, and every improvement feels risky.

This path is not about moving fast and breaking things.

It is about improving one valuable workflow at a time without breaking the business.

Same tools. Different mindset.

For a new product, the question is: how quickly can we validate this idea?
For an existing product, the question is: how can we make this system better without turning modernization into a six-month rewrite?

AI helps with both, but the second opportunity may be much larger.

Start with the workflow, not the model

The biggest mistake teams make is starting with the tech stack.

They ask which model to use, which IDE assistant is better, whether to use React or Livewire, whether they need vector search, or whether they should build an agent.

Those questions matter, but they are not the starting point.

The starting point is the workflow.

What does the user do every day?
Where do they waste time?
Where do they copy and paste?
Where do they wait?
Where do they make mistakes?
Where do they need context before making a decision?
Which part of the workflow is repetitive enough to automate but important enough to improve?

“Modernize our app” is too vague.

“Help support managers review, prioritize, and respond to tickets faster” is specific.

That kind of problem gives every tool a clear job.

Figma helps rethink the user experience. Figma Make helps test the improved flow before production work starts. Figma MCP helps move real design context into the coding environment. An AI coding agent helps inspect the existing codebase and implement focused changes. Laravel provides the application structure. Laravel AI SDK adds intelligent behavior where it actually belongs.

That is a real workflow.

Figma agents are becoming real product tools

Figma’s recent AI updates are important because the agent is no longer just a prompt box that creates a few screen ideas.

Figma has been expanding its design agent with more context, custom tools, reusable skills, and deeper connections to design and development workflows. This direction moves beyond simple prompting toward agents that understand how a team works, use broader project context, and help create reusable tools directly on the canvas.

For modernization work, this matters because context is everything.

If you are redesigning an old support dashboard, you do not want a random “modern SaaS UI.” You want a better version of the actual workflow your team already uses.

That means the agent should understand the current screen, the design system, user feedback, accessibility rules, product requirements, and the business goal behind the redesign.

This is where Figma’s agent becomes useful. It does not replace the designer. It helps the team move from vague feedback to concrete options faster.

Instead of starting from a blank canvas, a team can explore several improved versions of the same workflow, compare them, clean up the hierarchy, standardize components, and create better empty, loading, and error states.

The goal is not to make the old screen prettier.

The goal is to make the workflow easier to understand and faster to use.

Code layers make design and code feel closer

Another important Figma update is code layers.

Code layers bring interactive code onto the Figma canvas. Teams can create a code layer from a frame, ask the Figma agent to generate one, bring in a repository, or upload a local folder. This creates workflows where teams can compare, refine, and update code layers alongside normal design work.

This is especially interesting for legacy products.

Historically, modernization projects often started with screenshots of the old product. Screenshots are useful, but they are dead artifacts. They do not show real behavior, real state, real components, or the connection between design and implementation.

Code layers make the design conversation more practical.

Designers, developers, and product managers can compare the current experience with a proposed future experience in a more interactive way. They can discuss what is purely visual, what requires frontend work, and what depends on backend logic.

This does not mean Figma becomes your production IDE.

It means the gap between “what exists,” “what we designed,” and “what we plan to build” gets smaller.

Figma MCP reduces design-to-code guesswork

Design-to-code has always had a translation problem.

A designer creates a screen. A developer interprets it. Something gets lost. Spacing changes. Components get duplicated. States are forgotten. A table gets rebuilt from scratch even though the app already has one. A modal looks almost like the design system, but not quite.

AI can make this worse if it only works from screenshots or vague prompts.

That is why the Figma MCP Server matters.

Figma MCP can provide AI agents with design context from Figma files, including selected frames, components, variables, layout data, and resources from Figma Make files.

For modernization, the coding agent needs to understand two worlds at the same time:

the existing Laravel application;
the new Figma design direction.

If the agent only understands the old code, it may preserve outdated UI patterns. If it only understands the new design, it may produce code that does not fit the actual application.

But when it has both design context and codebase context, it can make more precise changes.

That is when AI becomes useful in real projects.

Not as a magic generator, but as a context-aware assistant.

Code Connect helps prevent component chaos

One of the easiest ways to damage a codebase with AI is to let it create duplicate components.

A new button. A new card. A new modal. A new table. A new dropdown. A new form pattern.

None of them are terrible alone, but together they create a maintenance problem.

After a few weeks, the app may look “AI-modernized,” but the codebase is harder to maintain than before.

Code Connect helps by linking Figma components to real code components. It connects design components with their implementation in code, which helps teams keep design and engineering aligned.

The button in Figma should map to the real button in code. The modal should use the existing modal. The table should follow the existing table pattern. The badge should not be recreated five different ways.

In a new product, this keeps things clean from the beginning.

In a legacy product, it is even more important because modernization should reduce inconsistency, not add more.

AI agents need boundaries. A connected design system gives them those boundaries.

AI in PhpStorm and other IDEs belongs in the real developer workflow

After the new flow is validated in Figma, the work moves into the IDE.

For PHP teams, PhpStorm is one of the most natural places for AI-assisted development. JetBrains AI Assistant supports modern PHP development workflows such as generating and explaining PHP code, multi-file edits, intelligent completion, and AI chat with project context.

JetBrains also has Junie, an AI coding agent that can work in code mode to execute tasks and in ask mode to collaborate on plans and questions.

If your team does not use PhpStorm, the same workflow can work with alternatives such as Cursor, Claude Code, or GitHub Copilot.

The specific tool matters less than the operating model.

A bad prompt is:

Refactor this dashboard.

A better request is:

Explain how this workflow works today. Identify its routes, controllers, models, policies, frontend components, jobs, and tests. List the business rules that must be preserved. Then propose a modernization plan without editing any files.

The agent’s first job should be understanding, not implementation.

After the plan is reviewed, let it change one vertical slice at a time. A ticket detail screen is a reasonable task. An entire support system is not.

Laravel now has an AI stack, not just an AI package

Laravel is especially interesting in this workflow because it has structure.

Routes have a place. Controllers have a place. Models have a place. Migrations have a place. Policies have a place. Jobs have a place. Tests have a place.

That structure helps humans, but it also helps AI agents.

Laravel’s AI tooling now operates at several layers.

Laravel Boost helps AI coding agents write better Laravel code by giving them Laravel-specific context, guidance, and project-aware tools.

Laravel AI SDK helps developers build AI features inside Laravel applications. It provides a Laravel-native way to build AI-powered features with providers, agents, tools, structured output, embeddings, vector workflows, and more.

Laravel MCP helps AI clients and agents interact with tools and resources exposed by Laravel applications. Laravel AI agents can also connect to MCP servers and work with external systems.

These tools solve different problems:

Boost helps AI write the application.
AI SDK helps the application use AI.
MCP helps AI interact with the application and external systems.

A production project may use all three, but it should not install all three simply because they exist.

Start with the workflow. Then choose the tool.

AI can help with framework upgrades too

Legacy modernization is not only about redesigning screens.

It often includes framework upgrades, package updates, new PHP versions, deprecated APIs, test-suite changes, and cleanup around old patterns.

AI-assisted upgrade workflows can help teams compare package versions, follow official upgrade guidance, update repetitive code, run the test suite, and report what still fails.

That does not make an upgrade automatic or risk-free.

An AI agent cannot know every undocumented production dependency, every unusual database record, or every client-specific behavior.

But it can turn an upgrade from a manual search-and-replace exercise into a structured engineering loop.

The team still owns the final diff.

Tests are the safety system for AI-assisted modernization

AI is useful in legacy work only when it makes change safer.

Before asking an agent to refactor old code, use it to help document and test the existing behavior.

These are often called characterization tests: they capture what the application does today, including behavior the team may not fully understand.

For an old support dashboard, that might include authorization rules, filters, sorting, ticket assignments, status transitions, notifications, exports, and tenant isolation.

Once those behaviors are protected, the agent can refactor with a clear signal when something breaks.

AI assistants can help generate unit tests in the IDE and show proposed test code for review.

But this part is important: an AI-generated test is not automatically a good test.

Sometimes the test simply repeats the same wrong assumption as the generated code. Sometimes it tests implementation details instead of behavior. Sometimes it misses authorization, edge cases, failure states, or multi-tenant boundaries.

The developer still needs to ask:

Is this testing behavior or implementation details?
Does it cover authorization?
Does it cover another tenant trying to access the record?
Does it cover invalid and incomplete data?
Does it cover failure and retry states?
Would this test have caught the original bug?
Did the agent weaken an assertion just to make the suite pass?

The goal is not more tests.

The goal is more confidence.

Laravel PAO makes the test loop better for agents

Laravel recently introduced PAO, or PHP agent-optimized output.

Test runners and analysis tools normally produce terminal output designed for humans: colors, progress dots, tables, warnings, and decorative formatting.

That output can waste context and make it harder for an AI agent to locate the actual failure.

Laravel PAO returns compact, structured output for supported commands when they are being run by an AI agent.

This sounds like a small feature, but it improves the most common agent loop:

Run the tests.
Find the failure.
Edit the relevant code.
Run the tests again.

When an agent receives the failing assertion, file, line number, and error details directly, it spends less time interpreting terminal noise and more time solving the actual problem.

AI features need their own testing strategy

Adding an AI-powered feature creates a second testing problem.

The application logic may be deterministic, but the model output is not.

Suppose the modernized support dashboard includes an AI-generated ticket summary. A normal test should not call a live provider and compare the exact paragraph returned by the model. That would be slow, expensive, and unreliable.

Instead, the regular application suite should test deterministic boundaries:

Was the correct agent invoked?
Was the job dispatched?
Was tenant authorization enforced?
Was the result stored in the correct record?
Did the response match the expected structured schema?
Was the failure state handled?
Was an automatic action blocked until human approval?

Laravel AI SDK includes testing helpers such as fakes and assertions for AI operations, allowing teams to test application behavior without making uncontrolled live model calls.

Model quality should be evaluated separately.

Keep a small set of representative examples and expected qualities: correct category, acceptable summary, no invented facts, no cross-tenant data, appropriate escalation, and no unsafe action.

Unit tests protect the application.

Evaluations protect the AI behavior.

You need both.

A practical modernization flow

Imagine an old customer-support dashboard built in Laravel.

It still works, but the ticket table has too many columns, filters are inconsistent, the detail page is difficult to scan, and support managers spend too much time reading repetitive requests.

A practical AI-assisted modernization flow could look like this.

1. Protect the current behavior

Before redesigning anything, map the existing route, controller, policies, database queries, frontend components, jobs, and notifications.

Ask the coding agent to identify missing coverage, then add characterization tests for the behavior users depend on.

Do this before the refactor, not after it.

2. Redesign the workflow with Figma’s agent

Bring the current interface, user feedback, support metrics, design system, and project requirements into Figma.

Ask the agent to explore a cleaner ticket inbox and a more focused ticket detail page.

Create reusable rules or skills that enforce the team’s component, accessibility, and layout standards.

The goal is not a beautiful concept.

The goal is a better working day for the support team.

3. Validate the interaction

Use Figma Make or code-layer workflows to create a working version of the new flow.

Let real support managers use it.

Watch where they hesitate. Check whether the AI summary helps or distracts. Confirm which information they need before approving a suggested response.

Fix the workflow before rebuilding the backend.

4. Connect the design to the real codebase

Use Figma MCP to provide the selected design context to the coding agent.

Map important design components to production components with Code Connect.

The agent should know which table, button, modal, badge, and form components already exist.

5. Implement one vertical slice

In PhpStorm with Junie, or in Cursor, Claude Code, or GitHub Copilot, ask the agent to inspect the existing implementation and propose a plan.

Start with the ticket detail page. Keep the old route available. Ship the new version behind a feature flag. Run the existing and newly generated tests after every meaningful change.

Do not modernize the entire support module in one task.

6. Add one narrow AI feature

Once the new workflow is stable, add ticket summarization through Laravel AI SDK.

Do not begin with full automation. The first version can summarize the request, classify it, suggest urgency, and draft a response for human approval.

That is useful, measurable, and relatively safe.

7. Test, release, and measure

Fake model responses in the normal test suite. Evaluate model quality separately. Use agent-friendly test output to improve the feedback loop. Release the new workflow to a small group and measure review time, error rate, adoption, and support-team feedback.

Then decide whether the next investment should be smarter routing, suggested replies, better search, or simply another redesigned screen.

Guardrails matter more than prompts

A coding agent working in a legacy product should have explicit boundaries.

It should not rewrite unrelated files.
It should not introduce a new frontend framework without approval.
It should not create duplicate components.
It should not change the database schema without a migration and rollback plan.
It should not weaken tests to make them pass.
It should not bypass policies or tenant boundaries.
It should not send sensitive production data to an external model without an approved data policy.

The agent can inspect, plan, implement, run tests, and review the diff.

The team still owns the architecture, security, product decisions, and release.

That is the real AI modernization stack: not one model and not one magic prompt, but a connected workflow with context at every stage.

Figma’s agent helps the team rethink the experience. Figma MCP and Code Connect carry design intent into development. PhpStorm, Junie, Cursor, Claude Code, or GitHub Copilot help engineers understand and change the codebase. Laravel Boost gives those agents framework-specific context. Laravel AI SDK adds useful intelligence to the product. Tests, fakes, evaluations, and agent-friendly output keep the process under control.

The goal is not to generate more code.

The goal is to improve valuable software without putting the business at risk.

At Kavita Systems, we help teams modernize existing web products, improve legacy Laravel workflows, and introduce practical AI features without committing to a risky full rewrite.

Need to understand where AI can create value in your existing product?

Laravel 13 Makes the “AI Means Python” Argument Weaker

VitaliiK — Wed, 24 Jun 2026 12:07:59 +0000

For a long time, adding AI to a Laravel product usually meant one thing: you had to bring another service into the stack.

The architecture often looked like this:

At first, this setup feels reasonable.

Laravel handles the product. Python handles the AI. FastAPI or Flask sits in the middle. The bridge sends text to an embeddings service, talks to a vector database, calls an LLM provider, and sends the answer back.

For a prototype, that is fine.

For a demo, it may even look impressive.

But then the product goes live.

And suddenly that “small Python bridge” is not small anymore. It needs deployment, monitoring, logs, retries, permissions, rate limits, error handling, security reviews, and someone on the team who understands why a payment flow in Laravel now depends on a Python service nobody wants to touch.

The problem was never Python itself.

The problem is using Python as a bridge only because Laravel used to have no native way to deal with AI workflows.

That is changing.

With Laravel 13 and the Laravel AI SDK, many things that previously required a separate Python service can now live inside the Laravel application: agents, tools, embeddings, vector search, RAG workflows, and AI provider orchestration.

Laravel also supports vector columns in PostgreSQL through pgvector, so semantic search can sit much closer to your Eloquent models, policies, queues, and business logic.

This does not mean Python is dead.

It means the Python bridge is no longer the default answer.

The Problem Was Never Python

Python is still great for machine learning research, notebooks, model training, data science, experiments, and custom ML pipelines.

If your team is training models or building research-heavy AI infrastructure, Python probably still belongs in your stack.

But most product teams are not doing that.

Most product teams want something much more practical.

They want to search a product catalog by meaning. They want to answer questions using internal documentation. They want to explain payment errors, help users book a service, prepare a stock order, summarize support tickets, or route a request to the right workflow.

That is not machine learning research.

That is application engineering.

And application engineering is exactly where Laravel is strong.

The real question is not:

Can Python do this?

Of course it can.

The better question is:

Do we need a separate Python service only to call an LLM, generate embeddings, search vectors, and trigger business workflows?

In many Laravel products, the answer is now: no.

What We Are Actually Killing

We are not killing Python.

We are killing an awkward split in the architecture.

Think about a real product.

Laravel knows the user. Laravel knows the order. Laravel knows the permissions. Laravel knows the payment state. Laravel knows the booking rules. Laravel knows the audit log.

But then we ask a separate Python service to make the AI decision.

That split feels wrong because the AI layer is not floating somewhere outside the product. It is supposed to help the product make better decisions, explain things better, and guide users through existing workflows.

If the business logic already lives in Laravel, the AI workflow should be close to that business logic.

With a native Laravel AI stack, the architecture becomes much easier to understand:

The user talks to the Laravel application. The Laravel application calls an AI agent. The agent uses allowed tools. The tools call Eloquent models, external APIs, policies, queues, and services. The LLM helps understand language, but Laravel still controls the workflow.

That means one codebase, one permission model, one deployment pipeline, one logging system, and one team that can understand the full flow.

That is the real win.

RAG Is Not Just “Chat With PDF”

A lot of people still imagine RAG as a chatbot that reads PDFs.

That is the beginner version.

In a real product, RAG is more useful than that. It is a way to give the AI the right business context before it answers or acts.

That context can come from many places:

But here is the important part: RAG should not become your source of truth.

RAG is great for finding, explaining, comparing, summarizing, and suggesting.

But real product actions still belong to your domain APIs.

An AI agent can help a user choose a laptop. But the catalog API must confirm the actual price and inventory.

An AI agent can explain a cancellation policy. But the booking API must confirm whether this specific reservation can still be canceled.

An AI agent can prepare a stock order. But the brokerage system must execute it only after confirmation, risk checks, and compliance rules.

This is the line that matters:

AI can help the user understand and prepare the action. The backend must still validate and execute the action.

Why Native Vector Search Matters

Before native vector support, adding AI search to Laravel usually meant adding more infrastructure.

You had Laravel for the product, FastAPI for the bridge, LangChain or custom orchestration for the AI flow, OpenAI or another model provider, Pinecone or another vector database, Redis or queues, custom sync jobs, and custom observability.

That is a lot of moving parts for a feature that may start with one simple question:

Can users search our data by meaning instead of exact keywords?

Now many teams can start much simpler.

For example, a product table can store an embedding directly in PostgreSQL:

<?php

Schema::ensureVectorExtensionExists();

Schema::create('products', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->text('description');
    $table->json('attributes')->nullable();

    $table->vector('embedding', dimensions: 1536)->index();

    $table->timestamps();
});

And semantic search can stay inside Eloquent:

<?php

$products = Product::query()
    ->where('is_active', true)
    ->whereVectorSimilarTo(
        column: 'embedding',
        value: 'a lightweight laptop for Figma, coding, and video calls',
        minSimilarity: 0.55,
    )
    ->limit(10)
    ->get();

This is not only about writing fewer lines of code.

It is about keeping search close to your existing models, filters, tenant scopes, policies, queues, and database logic.

When retrieval lives inside the same application, it is easier to reason about who can see what, what should be indexed, and what should never be exposed to the model.

Example 1: E-Commerce Search That Understands Human Requests

Traditional product search works well when the user knows exactly what they want:

iPhone 15 Pro 256GB
Nike Air Max size 10
Logitech MX Master 3S

But real users do not always search like that.

Sometimes they write:

I need a gift for someone who travels a lot.

Find me a laptop for design work and Laravel development.

Show me something useful for a home office under $300.

Keyword search can easily miss the intent behind these requests.

Semantic search works better because it compares meaning, not just words.

A product search tool can look like this:

<?php

final class SearchProductsTool
{
    public function handle(string $query, ?int $maxPrice = null): array
    {
        return Product::query()
            ->where('is_active', true)
            ->when($maxPrice, fn ($q) => $q->where('price', '<=', $maxPrice))
            ->whereVectorSimilarTo(
                column: 'embedding',
                value: $query,
                minSimilarity: 0.55,
            )
            ->limit(10)
            ->get([
                'id',
                'name',
                'price',
                'short_description',
            ])
            ->toArray();
    }
}

Now the user can say:

I need a compact gift for a colleague who flies twice a month.

The system can return travel adapters, power banks, compact headphones, laptop sleeves, or carry-on accessories even if the user never typed those exact words.

That is not just a “cool AI feature.”

That is a better shopping experience.

Example 2: Booking Systems Where AI Understands the Intent

Booking platforms are full of rules.

Cancellation windows. Slot availability. Deposits. Staff schedules. Seasonal prices. Minimum duration. No-show rules. Different policies for different services.

Users do not want to read all of that.

They want to ask simple questions:

Can I book a massage for two people this Saturday after 4 PM?

Find me an apartment in Lviv for the weekend with parking and free cancellation.

Can I cancel my booking if check-in is tomorrow?

AI is useful here because it can translate messy human language into a clean backend workflow.

It can search the policy documents, understand the request, and call the booking API to check real-time availability.

<?php

final class CheckAvailabilityTool
{
    public function handle(array $payload): array
    {
        return app(BookingApi::class)->availableSlots(
            service: $payload['service'],
            date: $payload['date'],
            guests: $payload['guests'] ?? 1,
            after: $payload['after'] ?? null,
            maxPrice: $payload['max_price'] ?? null,
        );
    }
}

A healthy booking flow should look like this:

The AI should not randomly finalize a reservation.

It should not guess dates. It should not ignore cancellation rules. It should not bypass your booking engine.

AI helps the user move faster.

Laravel still owns the transaction.

Example 3: Payments, Banking, and Stock Orders

Financial workflows are where AI needs the shortest leash.

A user might say:

Buy $500 worth of Apple stock if the fee is under $2.

Can I pay this invoice from my business account?

Why was my card payment declined?

AI can help with all of these requests.

But it should not directly move money without confirmation.

In payments, banking, and brokerage systems, the AI should usually do three things: explain what is happening, prepare the next step, and verify the conditions.

It should not silently execute a payment, bank transfer, refund, or stock trade.

A safer brokerage flow looks like this:

User asks to buy stock.
AI checks account status.
AI gets quote and estimated fees.
AI checks available balance.
Laravel creates a pending trade.
User reviews and confirms.
Backend executes the trade.

The AI-facing tool should create a pending trade, not execute the order:

<?php

final class CreatePendingTradeTool
{
    public function handle(string $symbol, float $amount): array
    {
        Gate::authorize('createTradeIntent', auth()->user());

        $quote = app(BrokerageApi::class)->quote($symbol);
        $fees = app(BrokerageApi::class)->estimateFees($symbol, $amount);

        $trade = PendingTrade::create([
            'user_id' => auth()->id(),
            'symbol' => $symbol,
            'amount' => $amount,
            'quote_snapshot' => $quote,
            'estimated_fees' => $fees,
            'status' => 'awaiting_confirmation',
        ]);

        return $trade->toArray();
    }
}

The final execution should stay inside the normal backend flow, with transactions, risk checks, policies, and audit logs.

The same idea applies to payments.

AI can create a payment intent. AI can explain why a transaction failed. AI can suggest another payment method.

But it should not bypass 3DS, fraud checks, limits, compliance rules, or explicit user confirmation.

That is not an AI limitation.

That is responsible engineering.

How to Put It Together in Laravel

A clean Laravel AI architecture can be organized around agents and tools.

The agent understands the user request. The tools define what the AI is allowed to do. Laravel services handle the real business logic.

Agents: CommerceAgent, BookingAgent, BankingAssistantAgent.
Tools: SearchProductsTool, CheckAvailabilityTool, CreateReservationHoldTool, CreatePaymentIntentTool, CreatePendingTradeTool, SearchPolicyDocumentsTool.
Services: CatalogApi, BookingApi, PaymentGateway, BrokerageApi, RiskService.
Models: Product, Booking, Payment, PendingTrade, PolicyDocument.

The most important idea is simple:

An AI agent should not be a god object. It should be a controlled interface between the user, the LLM, and your backend.

For example, a commerce agent may be allowed to search products, check delivery availability, create reservation holds, and prepare payment intents.

But it should not be allowed to execute payments, trades, refunds, or final bookings without explicit confirmation and server-side validation.

This is the mental model:

The LLM understands the request.
The agent decides which tools are allowed.
The tools call the real backend.
Laravel enforces permissions and policies.
The user confirms critical actions.
The system logs everything.

That is production architecture.

Not magic.

The Three-API Pattern

Most useful AI products are not just “LLM plus database.”

They are integrations.

This is where Laravel third-party API integration becomes more than a technical task. It becomes the layer that connects AI intent with real product systems: marketplaces, booking engines, payment gateways, banking APIs, and brokerage platforms.

Imagine an AI-powered commerce platform with three external APIs:

Marketplace API: products, prices, inventory, and attributes.
Booking API: delivery slots, appointments, and reservations.
Payment, banking, or brokerage API: payment intents, balances, fees, and stock orders.

Without AI, the user has to move through all these systems manually.

With AI, the user can simply say:

Find me a laptop for design work under $1,500, deliver it Friday evening, and prepare the payment from my business card.

The system can break this into a structured flow:

Run semantic product search.
Check inventory and current price.
Check delivery slot availability.
Create a payment intent.
Ask the user for confirmation.
Place the final order.

This is where AI becomes valuable.

Not because it replaces developers.

Because it turns messy human intent into structured backend operations.

When Dedicated Vector Databases Still Make Sense

PostgreSQL with pgvector is a great starting point for many Laravel applications.

It keeps the stack simple and keeps the data close to the domain model.

But dedicated vector databases are not going away.

Pinecone, Milvus, Qdrant, Weaviate, and similar systems can still make sense if you deal with very large vector datasets, advanced hybrid search, complex multi-tenant indexing, or an existing AI/search infrastructure.

In that case, Laravel can still remain the main application. The only difference is that your tool calls an external vector-store adapter instead of Eloquent.

The point is not “never use external vector databases.”

The point is:

Do not add another runtime, another service, and another deployment pipeline unless the product actually needs it.

Start simple.

Scale when the data proves you need to scale.

Production Checklist

AI in production is not only about prompts.

It is mostly about boring engineering.

And boring engineering is exactly what keeps AI features safe.

Use idempotency keys

Payment creation, booking holds, refunds, and trade intents must be idempotent.

If the model retries a tool call, the system should not create two payments, two bookings, or two stock orders.

Separate read tools from write tools

AI can have many read tools, but write tools should be limited.

Critical actions need explicit user confirmation.

Log every tool call

You should know what the user asked, what context was retrieved, what tool was selected, what input was sent, what output came back, what the model answered, and what action was finally executed.

This matters for debugging. In finance, healthcare, e-commerce, and other sensitive products, it matters even more.

Enforce Laravel policies

The AI agent must never become a permission bypass.

If the user cannot access a booking, invoice, account, payment, or trade manually, the AI should not access it either.

Queue expensive work

Embedding generation, document parsing, catalog reindexing, policy updates, and large sync jobs should run in queues.

Do not block the user because the system is rebuilding vectors.

Never trust RAG for real-time facts

RAG can retrieve policy context.

But real-time values must come from real systems:

Price comes from the Catalog API.
Availability comes from the Booking API.
Balance comes from the Banking API.
Fees come from the Brokerage API.
Payment state comes from the payment gateway.

Require confirmation for money movement

Payments, refunds, bank transfers, and stock purchases should always require explicit confirmation.

AI can prepare the action. The backend executes it. The user approves it.

What This Means for PHP Teams

For years, PHP developers heard the same story:

AI is Python territory.

PHP is for websites and CRUD.

If you want AI, build a Python service.

That story is outdated.

Modern PHP applications are not just templates and forms.

They run marketplaces, CRMs, fintech products, booking platforms, SaaS dashboards, internal tools, support systems, and high-volume APIs.

These are exactly the kinds of products where AI agents, RAG, semantic search, and workflow automation can create real value.

And many of those systems already live in Laravel.

So the AI layer should not automatically be outsourced to a separate Python bridge.

It should live where the business logic already lives.

When Python Still Belongs in the Architecture

Python still has an important role.

Use Python when you are training models, running notebooks, building custom ML pipelines, doing offline analytics, processing large data science workloads, experimenting with open-source models, or building specialized NLP and computer vision systems.

But do not use Python only because the industry got used to saying “AI equals Python.”

If all you need is LLM calls, embeddings, RAG, vector search, agents, tool calling, and business workflow orchestration, Laravel is now a serious option.

And in many product teams, it may be the cleaner option.

The Bottom Line

The future of AI in business applications is not a chatbot sitting somewhere beside the product.

The future is AI built directly into the workflows people already use.

In eCommerce, that means an assistant that understands product catalogs, inventory, return rules, and what the customer is actually trying to buy.

In booking platforms, it means an assistant that can read availability, pricing rules, cancellation policies, time slots, and user constraints before suggesting the next step.

In payments, banking, or brokerage products, it means AI that can explain failures, prepare safe actions, clarify intent, and support decisions without bypassing validation, permissions, or compliance.

That kind of AI does not need to live in a separate Python bridge by default.

It needs to live close to your models, policies, queues, APIs, transactions, logs, permissions, and users.

In other words, production AI needs to live inside the application layer where your business logic already works.

For PHP and Laravel teams, that changes the conversation.

One codebase.
One language.
One deployment pipeline.
One observability stack.
One place for business rules, permissions, and audit logs.
Zero unnecessary bridge services.

Kill the unnecessary Python bridge.

Not because Python is bad.

_But because production AI belongs where your product logic, user data, permissions, APIs, and business workflows already live.
_