DEV Community: Paul-S

The Flutter Upgrade Passed CI. Plugins Failed on Device

Paul-S — Wed, 30 Sep 2026 11:25:51 +0000

The upgrade pipeline looked perfect.

flutter analyze                         PASS
flutter test                            PASS
flutter build apk --release             PASS
flutter build ios --release --no-codesign PASS

The pull request was approved. The new build reached the testing team.

Then the device reports arrived.

Android: Push notifications never register
iOS: Sign-in returns to a blank screen
Both: Unit tests remain green

CI had not lied. It had successfully tested what we asked it to test.

The problem was what we never asked it to test.

A Green Build Does Not Prove Plugin Behaviour

Most Flutter applications are not entirely Flutter.

A plugin usually contains a Dart-facing API and a native implementation written in Kotlin, Java, Swift, or Objective-C. The two sides communicate through platform channels or native bindings.

That creates a longer execution path:

Dart code
   ↓
Platform channel
   ↓
Plugin registration
   ↓
Android or iOS lifecycle
   ↓
Native SDK

A Dart unit test may validate the first layer while never loading the remaining four.

Flutter’s documentation explains that plugin unit tests often replace the platform implementation with mocks. That is useful for testing application logic, but a mocked method channel cannot reveal that a native class failed to register or an operating-system callback stopped firing.

The test passes because the native failure never enters the test process.

Framework Upgrades Move Native Boundaries Too

A Flutter upgrade is rarely just a Dart SDK change.

On Android, it can affect the Android Gradle Plugin, Gradle itself, Java compatibility, Kotlin configuration, manifest handling, and plugin build scripts.

Recent Flutter migration guidance illustrates this clearly. Built-in Kotlin support changes how Android projects and plugins are configured, while add-to-app projects may require manual migration because Flutter cannot rewrite the native host application automatically.

On iOS, the move toward the UIScene lifecycle changes where application events are delivered. Plugins relying on older AppDelegate callbacks may compile correctly but fail when the application receives a URL, notification, or lifecycle event on a real device.

Compilation answers one question:

Can these files become an application?

It does not answer another:

Will every native capability behave correctly when the operating system invokes it?

Debug the Boundary, Not Just the Dart Exception

When a plugin fails after an upgrade, the Dart error is often the end of the trail rather than the beginning.

A MissingPluginException, frozen method call, or empty callback could originate from several places:

The plugin was not registered with the current engine.
The Android activity or iOS scene changed before a callback returned.
A required manifest entry, entitlement, or permission is missing.
The plugin supports debug builds but fails after release optimization.
Its native dependency is incompatible with the new build toolchain.
The plugin’s Dart package was updated without a matching native migration.

Start by reproducing the failure on one known device. Then inspect native logs through Android Studio, adb logcat, Xcode, or the macOS Console.

Follow one call across the boundary:

Did Dart send the method call?
Did the native handler receive it?
Did the operating system start the requested action?
Did the callback return?
Did Flutter receive the result?

This is usually faster than repeatedly changing Dart code around a native failure.

Put Plugin Workflows Into the Upgrade Gate

A better upgrade pipeline includes tests that launch the application on the platforms it supports.

Flutter’s integration_test package can run tests on emulators, simulators, physical devices, and device farms. Use it for critical workflows that depend on plugins, such as:

Authentication redirects
Camera and file access
Push-notification registration
Payments and in-app purchases
Deep links and app links
Location and background services

Do not test only the happy path.

Deny a permission and request it again. Put the app in the background during a callback. Launch it from a notification. Open a deep link after the process has been terminated. Run the signed release build, not only the debug build.

The minimum upgrade evidence should look closer to this:

Static analysis                 PASS
Dart unit tests                 PASS
Android release build           PASS
iOS release build               PASS
Android plugin workflows        PASS
iOS plugin workflows            PASS
Background and cold-start tests PASS

CI is still important. It simply needs coverage beyond compilation.

Change the Definition of “Upgrade Complete”

An upgrade is not complete when flutter build exits with code zero.

It is complete when the application’s important native paths have been exercised on Android and iOS, using the build modes and operating-system behaviours customers will actually encounter.

That may reveal that a plugin must be upgraded, patched, replaced, or temporarily pinned. It may also expose a missing native migration in the application itself.

This is the kind of evidence teams should expect from a hybrid app development company: not only a green pipeline, but a clear device matrix showing which plugin-backed workflows were tested.

The Flutter upgrade passed CI because the pipeline proved that the project could build.

The plugins failed because the application had not yet proved that it could run.

Which Flutter plugin has caused your most difficult device-only failure?

I Built a Laravel Agent That Must Ask Permission

Paul-S — Mon, 28 Sep 2026 11:59:36 +0000

The agent had already done the difficult work.

It found the customer’s order, checked the payment status, read the refund policy, and calculated the amount.

Then it proposed this:

Action: Issue refund
Order: ORD-1842
Amount: $129.00
Reason: Customer received a damaged product

The calculation looked reasonable. The customer qualified for a refund.

I still did not want the model pressing the final button.

A refund changes real business data and moves money. The agent could recommend the action, but a person needed to approve it.

The Dangerous Line Was One Method Call

My first version exposed an IssueRefund tool directly to the agent.

The instructions included a sentence like:

Always ask a manager before issuing refunds above $25.

That sounded safe until I considered what enforced it.

The same model deciding to issue the refund was also responsible for remembering when it needed permission. A changed prompt, incomplete conversation, or different model response could bypass that instruction.

The permission boundary belonged in PHP.

Laravel released AI SDK v1.0 on September 23, 2026. Among its production features is human approval for agent tools. An approvable tool pauses before its handle() method executes.

That was the behavior I needed.

Making the Refund Tool Approvable

Here is a simplified version of the tool:

<?php

namespace App\Ai\Tools;

use Illuminate\Contracts\JsonSchema\JsonSchema;
use Laravel\Ai\Approvals\Approval;
use Laravel\Ai\Concerns\InteractsWithApprovals;
use Laravel\Ai\Contracts\Approvable;
use Laravel\Ai\Contracts\Tool;
use Laravel\Ai\Tools\Request;
use Stringable;

class IssueRefund implements Approvable, Tool
{
    use InteractsWithApprovals;

    public function description(): Stringable|string
    {
        return 'Issue an approved refund for an existing order.';
    }

    protected function needsApproval(Request $request): Approval|bool
    {
        $amount = (int) $request['amount_cents'];

        return $amount <= 2500
            ? false
            : Approval::required(
                'Refunds above $25 require manager approval.'
            );
    }

    public function handle(Request $request): Stringable|string
    {
        return app(RefundService::class)->issueOnce(
            orderId: $request['order_id'],
            amountInCents: $request['amount_cents'],
            reason: $request['reason'],
        );
    }

    public function schema(JsonSchema $schema): array
    {
        return [
            'order_id' => $schema->string()->required(),
            'amount_cents' => $schema->integer()->min(1)->required(),
            'reason' => $schema->string()->required(),
        ];
    }
}

