Web Apps

Custom software development for UK businesses


Most businesses do not start by searching for custom software development. They start with a process that breaks under load: a spreadsheet that three people update differently, a customer onboarding flow that takes two weeks when it should take two days, or an order pipeline held together by email threads and manual re-keying.

Off-the-shelf tools work well for standard problems. When your operational processes are what differentiate you from competitors, forcing them into someone else's product means surrendering the advantage. Custom software development encodes how your business actually operates, owned entirely by you, with no per-seat licensing scaling against your growth.

We have been building custom web applications since 2005. We are still maintaining systems we shipped in 2008. That longevity shapes everything on this page: not theory, but patterns drawn from 20 years of production systems for UK businesses.

Custom software development is the practice of designing, building, and maintaining applications purpose-built for a specific organisation's processes, data structures, and users. Unlike off-the-shelf products that require workflow adaptation, custom software encodes how the business actually operates, owned entirely by the commissioning organisation with no per-seat licensing, no vendor roadmap dependency, and no forced migrations.


What businesses build with custom software

Custom software development covers a wide range of application types. The common thread is a process that off-the-shelf tools cannot accommodate without significant compromise.

Operational systems

Order management, service delivery tracking, resource scheduling. A logistics company whose fulfilment process did not match any standard warehouse management tool replaced three disconnected systems with one application that tracked orders from enquiry through to delivery confirmation. Data entry dropped from 45 minutes per order to under five.

Internal tools and dashboards

CRM systems, reporting dashboards, staff scheduling, inventory management. These are often the highest-value custom builds because they directly affect how efficiently a team operates every day.

Customer-facing portals

Self-service account management, order tracking, document access. Well-built portals reduce support volume while giving customers faster access to the information they need. The architecture differs from internal tools: authenticated external users require stricter session management, rate limiting, and data isolation.

Workflow automation

Approval chains, document generation, notification engines, and complex business processes modelled as state machines. A construction firm automated its site inspection workflow, replacing paper forms with a mobile application that captured data, triggered approval chains, and generated compliance reports. Time from inspection to report dropped from five days to four hours.

Integration layers connect CRM, accounting software, legacy databases, and third-party APIs into a single source of truth. When five systems each hold a fragment of a customer record, someone is re-keying data and someone else is working from stale information. Custom API integrations eliminate both problems.

Data applications round out the most common builds: analytics platforms, reporting tools, and data visualisation interfaces that turn raw information into something a team can act on. The value is not in storing data; it is in surfacing the right number at the right moment.


When custom software is the wrong answer

Honesty about when not to build custom is a better signal of expertise than claiming it fits every situation. Here are concrete decision rules.

Email, calendars, basic project management. These are commodity problems. Gmail, Outlook, Asana, and Monday.com solve them well. Building custom alternatives is expensive vanity.
Standard accounting. Xero and QuickBooks handle bookkeeping, invoicing, and VAT reporting for the vast majority of UK businesses. The effort required to replicate their HMRC integration alone makes custom accounting software irrational for most organisations.
Customer support ticketing. Zendesk, Intercom, and Freshdesk are mature products with years of iteration behind their workflows. Unless your support process is genuinely unusual, buy rather than build.
Your process is not yet stable. Custom software encodes a process. If that process is still changing weekly, you are encoding something that will be wrong within a month. Stabilise the workflow first, then automate it.
Your team is under five people. The overhead of specifying, building, and maintaining bespoke software rarely justifies the benefit at this scale. The threshold varies by industry, but the question is whether the operational savings exceed the investment within two to three years.

The decision rule: if your process is your competitive advantage and off-the-shelf tools force you to compromise it, build custom. If the process is commodity, buy. We cover this framework in depth on our build vs buy page.

Failure mode: a recruitment agency commissioned a custom applicant tracking system when Bullhorn and Greenhouse already matched 90% of their requirements. Twelve months and £80,000 later, they had a system that replicated commodity features while missing the integrations that mature products offer out of the box. The remaining 10% of unique process could have been handled with a lightweight integration layer at a fraction of the cost.


The gap between prototype and production

