Web development with Laravel

Start with ownership: who creates an order, who can change its price, where stock is recorded and when an order becomes accepted. A dealer portal separates catalogue, orders, contract pricing and integrations. Initially, these can be modules within one application and database, keeping deployment and support manageable. A separate service is justified by a concrete need for independent load, teams or release cycles.

Assign an owner to each value. The ERP might own stock and shipments while the portal owns drafts and approvals. Document state transitions and forbidden actions so the systems do not become competing versions of the same order.

Project checklist
Design deliverables: context diagram, data ownership table, state model and integration contracts.

A controller receives a request without having to contain the entire workflow. A Form Request validates its shape: quantity must be an integer within bounds and the address must belong to the selected customer. A policy checks permission, then an application service performs the action. Valid input does not mean a discount is authorised.

Recalculate prices, discounts and totals on the server. The client sends product identifiers and quantities, not a total the application must trust. Show errors next to the relevant fields, preserve entered data and explain the next action.

Project checklist
Acceptance checks: call the API directly, tamper with the price and submit fractional or negative quantities. The server must reject violations independently of the interface.

An order has lines, a customer, a version of commercial terms and a change history. Store money with explicit currency and precision, for example as integer minor units. Each line keeps a price snapshot; changing a price list must not rewrite historical sales.

Create an order and its lines in a database transaction. For concurrent reservations, choose appropriate locking or version checks. An external ERP request does not turn a local transaction into a distributed transaction: model delivery states and retries separately.

Project checklist
Acceptance check: two employees order the last available unit at the same time. Verify consistent behaviour, not just a successful isolated request.

A first-party browser portal can use session authentication; external clients may need token access. Sanctum supports both scenarios, with configuration depending on the domains and clients involved. Passwords, sessions, account recovery and protection against repeated login attempts need deliberate configuration.

A manager role alone is insufficient. Policies also consider company membership, order ownership, workflow stage and approval limits. An employee of one dealer must not read another dealer’s records by guessing an identifier. Apply the same checks to exports, attachments and background actions.

Project checklist
Create a role × action × data-scope matrix and test the denials. Choose two-factor authentication and session lifetimes according to the project’s requirements.

Define resources, required fields, error formats, pagination and compatibility rules. An OpenAPI specification with examples helps mobile and partner teams. API Resources provide control over exposed fields; internal model attributes should not leak into responses accidentally.

Order creation can return 202 Accepted when ERP delivery is still pending. Return an identifier and a status endpoint so the client can follow progress. Removing or renaming a field requires a coordinated client migration; a version number in the URL does not solve that on its own.

Project checklist
Acceptance checks cover required fields, access restrictions, empty lists and predictable errors. The example below is a project-specific contract, not a built-in Laravel route.

An ERP may accept an order before the connection drops. A retry must therefore avoid creating a second document. Bind an idempotency key to the company and a request checksum; reject reuse with a different payload. Agree a unique external identifier with the receiving system.

For important events, use a delivery journal: persist the order and an event atomically, then deliver the event separately. Verify webhook signatures and an allowed time window, and record event identifiers. Timeouts, retry limits and manual recovery are part of integration design.

Project checklist
Acceptance checks: duplicate events, a 500 response, a timeout after acceptance and out-of-order notifications. Sent is not the same state as accepted by the ERP.

Catalogue imports, document generation and notifications can run in a queue. Users see an understandable status while long operations continue separately. Keep critical jobs apart from bulk mail so a large import does not delay an order confirmation.

A repeated job must be safe. Configure timeouts, attempt limits and backoff; monitor queue depth and the oldest waiting job. Dispatch work that depends on a transaction after it commits successfully. Exhausted retries should appear in an actionable operator view.

Project checklist
Acceptance check: stop a worker during processing and resume it. The order should complete once and the operator should be able to identify why it was delayed.

Quotes, contracts and invoices live separately from public catalogue images. Check both user and company access before download, using a controlled route or a time-limited URL. An obscure path is not an access-control mechanism.

Validate size and allowed type, generate server-side names and define content inspection and retention policies. When generating a PDF, record the source-data and template versions. Choose object storage and backups alongside access and recovery requirements.

Project checklist
Acceptance checks: a direct link to another company’s document, an expired URL, an oversized upload and a misleading file extension.

Measure real journeys first: opening the catalogue, searching by SKU and placing an order. Inspect SQL query counts, external-call latency and response size. Indexes, pagination and loading related records efficiently often matter more than adding servers.

Cache data with an explicit freshness policy. A contract-price key includes the company and terms version; a shared key could disclose another customer’s discount. Price or permission changes invalidate dependent entries. Recheck current terms when the order is submitted.

Project checklist
Agree latency targets and a load profile before testing. A framework cannot promise a particular requests-per-second figure: results depend on the application, database, infrastructure and external services.

Laravel can support server-rendered templates, Livewire or a separate React/Vue interface. Choose according to interaction needs and team capabilities. Public catalogues need deliberate indexable URLs, metadata and content rendering; private portals should not accidentally enter search indexes.

Design around employee tasks: find a product, compare terms and understand a blocked action. Adapt tables for narrow screens, make confirmations explicit and keep keyboard focus visible. Both light and dark themes must preserve contrast in charts, alerts and status indicators.

Project checklist
Acceptance checks: keyboard-only checkout, enlarged text, validation failures, an empty catalogue, a slow connection and long product names.

Test more than a successful order. Include discount boundaries, company isolation, concurrent changes, repeated events and ERP downtime. Test domain rules in isolation and critical flows through integration and browser scenarios.

An error log and a business audit trail serve different purposes. Record the actor, action, time and changed values without logging secrets or unnecessary personal information. A correlation identifier links the portal request, queued job and external call.

Project checklist
Alert on exchange failures, rising error rates and queue delays. Each alert needs an owner and a documented recovery procedure.

Separate development, staging and production environments. Keep secrets out of the repository and disable public debug output. A release includes frontend assets, configuration checks, migrations and restarting long-running workers.

Make database changes compatible with the previous application version during deployment. Rolling back code does not automatically reverse data changes. A risky migration needs a recovery plan and a verified backup. Back up the database, files and configuration, and practise restoring them.

Project checklist
At handover, document environments, release commands, backup schedules, responsible contacts and dependency maintenance. Response times belong in the support agreement.