Refunds of $25 or less can continue automatically. Anything above that amount produces an approval request.

The threshold is ordinary application logic. The model cannot negotiate with it or reinterpret it.

A Pause Is a Real Workflow State

When the agent selects IssueRefund, Laravel returns the pending tool call instead of executing it.

$response = (new RefundAgent)
    ->forUser($user)
    ->prompt('Refund the damaged order ORD-1842.');

if ($response->hasPendingApprovals()) {
    foreach ($response->pendingApprovals as $approval) {
        // Display the tool name, arguments and reason.
    }
}

The approval screen should show the exact order, amount, reason, and requested action. A vague “Allow this agent to continue?” message does not give the reviewer enough information.

After the manager approves or rejects the request, the application resumes the conversation:

use Laravel\Ai\Approvals\Decision;
use Laravel\Ai\Approvals\Decisions;

$response = (new RefundAgent)
    ->continue($conversationId, as: $manager)
    ->prompt(Decisions::from([
        $toolCallId => Decision::approve(),
    ]));

Laravel also supports rejecting the request or editing its arguments before execution. The human tool approval documentation covers the full flow.

Approval Is Not Authorization

This was the most important lesson from the build.

An approval button does not prove that the current user is allowed to approve the refund.

Before resuming the agent, the application must verify that:

The conversation belongs to the correct account
The signed-in user has refund approval permission
The order still qualifies for a refund
The approved amount remains valid
The action has not already been completed

The refund service also needs an idempotency rule. If a queue retries or a user submits the approval twice, the customer should still receive only one refund.

The official documentation warns that paused turns are matched through the conversation and pending tool calls. The application is responsible for authorizing access before resuming them.

The Tests That Matter

A happy-path test proves that an approved refund can succeed. That is only the beginning.

I would also test these cases:

An unauthorized employee attempts to approve the refund
The order status changes while approval is pending
A manager edits the amount before approval
The same approval is submitted twice
The approval references an unknown tool-call ID
A rejected action returns a useful explanation
An old approval expires before execution

These tests check the business boundary around the model rather than the quality of its wording.

If you are comparing teams under a search such as best Laravel development company, ask how they would authorize, resume, audit, and retry this workflow. That answer reveals more than another framework quiz.

The agent can collect evidence and recommend a refund.

PHP decides whether the tool must pause. Laravel records the pending action. An authorized person makes the final decision. The service executes it once.

That separation is what made the agent safe enough to use.

Which action in your application should an AI agent never execute without approval?

Banks Know Their Customers. Now They Need to Know Their AI Agents.

Paul-S — Thu, 17 Sep 2026 09:58:56 +0000

“Who authorized this transaction?”

“The customer.”

“Which agent submitted it?”

“We do not record that separately.”

“Which tools was the agent allowed to use?”

“It used the customer’s session.”

“Can we revoke the agent without blocking the customer?”

Silence.

This is the architecture review many banks will eventually face.

Banks already know how to identify customers, employees, applications, and service accounts. AI agents introduce a less familiar actor: software that can interpret a goal, select tools, collect data, and initiate actions on someone else’s behalf.

Confirming the customer’s identity is no longer enough. The bank must also know which agent is acting, who owns it, what authority it received, and where that authority ends.

Know Your Agent Is a Chain of Trust

At the Global Fintech Fest 2026, State Bank of India Chairman CS Setty proposed a “Know Your Agent” framework covering agent identity, authentication, customer consent, transaction limits, audit trails, and revocation.

His warning was important. An autonomous error can travel through connected systems at machine speed. The same automation that reduces waiting time can also multiply the effect of a bad decision.

A banking agent should therefore never appear in a transaction as an invisible extension of the customer.

The trust chain should remain visible:

Customer → Consent → Agent → Policy Decision → Banking API

If one link is missing, the bank cannot confidently explain why an action happened.

Authentication proves which agent made the request. Authorization determines whether that particular agent may perform that particular action for that customer at that moment.

Banks need both.

Give the Agent a Passport, Not a Master Key

An agent identity should carry a small, verifiable description of its authority. Think of it as a temporary passport rather than a reusable API key.

Here is an illustrative manifest:

agent:
  id: card-dispute-prod
  owner: disputes-team
  acting_for: customer-8421

  permitted:
    - transactions.read
    - fee_reversal.draft

  prohibited:
    - money.transfer
    - beneficiary.create

  approval_required:
    - fee_reversal.execute

  expires_in: 5m

This information should not exist only inside the model’s prompt. Prompts can be altered, misunderstood, or exposed to injection attacks.

The passport must be issued, signed, and checked by infrastructure outside the model. Every banking API should evaluate it before accepting an action.

This also separates three identities that teams often combine:

The customer requesting help
The agent interpreting the request
The service executing the action

That separation makes investigation and revocation possible.

The NIST National Cybersecurity Center of Excellence is exploring similar questions around agent identification, authentication, least privilege, delegated access, human approval, and verifiable audit records. Its 2026 concept paper also considers established technologies such as OAuth, OpenID Connect, SPIFFE, and SCIM.

Banks may not need a completely new identity system. They may need to adapt proven identity controls to a new class of non-human user.

Authority Should Shrink as Consequence Grows

Not every agent action carries equal risk.

A banking assistant might operate in four lanes:

Explain: Describe a fee or summarize account activity.
Prepare: Collect details and draft a dispute.
Recommend: Suggest a decision to an employee.
Execute: Change data, move money, or approve an outcome.

Moving from explanation to execution should not simply unlock more tools. It should narrow the acceptable conditions.

A balance explanation may require authenticated account access. Adding a beneficiary should require fresh customer confirmation. Reversing a fee may need an employee’s approval. Moving money should require stricter limits, stronger authentication, and an independent fraud check.

My view is that banks should automate evidence gathering before automating irreversible decisions. It produces meaningful efficiency while keeping responsibility with a person who is accountable for the outcome.

Financial-Crime Work Shows a Safer Starting Point

FIS offers a useful example. Its Financial Crimes AI Agent is designed to assemble evidence from banking systems, evaluate activity, and surface higher-risk cases.

The investigator still controls the decision.

That division of work matters. The agent handles the repetitive search across disconnected systems. A qualified human evaluates the evidence and accepts responsibility for the conclusion.

This is a more defensible starting point than allowing a general-purpose agent to perform every available banking action simply because the customer is authenticated.

Revocation Should Be Boring

If an agent behaves unexpectedly, stopping it should not require disabling the customer’s account or rotating a shared production credential.

Agent authority should be short-lived and revocable independently.

A bank should be able to answer:

Which agent is active?
Who or what delegated its authority?
Which resources can it access?
What actions has it attempted?
When does its permission expire?
Can the bank terminate it immediately?

These are ordinary identity-management questions. What changes is the speed and flexibility of the software being controlled.

The Next Banking User May Not Be Human