Most custom software projects fail not in the first sprint but somewhere between "it works on my laptop" and "it handles 200 concurrent users in production." The gap between a tutorial-quality application and a production system is where bespoke software development budgets overrun and timelines collapse. It is also where 20 years of experience shows most clearly.

Concern Prototype / tutorial Production (what we ship)
Authentication Basic login form, weakly hashed passwords Multi-factor authentication, Sanctum tokens, role-based access control, session management with idle timeout, brute-force protection
Data integrity Single-user testing, no concurrent writes Pessimistic locking on critical records, database transactions wrapping multi-step operations, unique constraints, referential integrity across 50+ tables
Error handling Generic try/catch, raw exceptions shown to users Structured exception hierarchy, Sentry integration for real-time alerting, user-friendly error messages, automatic retry with exponential backoff
Background processing Synchronous HTTP requests, user stares at spinner Laravel Horizon queue management, job batching, dead letter queues, retry policies per job class, real-time monitoring
Deployment FTP upload, manual database changes Zero-downtime deployment via atomic symlink switching, version-controlled migrations with rollback capability, automated smoke tests
Performance Acceptable on a developer's laptop with 10 records N+1 query elimination, Redis caching with tagged invalidation, eager loading strategies, composite database indexes, load testing against production-scale data

Failure mode: a prototype application processed CSV imports synchronously during HTTP requests. With 50 rows, this took two seconds. With 5,000 rows (the real production volume), the request timed out at 30 seconds, the import half-completed, and the database was left in an inconsistent state. The production fix: queued job processing via Laravel Horizon with transactional batching, progress tracking via WebSocket, and automatic rollback on failure.


Cross-cutting concerns in custom software development

These eight constraints affect every custom software build regardless of the application type. Addressing them after launch is always more expensive than building them in from the start.

Data migration

Moving from spreadsheets or legacy systems without data loss. This requires schema mapping between source and target, validation rules that catch malformed records, and parallel running periods where both old and new systems operate simultaneously. The most common failure: assuming source data is clean when it is not.

Multi-tenancy vs single-tenant

An architectural decision that determines database isolation strategy, deployment complexity, and per-tenant cost structure. Multi-tenant Laravel applications serving multiple clients from one codebase need schema-per-tenant isolation or row-level filtering. Choosing wrong is expensive to reverse once data is in production.

Audit trails

Regulatory compliance and debugging both require knowing who changed what, when, and why. Every state change must be traceable to a user, a timestamp, and a reason. Immutable event logs with queryable history are a necessity, not a feature.

Access control

Role-based permissions that mirror organisational hierarchy. The receptionist should not see the same screens as the finance director. Laravel's gate and policy system provides granular, testable authorisation that is enforced at both the route and query level.

API design

Every custom application eventually needs to talk to other systems. REST conventions, versioning, and authentication must be built in from day one, not bolted on when the first integration request arrives.

Testing strategy

Unit tests for business logic, feature tests for user flows, database factories for realistic test data. Untested code is undeployable code. A test suite that runs in under 60 seconds enables confident, frequent deployments. One that takes 20 minutes means deployments happen on Fridays with crossed fingers.

Backup and disaster recovery

Automated database backups, point-in-time recovery, tested restoration procedures. The test: can you restore last night's backup to a clean server within one hour? If you have never tested this, the answer is no.

GDPR and data handling

Consent management, right to deletion, data export, audit logging. Non-negotiable for UK businesses processing personal data. The failure mode is not a fine from the ICO. It is the inability to answer a subject access request within 30 days because personal data is scattered across 12 unindexed tables.


Architecture decisions that shape custom software development

The architectural choices made in the first two weeks of a project determine the maintenance cost for the next decade. Three decisions matter most.

Monolith vs microservices

Do: Start with a well-structured monolith. Laravel's service container, event system, and module boundaries provide clean separation without the operational complexity of distributed systems.
Avoid: Premature microservices. They add deployment pipelines per service, distributed transaction management, network latency between components, and debugging complexity that requires distributed tracing tooling.

A logistics company split their application into eight microservices before they had 10 active users. Debugging a single order flow required tracing requests across four services with separate log streams. They consolidated back to a monolith in month six. Development velocity tripled.

Server-side rendering vs single-page applications