This shift also changes how conversational banking products should be built.

For an AI chatbot development company, improving response quality is no longer the complete assignment. Once a chatbot can call tools and modify business systems, its identity, permissions, approval boundaries, and audit trail become part of the product.

At Spaculus Software, that means treating an AI agent as a governed system actor, not merely a conversational interface.

Banks have spent decades learning who their customers are. The next challenge is knowing which software is standing beside those customers, what it has been asked to do, and whether it should be allowed to continue.

If an AI agent contacted your banking API today, could your system identify the agent separately from the customer?

An AI Engineer’s Hardest Problem Is Knowing When the Model Should Stop

Paul-S — Tue, 15 Sep 2026 12:05:21 +0000

RUN 4821
Goal: Process customer refund
Order found: Yes
Refund policy found: Yes
Policy versions found: 2
Amounts calculated: $89 and $129
Tool retries: 4
Next action selected: Issue $129 refund

The agent found conflicting policies, calculated two different amounts, and still selected an action.

That last line might look like successful task completion.

It is actually the failure.

The agent should have stopped when it discovered that the evidence could not support one safe decision.

The Missing State in Most Agent Workflows

Many agent workflows define only two outcomes:

SUCCESS
FAILURE

But an agent can execute every tool successfully and still make the wrong decision. The API responded. The database was available. No exception occurred.

The uncertainty existed in the business context, not the infrastructure.

Production agents need more meaningful terminal states:

ASK_FOR_INPUT
WAIT_FOR_APPROVAL
ESCALATE_TO_HUMAN
DENY_ACTION
STOP_LIMIT_REACHED
COMPLETE

A stop is not necessarily a failure. Sometimes it is the most correct output the system can produce.

Why Another Prompt Will Not Fix This

A common response is to add instructions such as:

Only proceed when you are confident.

That delegates the boundary decision to the same probabilistic model creating the uncertainty.

The model may report high confidence even when its evidence is incomplete. It may interpret repeated tool calls as a reason to keep investigating. A different model version could interpret the instruction differently.

Prompts can guide reasoning. They should not be the only mechanism protecting consequential actions.

The application needs a deterministic gate between the model’s recommendation and the real operation.

Turn Stop Conditions Into Code

Here is a framework-independent example:

def next_state(run):
    if not run["authorized"]:
        return "DENY_ACTION"

    if run["conflicting_evidence"]:
        return "ESCALATE_TO_HUMAN"

    if run["missing_required_data"]:
        return "ASK_FOR_INPUT"

    if run["irreversible"] and not run["approved"]:
        return "WAIT_FOR_APPROVAL"

    if run["tool_attempts"] >= 6:
        return "STOP_LIMIT_REACHED"

    return "COMPLETE"

Notice what this function does not check: the model’s self-reported confidence.

It checks observable conditions such as authorization, missing data, conflicting evidence, reversibility, approval, and execution limits.

The model can propose the next action. The surrounding software decides whether that action is allowed.

OWASP calls the combination of excessive functionality, permissions, and autonomy Excessive Agency. Its recommended controls include least-privilege access, limited tools, independent authorization checks, and human approval for high-impact actions.

Break the Exit Paths Before Users Do

Happy-path tests ask whether an agent can complete a task.

Boundary tests ask whether it refuses to complete the wrong task.

A small pytest suite can make those decisions visible:

import pytest


@pytest.mark.parametrize(
    "change, expected",
    [
        ({"authorized": False}, "DENY_ACTION"),
        ({"conflicting_evidence": True}, "ESCALATE_TO_HUMAN"),
        ({"missing_required_data": True}, "ASK_FOR_INPUT"),
        (
            {"irreversible": True, "approved": False},
            "WAIT_FOR_APPROVAL",
        ),
        ({"tool_attempts": 6}, "STOP_LIMIT_REACHED"),
    ],
)
def test_agent_exit_paths(base_run, change, expected):
    run = {**base_run, **change}
    assert next_state(run) == expected

These tests are simple, but they force the team to define expected behavior before an unusual request reaches production.

The next layer is adversarial evaluation. Give the agent contradictory documents, expired authorization, unavailable tools, repeated timeouts, ambiguous user instructions, and requests that cross account boundaries.

Do not score only the final answer. Record whether the agent chose to continue, ask, pause, deny, or escalate.

The NIST AI Risk Management Framework recommends documenting knowledge limits, defining human oversight, testing under deployment-like conditions, and ensuring AI systems can fail safely when operating beyond their limits.

The Hiring Question I Would Ask

I would not evaluate an AI engineer only by asking which models or agent frameworks they have used.

I would give them the refund trace from the beginning of this article and ask:

Where should this workflow stop, and which component should enforce that decision?

A strong answer should discuss permissions, evidence quality, action reversibility, approval requirements, retry budgets, logging, and human handoff.

For teams planning to hire AI engineers, this boundary-first evaluation is more revealing than another prompt-engineering exercise. It is also how Spaculus Software approaches production AI workflows: the model reasons, but the system retains control.

The hardest part of agent engineering is not helping a model finish more tasks.

It is making sure the system recognizes the tasks it must not finish alone.

What stop condition would you add before allowing an AI agent to change real business data?

Your AI Engineer Is Debugging Workflows, Not Prompts

Paul-S — Fri, 11 Sep 2026 11:10:44 +0000

The support agent looked fine during testing.

It understood refund requests, found the correct order, explained the policy, and asked for confirmation before taking action.

Then it reached production and refunded the same order twice.

The first reaction was predictable: rewrite the prompt.

Add “never issue the same refund twice.” Put it in capital letters. Repeat it near the tool instructions. Lower the temperature.

None of that fixed the real problem.

The payment API had completed the first refund, but its response timed out. The workflow interpreted the missing response as failure and retried the tool call. The model followed its instructions both times.

This was not a prompt bug. It was a distributed-systems bug wearing an AI costume.

The Prompt Is Only One Part of the System

A demo often looks like this:

user request -> model -> answer

A production agent looks more like this:

request -> context -> model -> tool -> external API
-> state update -> model -> approval -> final response

Every arrow is another place where the workflow can fail.

The wrong customer record may enter the context. A tool may receive valid JSON with the wrong business meaning. Authentication may expire halfway through a run. A background worker may retry after the external action has already succeeded.

Prompt changes cannot repair those failures.

Tool Calls Create Real Side Effects

Generating a poor paragraph is inconvenient. Sending an email, cancelling an order, or updating a CRM record changes something outside the model.

That means consequential tools need the same protections as any other production service: input validation, authorization, timeouts, retry policies, idempotency, and audit logs.

A simplified refund tool might protect repeated calls with an action identifier:

async def refund_order(order_id: str, action_id: str):
previous = await actions.find(action_id)
if previous:
return previous.result

return await actions.run_once(
    action_id,
    lambda: payments.refund(order_id),
)

The important instruction is not hidden in the prompt. It is enforced by the application: one logical action should produce one external effect.

The production implementation still needs atomic storage and protection against concurrent requests, but the boundary is clear. The model can propose the action. The system decides whether that action is safe to execute.

Traces Are More Useful Than Chat Logs

A chat transcript shows what the user and model said. It rarely explains why an agent selected a tool, what arguments it generated, how long the API took, or which state was restored after a retry.

An end-to-end trace should connect the model turn, tool call, approval, API response, state change, and final answer under one run identifier.

The OpenAI Agents SDK tracing documentation reflects this approach. Its traces can capture generations, function calls, handoffs, guardrails, and custom events as parts of one workflow.

This makes a useful debugging question possible:

Where did the actual behavior first diverge from the expected behavior?

That is much more precise than asking why the model was “confused.”

Some Actions Should Pause

Not every decision should be automated simply because the agent can call the necessary tool.

Reading an order status may be low risk. Issuing a large refund, deleting a record, publishing content, or changing account permissions may require human approval.

The human-in-the-loop guidance for the OpenAI Agents SDK demonstrates a pause, approve or reject, and resume pattern for sensitive tool calls. The specific framework is optional. The control is not.

Experienced AI engineers define these boundaries before production incidents define them instead.

Evals Should Test the Workflow

Testing ten prompts against ten expected answers is useful, but it does not test the complete system.

Workflow evaluations should also ask whether the correct tool was selected, whether its arguments were valid, whether unauthorized data was excluded, whether duplicate actions were prevented, and whether low-confidence situations were escalated.

Every production failure should become a regression case. Over time, the evaluation set becomes a record of how the system has failed in the real world.

At Spaculus Software, this is why AI engineering work extends beyond model integration. Reliable systems require workflow design, tool boundaries, evaluation, observability, and safe recovery paths around the model.

The prompt still matters. It guides intent, tone, reasoning, and tool selection.

But when an AI application breaks in production, the most valuable engineer in the room is usually not asking, “How should we reword this?”

They are asking, “What exactly happened between the request and the result?”

What workflow failure has been hardest for you to diagnose?

I Connected an LLM to Production. Here’s What Broke

Paul-S — Tue, 08 Sep 2026 10:54:30 +0000

The demo looked ready.

The application could search company documents, answer support questions, classify requests, and create tickets through an API. It handled every test prompt we gave it.

Then real users arrived.

They asked incomplete questions. They pasted entire email threads. They used terms that did not exist in our documentation. Some requests matched several policies, while others required information the system could not access.

The LLM was still producing fluent answers. The workflow around it was falling apart.

The Output Was Valid Until It Wasn’t

During testing, the model returned predictable JSON:

{
"category": "billing",
"priority": "high",
"requires_human": true
}

Production inputs were less predictable. Sometimes the model changed a field name, returned an unsupported category, or added an explanation outside the JSON object.

A response that looks reasonable to a person can still break an application.

The first improvement was to treat model output as untrusted input. Every response had to pass schema validation before the application could use it.

from typing import Literal
from pydantic import BaseModel

class TicketAction(BaseModel):
category: Literal["billing", "technical", "account"]
priority: Literal["low", "medium", "high"]
requires_human: bool

def validate_action(model_output: dict):
return TicketAction.model_validate(model_output)

Structured output reduced parsing failures, but it did not prove that the selected category was correct. Format validation and business validation became separate steps.

RAG Retrieved Something Relevant but Not Correct

The knowledge base contained current policies, archived documents, internal notes, and several pages describing similar processes.

The retrieval system often returned a document related to the question. That did not mean it returned the document needed to answer it.

One customer asked about cancelling a subscription. The system retrieved an older cancellation policy because it shared more words with the question than the current policy did.

The solution was not simply increasing the number of retrieved chunks.

Documents needed version metadata, ownership, effective dates, and access rules. Archived content had to be removed from normal retrieval. The application also needed to recognise conflicting evidence and stop instead of asking the LLM to choose a convenient answer.

RAG improved the model’s access to information. It did not remove the need to manage that information.

Tool Calling Turned Small Errors Into Real Actions

A wrong answer is harmful. A wrong action can be worse.

Once the LLM could create tickets, update CRM records, and trigger notifications, every uncertain decision had operational consequences.

Retries created duplicate records. Incorrect parameters sent requests to the wrong queue. A broad service account gave the agent access to functions it never needed.

We reduced this risk by giving each tool one narrow purpose. Tool arguments were validated outside the model, write operations used idempotency keys, and high-impact actions required confirmation.

This follows the principle behind OWASP’s guidance on excessive agency: limit available tools, permissions, functionality, and autonomy.

The model could recommend an action. The application decided whether that action was allowed.

One User Request Became Eight Model Calls

The original demo made one request to an LLM.

The production version classified the user’s intention, rewrote the search query, retrieved documents, reranked the results, generated an answer, checked the answer, selected a tool, and summarized the result.

Each step appeared reasonable on its own. Together, they created noticeable latency and unpredictable costs.

Agents made the problem harder because the number of steps could change for every request. A simple question might finish immediately, while an ambiguous request could enter a loop of repeated searches and tool calls.

We added limits for execution time, model calls, retries, retrieved context, and total tokens. Smaller models handled basic classification, while stronger models were reserved for decisions that needed deeper reasoning.

The goal was not to minimize every model call. It was to ensure that each call justified its cost and delay.

Our Logs Said Everything Was Successful

The API returned 200. The workflow was still wrong.

Traditional logs showed that the request completed, but they did not explain which documents were retrieved, why a tool was selected, or where the answer changed.

Production debugging required a trace of the complete workflow. We recorded the prompt version, model version, retrieved document IDs, tool arguments, tool results, latency, token usage, validation failures, and final outcome.

Sensitive customer data was removed or masked before storage. Observability should help investigate failures without creating a new privacy problem.

The NIST Generative AI Profile also emphasizes ongoing monitoring, documented responsibilities, incident handling, and human oversight for generative AI systems.

The Evaluation Set Was Too Polite

Our early tests asked clear questions with known answers.

Real users did not behave like an evaluation dataset.

They submitted vague instructions, conflicting requests, spelling mistakes, old account details, pasted web content, and questions requiring permissions they did not have.

The evaluation set had to include those conditions. We added cases involving stale documents, conflicting sources, API timeouts, repeated actions, missing information, prompt injection, and requests that should be refused or escalated.

Every production failure became a new regression test.

That changed evaluation from a task completed before launch into a process that continued throughout the product’s life.

The LLM Was Only One Part of the Product

The biggest lesson was simple: connecting an LLM to an application is not the same as building a production AI system.

Reliable AI requires structured outputs, managed knowledge, secure tools, permission checks, human approvals, observability, cost controls, and realistic evaluations.

This is also what teams should examine when they plan to hire AI engineers. Prompting skills matter, but production AI development also requires backend engineering, API design, security, data management, testing, and operational thinking.