Do: Server-rendered HTML with selective interactivity using Livewire and Alpine.js. Pages load in under 500ms, work without JavaScript for core flows, and remain accessible to screen readers.
Avoid: Shipping a 2MB JavaScript bundle for a CRUD application. Single-page applications are appropriate for genuinely interactive interfaces (configurators, real-time dashboards, drawing tools), not for every form and table.

A React SPA for a staff scheduling tool. Initial load on a warehouse floor tablet: 4.2 seconds over the facility's WiFi. The same interface server-rendered with Livewire for the interactive drag-and-drop elements: 400ms initial load, with interactivity hydrated progressively.

Database design

Do: Normalised relational schema with PostgreSQL. JSON columns reserved for genuinely semi-structured data (user preferences, third-party webhook payloads). Composite indexes planned from the schema design phase.
Avoid: Storing structured business data in JSON columns "for flexibility." You lose query performance, referential integrity, and the ability to enforce constraints at the database level.

An application stored order line items as JSON arrays within the orders table. Reporting across 50,000 orders required deserialising every row in application code. Query time: 45 seconds. After normalising the schema with a dedicated line_items table, proper foreign keys, and a composite index: 200ms.


The technology stack

We use boring, proven technology. Laravel and PostgreSQL are not exciting choices. They are correct choices for business software that needs to run reliably for a decade.

Laravel

PHP framework, mature since 2011. Handles authentication, queues, caching, migrations, mail, notifications, and scheduling out of the box. We have built over 50 applications with it. The framework's conventions mean any competent Laravel developer can read and extend our code, which matters if your relationship with us ends.

PostgreSQL

Relational database with native JSON support, full-text search with language-aware stemming, geographic queries via PostGIS, and 25+ years of production reliability. For custom web application development, it handles everything from simple CRUD to complex analytical queries without requiring a separate search engine or data warehouse for most use cases.

Laravel Horizon and Sentry

Horizon provides queue monitoring and management for background job processing. Sentry provides error tracking and performance monitoring. Every production application reports exceptions in real time with full stack traces, request context, and user identification.

Expo for mobile

Expo provides cross-platform mobile development when field teams need the same business system in their pocket. One codebase produces iOS and Android applications that share the backend API with the web application.

Technology choice is a hiring decision. A competitor quoted a client using a bespoke Python/FastAPI stack for a standard business application. Six months post-launch, the client needed to hire a developer for ongoing maintenance. The UK market had 47 available FastAPI developers on LinkedIn versus over 12,000 with Laravel experience.


What a custom software development project looks like

The process compresses into four phases. The details vary per project, but the rhythm is consistent across 20 years and over 50 applications.

1

Discovery (one to two weeks)

Understand the business, map the processes, define scope. Output: specification document detailing data model, user roles, core workflows, and integration points. Architecture diagram showing system boundaries. Realistic timeline with two-week sprint milestones.

2

Build (six to twelve weeks)

Iterative two-week sprints. Working software demonstrated at the end of every cycle. Feedback incorporated continuously. The first demo typically arrives within two weeks of starting, not two months.

3

Launch

Zero-downtime deployment to production. Data migration from existing systems with validation checksums. User training, documentation, and a parallel running period if replacing an existing system. The goal is a Monday morning where the team opens the new system and everything they need is already there.

4

Support

Ongoing monitoring, security updates, and feature development. Some client relationships span 15+ years. We maintain the system as the business evolves, adding capabilities when the need is clear rather than speculating upfront. Post-launch costs are typically 10-15% of the initial build per year.

Failure mode: projects that skip discovery. A client insisted on starting development immediately to "save time." Eight weeks in, a fundamental misunderstanding about their invoicing workflow required restructuring the database schema and rewriting three modules. The rework cost more than the discovery phase would have. Every project we have seen skip discovery has paid for it later with interest.


Sub-page map

Custom software development spans dozens of specialist concerns. Each page below addresses a specific architectural constraint in the depth it deserves.

Architecture and patterns

Multi-tenant Laravel

When one codebase serves multiple clients, the database isolation strategy determines everything: data security, query performance, and deployment complexity. We use schema-per-tenant with shared application infrastructure.

Workflow engines