The LLM did not suddenly become less capable after deployment. Production simply exposed every assumption that the demo never tested.

What broke first when you moved an LLM application into production?

The Laravel App Worked Fine Until the Customer Base Started Growing

Paul-S — Tue, 01 Sep 2026 12:43:55 +0000

At launch, the Laravel application felt fast. Pages loaded quickly, orders moved through the system, and the support team heard few complaints. Then the customer base grew. Reports took longer to open, checkout occasionally stalled, and background tasks began to pile up. The application had not suddenly become badly written. Its original assumptions simply no longer matched the workload.

This is a common stage in a successful product. More customers do not just create more page views. They create more data, simultaneous sessions, uploads, notifications, searches, reports, API calls, and support activity. A design that works comfortably for hundreds of users may reveal bottlenecks when thousands arrive at the same time.

Growth changes the shape of the workload

Teams often respond to slower performance by adding a larger server. That can provide temporary relief, but it does not explain where time is being spent. One customer action may trigger several database queries, an email, a webhook, an audit entry, and a file operation. As traffic rises, each small cost is multiplied.

The first task is therefore measurement. Request duration, error rates, memory use, database load, slow queries, queue depth, and third-party response times help reveal the actual constraint. Without that visibility, scaling becomes an expensive guessing exercise.

The database often feels the pressure first

Database problems can stay hidden while tables are small. Missing indexes, repeated queries, and loading more records than a page needs may barely be noticeable during early development. With years of orders or a rapidly growing product catalogue, the same patterns become costly.

Laravel teams should examine slow-query logs and common user journeys. N+1 queries can often be reduced through appropriate eager loading. Large lists should use pagination, and searches should avoid scanning unnecessary columns or rows. Indexes should support real filtering and sorting patterns, not be added blindly. Optimizing the query behind a busy endpoint is usually more valuable than increasing hardware without investigation.

Synchronous work makes customers wait

A web request should finish the work the customer needs immediately and move suitable follow-up tasks elsewhere. Sending emails, generating reports, processing imports, resizing images, or notifying external systems can often run through queues. This keeps the user-facing response short even when the total amount of work grows.

Queues are not a place to hide unreliable code. Jobs need sensible timeouts, controlled retries, failure monitoring, and protection against running the same action twice. Workers must also scale with demand. A fast website paired with a six-hour queue backlog is still a poor customer experience.

Caching helps when its rules are clear

Frequently read information can be cached to reduce repeated database and API work. Configuration, catalogue summaries, and expensive calculations are common candidates. However, caching introduces a new question: when does the stored value become outdated?

A cache strategy should define what is stored, how long it remains valid, and which event refreshes or removes it. Caching everything can trade a performance issue for stale prices, incorrect permissions, or confusing customer data. The safest approach starts with measured hot paths and clear invalidation rules.

External services become part of reliability

Payment providers, shipping platforms, CRMs, and AI services may work perfectly in a low-volume test. At scale, rate limits, network timeouts, and intermittent failures become normal operating conditions. Integrations should fail gracefully, use appropriate retries, record enough context for diagnosis, and avoid blocking an entire page when a non-essential service is unavailable.

Scaling requires operational discipline

Adding application instances works best when the application is stateless. Sessions, cache data, and user uploads should not depend on the local disk of one server. Deployments should be repeatable, and database changes should be planned so old and new application versions can operate safely during a release.

Businesses investing in Custom Laravel Development should plan for expected traffic, data growth, background processing, integrations, failure handling, and observability before adding infrastructure. These decisions make later growth less disruptive and help teams scale the parts of the system that genuinely need it.

Start with evidence, not a rewrite

A growing application does not automatically need microservices or a complete rebuild. A well-structured Laravel monolith can support substantial demand when its database access, queues, caching, and deployment model are designed carefully. Splitting a system too early can add network failures, duplicated data, and operational complexity without improving the customer experience.

Begin with profiling and realistic load tests. Fix the most expensive query, move slow non-essential work to queues, add monitoring, and test again. Repeat until the system meets a defined performance target. Architecture should change only when evidence shows that a clear boundary needs independent scaling, ownership, or release cycles.

Customer growth is not proof that Laravel failed. It is proof that the product reached a workload its early design never had to handle. The strongest teams treat that moment as a signal: measure what changed, remove the real bottlenecks, and build the operational habits needed for the next stage of growth.

AI Chatbot vs Traditional Mobile App: What Do Customers Actually Need?

Paul-S — Tue, 01 Sep 2026 11:51:41 +0000

When businesses discuss digital customer experience, the conversation often becomes a contest: should they build an AI chatbot or a traditional mobile app? That framing sounds simple, but it overlooks the most important person in the decision—the customer.

Customers rarely care which technology sits behind an experience. They want to complete a task quickly, understand what is happening, and feel confident that their information is safe. Sometimes a conversation is the easiest route. In other situations, a familiar screen with clear buttons is faster and more dependable.

What a traditional mobile app does well

A mobile app is strong when customers perform the same structured tasks regularly. Banking customers may want to check balances, review transactions, transfer money, or manage cards. Fitness users may want dashboards, progress charts, saved routines, and device tracking. These actions benefit from a stable visual layout that users can learn over time.

Apps are also useful when an experience depends on phone features such as the camera, GPS, biometric login, push notifications, or offline access. A well-designed app gives users direct control. They can see available options, compare information, move backward, and confirm an action before submitting it.

That predictability matters for high-value or sensitive tasks. Customers may prefer a visible form and a clear confirmation screen when making a payment, changing account settings, or uploading personal documents.

Where an AI chatbot can reduce friction

Chatbots are more helpful when customers do not know where to begin. Instead of searching through menus, users can explain what they need in their own words. The chatbot can ask follow-up questions, clarify the request, and guide them toward a relevant answer or action.

This approach works well for product discovery, appointment scheduling, onboarding, troubleshooting, and questions that involve several possible routes. A customer could describe the type of insurance cover they need, ask which subscription suits their team, or explain an unusual delivery problem without first learning the company's navigation structure.

Conversation can also make digital services easier for people who struggle with complex menus or unfamiliar terminology. Voice input, translation, and step-by-step explanations can improve access when they are designed carefully.

A chatbot is not automatically the simpler choice

Natural language feels easy, but it can introduce uncertainty. A customer may not know what the chatbot can do, how to phrase a request, or whether an answer is accurate. Long conversations can also become slower than tapping a few familiar buttons.

Chatbots are weak when users need to scan, compare, or control several items at once. Choosing airline seats, reviewing financial charts, editing a detailed profile, or comparing product specifications usually works better through a visual interface. Customers should not have to conduct a lengthy conversation for a task that a simple screen can complete in seconds.

Trust is another concern. If a chatbot can access accounts or perform actions, users need clear confirmation, visible limits, and an easy way to reach a person. A confident but incorrect answer can damage the experience faster than a confusing menu.

The practical answer is often a hybrid experience

Businesses do not always need to choose one interface. A mobile app can provide the stable structure, while an AI assistant helps users navigate it. The chatbot might explain a feature, find a transaction, summarize account activity, or prepare an action. The app can then display the details and ask the user to review and confirm.

This combination uses conversation for discovery and guidance while keeping visual controls for comparison, editing, and approval. It also allows customers to switch methods. Someone may start with a question, move to a form, and return to the conversation if they need help.

Start with customer tasks, not technology

Businesses considering AI chatbot app development services should begin by studying the tasks customers are trying to complete. The right design depends on how often the task occurs, how much information it involves, how serious an error would be, and whether customers need to compare options visually.

Teams should map the complete journey, including what happens when the system does not understand, when data is missing, or when human judgment is required. They should also test the experience with real customers rather than assuming that a conversational interface is naturally easier for everyone.

Useful measures include completion rate, time required, abandonment, repeated attempts, customer satisfaction, and the quality of human handoffs. These reveal whether the interface is solving a genuine problem or simply adding a fashionable AI layer.

Give customers the shortest reliable path

AI chatbots and traditional mobile apps serve different needs. Apps provide structure, visibility, and control. Chatbots provide flexibility, guidance, and a natural starting point for uncertain requests. Neither is universally better.

What customers actually need is the shortest reliable path to their goal. The best digital products choose the interfac

Five Signs Your Python Application Needs an Experienced Engineer

Paul-S — Wed, 26 Aug 2026 11:56:55 +0000

A Python application can appear healthy while problems are quietly growing underneath it.

Features are being released. Customers can log in. The API responds. Nothing seems urgent.

Then traffic increases, a dependency is updated, or a new developer joins the project. Suddenly, simple changes take days, errors become difficult to reproduce, and nobody wants to touch certain parts of the code.

These problems do not necessarily mean Python was the wrong choice. They usually mean the application has grown beyond the engineering practices used to build its first version.

Here are five signs that your Python application may need a more experienced engineer.

1. Every Small Change Breaks Something Else

Adding a field to a form should not break the reporting system. Updating a payment method should not affect user registration.

When unrelated features repeatedly fail after small changes, the code probably contains tight dependencies. One function may be handling validation, database operations, business rules, and external API calls at the same time.

This often happens in early-stage products. The team moves quickly because proving the idea matters more than creating perfect architecture.

That approach can work for a prototype. It becomes dangerous once customers depend on the application.

An experienced Python engineer can separate responsibilities, introduce clearer boundaries, and reduce the chance that one change creates failures elsewhere. The objective is not to rewrite everything. It is to make future changes safer.

2. Nobody Trusts the Test Suite

A test suite should give developers confidence before a release. Instead, some teams have tests that fail randomly, take too long, or cover only the easiest parts of the application.

The team eventually stops paying attention to failures. Developers rerun the same test until it passes or disable it to complete a deployment.

At that point, testing becomes decoration rather than protection.

A senior engineer will first identify which workflows create the greatest business risk. Authentication, payments, permissions, data processing, and third-party integrations usually deserve attention before minor interface details.

Good testing is not about reaching an impressive coverage percentage. It is about detecting failures that could affect customers or business operations.

3. Production Errors Are Difficult to Investigate

Consider this error handling:

try:
process_payment(order)
except Exception:
pass

The application does not crash, but the payment may fail without leaving useful evidence. The customer sees an incomplete order, while the support team has no information about what happened.

Changing pass to a log statement is not enough if the system still lacks request IDs, structured logs, alerts, performance metrics, and relevant business context.

Experienced engineers think about how software will be investigated after deployment. They design applications to answer practical questions:

Which customer was affected?
Which request failed?
Did an external service time out?
Can the operation be retried safely?
Did the same error affect other users?

If finding the cause of an error requires hours of guesswork, the application needs better observability, not just more debugging.

4. Performance Problems Are Solved by Adding Servers

Adding infrastructure can temporarily hide inefficient code, but it does not always solve the underlying problem.

A slow Python application may be making repeated database queries, loading too much data into memory, calling external services one after another, or performing heavy work inside a web request.

An experienced engineer measures the system before changing it. The real bottleneck might be a database index, an inefficient query, a blocking network call, or a task that belongs in a background queue.

This distinction matters because each problem requires a different solution. Adding servers to compensate for a poor database query can increase cloud costs without providing reliable performance.

Optimization should start with evidence.

5. One Developer Holds the Entire System Together

Sometimes only one person knows how deployments work, why a particular workaround exists, or which background job must be restarted manually.

That person becomes the project’s unofficial documentation.

This situation creates a serious business risk. If the developer is unavailable, releases slow down and production incidents become harder to resolve. New team members may avoid important parts of the application because they do not understand the consequences of changing them.

An experienced engineer can reduce this dependency through clearer documentation, automated deployments, code reviews, architecture notes, and repeatable operational processes.

The goal is not to make every developer know everything. It is to ensure that critical knowledge belongs to the team rather than one individual.

Experience Is More Than Writing Advanced Python

Experienced Python engineers do not simply write more complicated code. In many cases, they make the application simpler.

They know when a small refactor is enough and when an architectural change is necessary. They consider security, testing, deployment, monitoring, and maintainability alongside feature delivery.

If you plan to hire Python developers for an existing application, evaluate more than framework knowledge. Ask candidates how they have diagnosed production failures, improved legacy code, reduced deployment risk, and handled systems that grew beyond their original design.

At Spaculus Software, this is often the first step when joining an existing Python project: understand the current system before recommending changes. A careful technical review can reveal whether the application needs focused improvements, gradual modernization, or a larger architectural update.

Final Thought

A working application is not always a healthy application.

Frequent regressions, unreliable tests, unclear production errors, rising infrastructure costs, and knowledge concentrated in one person are signs that technical risk is accumulating.

The right engineer will not begin by rebuilding everything. They will identify the most important risks, protect what already works, and help the application become easier to change as the business grows.

Which of these warning signs have you encountered in a Python project?

The Chatbot Worked in Testing, Then Real Users Arrived

Paul-S — Tue, 25 Aug 2026 11:53:23 +0000

The demo looked ready.

The chatbot answered every question from the testing document. It explained product features, found account information, and politely handed difficult conversations to a human.

The team tested it again before launch.

“Where can I download my invoice?”

“Can I change my subscription?”

“What is your refund policy?”

Every answer was correct.

Then real customers arrived.

One user wrote, “charged twice pls fix.” Another sent three messages instead of one complete question. Someone pasted an entire email thread into the chat. A customer referred to “the plan I had before,” although the chatbot had no access to that history.

By the end of the first day, the team had discovered something its test script never showed:

The chatbot understood the test cases. It did not yet understand the messiness of real conversations.

Testing Questions Were Too Clean

Development teams often test chatbots with complete, well-written questions because those cases are easy to review.

Real users do not behave that way.

They misspell words, change topics halfway through a message, use internal product names, and assume the chatbot remembers information from earlier sessions. They may provide too little context or far more context than the system can process effectively.