Business processes with branching logic, approval chains, and exception handling cannot be hardcoded as if-else trees. State machines with explicit transition rules model complex workflows without becoming unmaintainable at 50+ states.

Background jobs

Long-running operations (report generation, data imports, email campaigns) executed synchronously block the UI and risk HTTP timeouts. Laravel Horizon manages queued jobs with retry policies, rate limiting, and real-time monitoring.

Data and integration

Data modelling

The database schema is the most consequential architectural decision in any custom software project. Normalisation depth, indexing strategy, and relationship design determine query performance and application flexibility for years after launch.

Database migrations

Schema changes in production require version-controlled migrations that can roll forward and back without data loss. Every migration is tested against production-scale data before deployment to catch lock contention and timeout issues.

API integrations

Connecting your custom application to Xero, HubSpot, legacy databases, or third-party services. Circuit breakers prevent cascading failures when external APIs go down. Idempotency keys prevent duplicate processing on retry.

Integration patterns

Beyond point-to-point API calls: event-driven architectures, webhook processing, batch synchronisation, and conflict resolution strategies for bidirectional data flow between systems that each consider themselves the source of truth.

Operations and infrastructure

Real-time dashboards

Live operational data without polling. WebSocket connections push state changes to the browser as they happen. The engineering challenge is not the technology; it is deciding which metrics justify real-time updates versus refreshing on a five-minute schedule.

Audit trails

Regulatory compliance and debugging both require knowing who changed what, when, and why. Immutable event logs with queryable history, integrated into the application's write path rather than bolted on as an afterthought.

Infrastructure

Hosting, deployment pipelines, SSL, CDN configuration, and server monitoring. Infrastructure matched to the application's actual traffic patterns and availability requirements, not over-engineered for theoretical scale.

Security and operations

Authentication, authorisation, encryption at rest and in transit, OWASP compliance, dependency vulnerability scanning, and incident response procedures. Security is a cross-cutting concern woven into every layer, not a feature added before launch.

Legacy migration

Moving off Access databases, ancient PHP 5 applications, or Excel-based workflows without losing years of accumulated data or disrupting daily operations. Phased migration with parallel running periods and automated validation checksums.

Specialist capabilities

Mobile apps

Cross-platform mobile applications with Expo (React Native) that connect to your central business system via the same API. Field teams, remote workers, and customer-facing tools sharing one data layer and one set of business rules.

Maps and location

Geospatial features: route planning, territory mapping, asset tracking, and location-based search. PostGIS integration for geographic queries at the database level, avoiding the performance penalty of calculating distances in application code.

Three.js interfaces

Interactive 3D visualisation for product configurators, spatial data, and digital twins. WebGL rendering in the browser without plugins. InstancedMesh for draw call reduction, Draco compression for geometry payload, and WebGPU compute where available.

Custom software development deep dives

Custom software vs SaaS

A structured comparison framework covering total cost of ownership, flexibility, data ownership, and long-term risk. When the break-even point favours building, and when it favours buying, with worked examples at different scales.

Laravel for business applications

Why Laravel specifically for bespoke software development. Framework maturity, ecosystem depth (Horizon, Sanctum, Scout, Cashier), UK talent availability, and long-term maintainability compared to alternatives.

Custom software costs in the UK

Pricing frameworks, what drives cost variation, and how to evaluate return on investment. Concrete ranges by application complexity, with the factors that push projects toward the lower or upper end.

The custom software development process

Discovery through to launch expanded into a detailed walkthrough. Deliverables per phase, decision points, common pitfalls, and what to expect from each sprint cycle.

Internal tools development

Purpose-built applications for your team: CRMs, scheduling systems, operational dashboards, and data entry tools. The specific failure modes of "building internal tools with spreadsheets" and the architectural patterns that replace them.

Customer portal development

Self-service portals for external users: account management, order tracking, document access. Authentication patterns for external users differ from internal tools, requiring stricter session controls, rate limiting, and data scoping.


Start with a conversation

If you are running a business on spreadsheets, disconnected tools, or software that does not match how you actually work, a conversation is the right starting point. We will tell you honestly whether custom software development is the right approach for your situation, or whether a well-chosen SaaS product would serve you better.

Book a discovery call →
Graphic Swish