A chatbot tested only with ideal questions is like a payment form tested only with valid cards. It proves that the happy path works, not that the product is ready.

A stronger evaluation set should include incomplete messages, spelling mistakes, conflicting requests, long conversations, unsupported languages, angry customers, and questions with no verified answer.

OpenAI’s official evaluation guidance describes evals as an essential part of checking whether model outputs meet defined content and style expectations. The important word is defined. “The answer looks good” is not a measurable production requirement.

Retrieval Worked Until the Wording Changed

The chatbot used retrieval-augmented generation to answer from company documents. During testing, the user’s wording closely matched the documentation.

The knowledge base said “subscription cancellation.” Testers asked, “How do I cancel my subscription?”

Customers asked:

“How do I stop getting billed next month?”

The intent was the same, but retrieval did not always return the correct document.

This is why teams should inspect more than the final answer. They need to know which documents were retrieved, how relevant those documents were, and whether the model had enough evidence to respond.

A useful production trace might record:

{
"conversation_id": "conv_1842",
"intent": "cancel_subscription",
"retrieved_documents": 3,
"top_relevance_score": 0.62,
"response_time_ms": 2480,
"used_fallback": false,
"human_handoff": true
}

The exact fields will vary, but the principle remains: if the chatbot produces a bad answer and the team cannot reconstruct what happened, debugging becomes guesswork.

The Bot Answered When It Should Have Stopped

One customer asked about a policy that was not present in the approved knowledge base.

The chatbot still responded.

The answer sounded reasonable, confident, and completely invented.

This is one of the most dangerous production failures because fluent language can hide missing evidence. Anthropic’s official guidance on reducing hallucinations recommends allowing the model to express uncertainty and grounding responses in direct source material.

A production chatbot should have a clear refusal or escalation rule:

if retrieval_score < MIN_CONFIDENCE:
return {
"answer": "I don’t have enough verified information to answer that.",
"action": "handoff_to_human"
}

The threshold should be tested using real conversations. Setting it too low increases unsupported answers. Setting it too high sends too many customers to human support.

Some Users Tested the Boundaries on Purpose

Not every unexpected input is accidental.

Users may ask the chatbot to ignore previous instructions, reveal its system prompt, expose private information, or perform actions outside their permissions. If the chatbot reads uploaded files, webpages, emails, or support tickets, malicious instructions may also enter indirectly through that content.

The OWASP GenAI Security Project lists prompt injection as a major risk for LLM applications. It also makes an important point: retrieval and fine-tuning do not completely remove the problem.

Teams therefore need controls outside the prompt. Tools should enforce user permissions independently. Sensitive actions should require confirmation. Retrieved content should be treated as untrusted input, and the chatbot should never receive broader system access than the task requires.

Production Quality Is More Than Answer Accuracy

A chatbot can answer correctly and still create a poor experience.

A response that arrives after twelve seconds may cause the customer to leave. A correct answer written in five dense paragraphs may be useless on mobile. A bot that forgets the previous message forces the customer to start again. A handoff that loses the conversation history makes human support repeat the same questions.

Production monitoring should therefore cover:

Answer correctness and source support
Retrieval quality
Response time and failures
Cost per conversation
Fallback and handoff rates
Repeated questions after an answer
Customer feedback and unresolved conversations

These metrics should be reviewed by intent. A chatbot may perform well for opening hours and order tracking while failing badly on billing or account access. One overall success rate can hide those differences.

Real Conversations Should Become New Tests

The most valuable evaluation set is not created once before launch. It grows from production.

Failed searches, poor answers, unusual wording, escalated conversations, and negative feedback should become new test cases. Before changing the prompt, model, retrieval settings, or knowledge base, teams can run those cases again and check whether the update fixes one problem without creating another.

That feedback loop is what separates a chatbot demo from a maintained product.

It is also the work businesses should examine when choosing an AI chatbot development company. Spaculus Software supports chatbot architecture, RAG pipelines, integrations, evaluation, security controls, deployment, and ongoing monitoring—not only the chat interface customers see.

The Real Launch Begins After Launch

The chatbot did not suddenly become less intelligent when customers arrived.

The environment changed.

Testing gave it clean questions, known answers, and predictable conversations. Production introduced ambiguity, missing context, unusual language, security risks, latency, integration failures, and genuine consequences for being wrong.

The team’s mistake was not launching too early.

It was treating launch as the end of testing.

For an AI chatbot, real users do more than use the product. They reveal the test cases the development team never knew it needed.

AI Developers Can Build the Demo in a Week. Production Is Where the Real Work Starts

Paul-S — Fri, 21 Aug 2026 10:39:55 +0000

The demo looks perfect.

A user asks a question. The AI finds the right information, writes a clear answer, and returns it within seconds.

Everyone in the meeting is impressed.

Then the application goes live.

Real users ask unclear questions. Some upload broken files. Others try prompts nobody expected. Responses become slower, API costs rise, and the AI occasionally gives a confident answer that is completely wrong.

The demo proved that the idea could work.

Production reveals whether it can keep working.

Why Is an AI Demo Easy to Build?

Modern AI APIs make it possible to create a working prototype quickly. A developer can connect a language model, add a simple interface, provide a few instructions, and have something impressive within days.

That is valuable. A quick demo helps a company test an idea before spending heavily on it.

But a demo normally works with:

Selected questions
Clean data
Limited users
Controlled conditions
Little concern about cost or scale

Production removes all those protections.

What Changes When Real Users Arrive?

Real users do not follow the demo script.

They misspell words, leave out important details, switch topics, upload unexpected formats, and sometimes ask the AI to do things it should never do.

This is where AI development becomes less about prompts and more about engineering.

A production AI system needs to know:

When it has enough information to answer
When it should search company data
When it should ask another question
When it should refuse a request
When a human should take control

A better prompt may improve the response, but it cannot solve every production problem.

Production AI Must Be Measured, Not Trusted

Traditional software usually gives the same result when it receives the same input. AI systems can behave differently, even when a request looks similar.

That means testing a few successful examples is not enough.

AI developers need evaluation sets containing normal questions, difficult cases, incomplete requests, unsafe prompts, and examples collected from real usage. They must measure whether answers are correct, grounded in approved data, useful, fast, and affordable.

Logging is equally important. If an answer goes wrong, the team should be able to see what the user asked, what information was retrieved, which model responded, and where the process failed.

Without that visibility, improving the system becomes guesswork.

Reliability Is More Than Preventing Hallucinations

Wrong answers receive the most attention, but production AI can fail in quieter ways.

A response may be correct but arrive too late. An AI agent may repeat a tool call and increase costs. A retrieval system may find an outdated document. A model update may change behaviour that worked yesterday.

Production engineering therefore includes:

Data quality and retrieval
Security and access control
Response evaluation
Monitoring and alerts
Cost and latency control
Fallbacks and human review

This is often the point when companies decide to hire AI engineers instead of treating AI as one more API integration.

When Should You Hire AI Developers?

You probably do not need a large AI team to test an early idea. One focused prototype can answer an important question: Does this solve a real user problem?

Once the answer is yes, the requirements change.

If you plan to Hire AI engineers, look beyond model knowledge and prompt writing. Ask how they test output quality, protect private data, control costs, handle model failures, and monitor the complete user request.

While exploring production AI at Spaculus Software, one lesson keeps coming up: getting the first answer is easy, but making the complete system reliable takes real engineering. The goal is not simply to make AI answer once. It is to make the complete system useful, measurable, and dependable when real people start using it.

A demo earns attention. Production earns trust.

*For developers who have shipped an AI feature: what failed first when real users arrived? *

Can I Hire MEAN Stack Developers to Upgrade an Existing Angular or Node.js Application?

Paul-S — Thu, 20 Aug 2026 13:17:30 +0000

Yes. You can hire MEAN Stack developers to upgrade an existing Angular frontend, Node.js backend, or complete JavaScript application.

A MEAN developer works across MongoDB, Express.js, Angular, and Node.js. This full-stack knowledge is useful when an upgrade affects both the user interface and backend APIs.

However, the MEAN Stack label alone does not guarantee a successful upgrade. The developer should have practical experience with your current Angular or Node.js version, dependencies, testing environment, database, deployment process, and application architecture.

Why Should You Upgrade an Existing Application?

Framework upgrades are not only about accessing new features. They help applications continue receiving security fixes, maintain compatibility with third-party packages, and avoid growing technical debt.

As of August 2026, Angular 22 is under active support. Angular 21 and Angular 20 are receiving long-term support, although Angular 20’s LTS period ends on November 28, 2026. Angular 19 and earlier versions are no longer supported.

Angular provides approximately 12 months of active support followed by 12 months of long-term support. Once a version becomes unsupported, it no longer receives regular framework fixes or security patches. Angular release policy

Node.js has a different release model. Node.js 26 is the current release, while Node.js 24 and Node.js 22 are supported LTS versions. Node.js 20 and earlier versions have reached end of life.

The Node.js project recommends using only Active LTS or Maintenance LTS releases in production. Node.js release schedule

If your application uses an unsupported version, postponing the upgrade can increase security, compatibility, and maintenance risks.

When Is a MEAN Stack Developer the Right Choice?

A MEAN developer is a strong fit when an Angular upgrade also affects Node.js APIs, Express middleware, authentication, MongoDB queries, or shared TypeScript models.

For example, upgrading Angular may require a newer TypeScript version. That change can affect shared packages used by the Node.js backend. A full-stack developer can review these dependencies together instead of treating the frontend and backend as separate systems.

MEAN developers can also help when the project needs more than a version update. They can replace deprecated packages, improve API performance, review MongoDB queries, modernize Angular components, and strengthen automated testing.

If the application contains only a small Angular interface without Node.js or MongoDB, a dedicated Angular developer may be more efficient. A complex Node.js microservices platform may similarly require a backend specialist with distributed-systems experience.

The right choice depends on the actual architecture, not the name of the stack.

What Should Be Checked Before the Upgrade?

An upgrade should begin with an application audit rather than immediately changing package versions.

For an Angular application, developers can start with:

ng version
ng update
npm outdated
npm audit

For a Node.js application:

node --version
npm outdated
npm audit
npm test

These commands identify the current versions, outdated dependencies, known package vulnerabilities, and the condition of the existing test suite.

The audit should also cover custom build configurations, deprecated APIs, UI libraries, authentication packages, database drivers, environment variables, and CI/CD workflows.

This assessment helps determine whether the project needs a routine update, a broader modernization effort, or selected parts of the application to be rebuilt.

Can Angular Be Upgraded Across Several Versions at Once?

Angular recommends upgrading one major version at a time.

An application moving from Angular 19 to Angular 22 should normally follow this path:

*Angular 19 → Angular 20 → Angular 21 → Angular 22
*
Angular’s migration tooling supports updates between adjacent major versions. The official guidance says that the version being upgraded should be within one major version of the target. Angular Update Guide

This staged approach makes problems easier to isolate. Jumping across several versions at once can combine dependency conflicts, TypeScript changes, removed APIs, and test failures into one difficult debugging process.

What Happens During an Upgrade Project?

The team should first document the current versions, architecture, package dependencies, business-critical workflows, and known defects.

Next, developers identify compatible versions of Angular, Node.js, TypeScript, MongoDB drivers, and third-party packages. Unsupported libraries may need to be replaced before the main framework upgrade can continue.

The application is then upgraded in controlled stages. After each stage, developers run unit tests, integration tests, build checks, and important user journeys.

The updated application should be released to a staging environment before production. Performance, errors, API behaviour, authentication, database operations, and customer-facing workflows should be monitored after deployment.

An upgrade is complete only when the application works reliably in production. Successfully installing new package versions is not enough.

Should You Upgrade or Rewrite the Application?

In most cases, an incremental upgrade is safer than a complete rewrite.

A rewrite creates new risks around feature parity, data migration, testing, delivery time, and business continuity. Existing business rules that took years to develop may be overlooked during reconstruction.

A rewrite may be appropriate when the current architecture blocks essential changes, core dependencies have no supported upgrade path, serious security problems are deeply embedded, or maintaining the existing code costs more than replacing it.

The decision should be based on a technical audit rather than the age of the application alone.

What Should You Ask Before Hiring MEAN Stack Developers?

Ask developers how they would assess the application before providing a final estimate.

They should be able to explain their approach to incremental Angular upgrades, Node.js LTS migration, dependency conflicts, automated testing, rollback planning, staging, and production monitoring.

Request examples of previous upgrade projects and ask what unexpected problems occurred. Experience resolving real dependency, testing, and deployment issues is often more valuable than familiarity with a long list of technologies.

How Can Spaculus Help?

Spaculus Software provides MEAN Stack developers for Angular interfaces, Node.js and Express APIs, MongoDB applications, performance optimization, and legacy-system modernization.

The team can audit an existing application, prepare a staged upgrade plan, replace unsupported dependencies, improve testing, optimize APIs, and support production deployment. Spaculus also provides custom software, SaaS, Cloud and DevOps, UI/UX, QA, mobile, and AI development services when the upgrade is part of a broader product roadmap.

Businesses can hire MEAN Stack developers from Spaculus without automatically rebuilding the complete application.

Key Takeaways

MEAN Stack developers can upgrade Angular-only, Node.js-only, or complete MEAN applications.
Angular 19 and earlier versions are unsupported as of August 2026.
Node.js 20 and earlier versions have reached end of life.
Angular upgrades should normally move through one major version at a time.
A technical audit should determine whether the application needs an update, modernization, or rewrite.

Upgrading an application is rarely just an npm install command. A safe project begins by understanding what the current system does, which workflows users cannot afford to lose, and how every change will be tested before production.