Software Development Company UK | iCentric Agency

Why teams hire iCentric as their software development company

iCentric Agency is a UK software development company that ambitious product, operations and technology leaders bring in when an idea has outgrown spreadsheets, an off-the-shelf SaaS no longer fits the way the business actually works, or an internal team needs senior delivery muscle alongside it. We are not a body shop. We sell shipped software, measured against business outcomes you can put in a board pack: revenue captured, hours saved, conversion lifted, risk removed. Every engagement is anchored to a small number of outcomes that we agree in discovery and report against weekly until go-live.

We are deliberately structured as small, senior-led pods. A typical iCentric squad is a product lead, a tech lead, two to four engineers, a designer and a QA engineer, all working in your timezone with a single point of contact who has the authority to make decisions on the day. There are no rotating juniors hidden behind a glossy account manager, and we publish the names, GitHub histories and LinkedIn profiles of every person who will touch your code before the contract is signed. If someone leaves the squad mid-project, we tell you - and we eat the handover cost ourselves.

Our engagement model is built to remove the two things clients tell us went wrong on their last project: ambiguous scope and opaque progress. Fixed-scope MVPs are quoted against a written scope artefact that both sides sign, with a capped change budget baked into the price so that small adjustments do not trigger a fresh round of contract renegotiation. Dedicated squads run on two-week sprints with a Friday demo, a written sprint report and a burn-up chart shared in your own tooling - Jira, Linear, Notion or Asana, whichever you already use. You will never have to ask us how the build is going; you will already know.

Clients who hire iCentric typically have one of three problems. The first is a commercial one: they have validated demand for a product and need a partner who can take it from Figma to revenue in under six months. The second is operational: their business has grown faster than its tooling, and the spreadsheet-and-Slack stack is now a constraint on margins or headcount. The third is technical: an inherited codebase is slowing them down, security and compliance reviews are flagging issues, and they need a credible team to modernise without a high-risk big-bang rewrite. We have written this page so that whichever of those problems you arrived with, you can see exactly how we would tackle it, who would be on the team, what it would cost and how long it would take.

We work UK-wide from offices in London and Manchester, with senior engineers across the rest of the country, and we deliberately keep our headcount under a hundred so that founders and CTOs deal with the same partners from pitch through to year-three roadmap. That continuity is the single most under-priced asset a software development partner can offer, and it is the reason 78% of our revenue comes from clients we have worked with for more than two years.

What a modern software development company actually does

The phrase "software development company" has stretched to cover everything from two-person freelancer collectives to publicly listed multinationals with thirty thousand staff, and what you actually get differs wildly across that spectrum. At the modern, full-service end - where iCentric sits - a software development company is responsible for the whole arc of getting a product from a business problem to live, measurable value in production, and then for keeping it healthy as the business changes around it.

That arc starts with discovery. Before any code is written, a good software development company will spend time with your commercial, operational and technical stakeholders to understand the system the new software has to live inside. What does the business actually do? Where does money currently leak? Which workflows are negotiable, and which are sacrosanct because the regulator, the customer or the union say so? What does success look like in twelve months, and which metric on which dashboard will tell us we got there? Skipping discovery is the single most common reason software projects fail, and any provider that does not insist on it - even as a small, paid, two-week engagement - should be treated with suspicion.

Next comes product strategy and design. The output of this phase is not Figma screens; it is a small number of clearly framed bets about what to build, in what order, for whom, with measurable acceptance criteria. Good software development companies push back on scope. They will tell you when a feature is not worth building, when an integration is cheaper than a custom build, and when the right answer is a no-code tool rather than a full engineering engagement. iCentric publishes a written build-vs-buy memo at the end of discovery on every engagement, and we have killed our own projects on the strength of it more than once.

Then there is the engineering itself: architecture, full-stack development, mobile, data, AI, DevOps and security. A modern team is fluent in cloud-native patterns, infrastructure as code, automated testing, continuous deployment and observability. They build with composable, well-typed components, write tests as a matter of professional pride, and treat performance and accessibility as first-class requirements rather than bolt-ons. They also know when to stop adding complexity - a Postgres database and a boring monolith is the right answer far more often than the conference circuit suggests.

Finally there is operate-and-improve. Software is not finished at go-live; that is the moment it starts paying rent. A serious software development company sticks around for warranty support, runs on-call rotations against agreed SLAs, watches your error budget and works through a steady-state roadmap of improvements driven by real usage data. The contracts we are proudest of are the ones still running five and six years later, where the original MVP is now a multi-million-pound revenue engine.

This page walks through each of those phases in the order you will experience them, and then answers the practical questions about cost, timeline, contracts and team composition that real buyers ask.

Our software development services in detail

We organise our service catalogue around the deliverable, not the technology. Clients buy outcomes - a portal, an app, an automation, a modernised platform - and we map the right combination of disciplines and stacks onto that outcome behind the scenes. The headline services are:

• Custom software development for bespoke workflows that no SaaS product covers cleanly.
• Web application development for customer portals, marketplaces, internal tools and content-driven platforms.
• Mobile app development for native iOS, native Android and cross-platform builds where the maths supports it.
• SaaS product development for founders and scale-ups taking a product from MVP to Series A and beyond.
• Enterprise software development for larger organisations that need to integrate cleanly with SAP, Oracle, Dynamics, Salesforce and ServiceNow without breaking their security model.
• AI and machine learning integration for teams adding copilots, retrieval, summarisation, classification and intelligent automation to existing products.
• Cloud-native and DevOps engineering for resilient, observable, cost-controlled platforms on AWS, Azure and Google Cloud.
• API and systems integration for replacing manual swivel-chair work between systems with reliable, observable, event-driven flows.
• Legacy modernisation for organisations carrying technical debt that has started to affect commercial velocity.
• Product discovery, UX and UI design as either a standalone discovery sprint or part of a wider build.
• Quality assurance, testing and security as embedded disciplines on every squad and as standalone audits.

Each of the next twelve sections expands one of those services with the patterns we use, the stacks we reach for, the typical cost and timeline, and at least one anonymised real-world example. If you only have time to read one section, pick the one that matches the deliverable you actually need - the rest will still be here when you come back.

Custom software development

Custom software development is the work of building applications that are specifically shaped to your business, rather than bending your business to fit somebody else's product. Most organisations buy SaaS for the eighty per cent of their operations that look like everybody else's - email, accounting, CRM, payroll - and then commission custom software for the twenty per cent that is genuinely theirs, where the workflow itself is the competitive advantage.

The trigger for a custom build is usually one of three signals. The first is that your operations team has built a spreadsheet so elaborate that it now has its own change-management process, multiple owners and a folder full of macros. The second is that you are paying a SaaS vendor a six-figure annual licence but are still importing and exporting CSVs to make it usable. The third is that your competitors are doing something you cannot do because their internal tools are simply better than yours. In all three cases, the custom software development business case is straightforward to model: take the loaded cost of the manual work, multiply by twelve, compare against a one-off build and a sensible support retainer, and the payback is usually inside eighteen months.

Our typical custom build sits between £80,000 and £400,000 for the first production release, depending on integration count, regulatory load and the complexity of the user experience. Architecturally, we default to a modular monolith on PostgreSQL with a typed TypeScript or .NET backend, a Next.js front end and a thin queue-based worker tier for anything that runs asynchronously. Microservices are deployed only when the team size, deployment frequency or data residency story actually requires them - which, in our experience, is far less often than vendors of microservice tooling would have you believe.

A recent example: a Lloyd's-market insurance broker came to us with a quoting workflow that involved seven underwriters, a shared Outlook inbox, three Excel templates and a Word document that was the legal record of the quote. Manual handling per quote was forty-seven minutes, error rates were rising, and the broker had just lost a significant account because a quote went out with a wrong sum insured. We delivered a quoting platform in fourteen weeks: a typed React front end, a NestJS backend, a Postgres data model that mirrored the underwriting questions, integrations into their policy admin system and Companies House, and a generated Word and PDF quote document signed off by their compliance lead. Manual handling fell to under fourteen minutes per quote, error rates fell by 71%, and the broker has since used the freed-up underwriting capacity to win three new schemes worth more than a million pounds in gross written premium each year.

What makes custom development succeed is not the language or the framework; it is the discipline of saying no. On that engagement we said no to a mobile app, no to a customer-facing portal in phase one, and no to a real-time chat feature that one stakeholder championed - all because the data said they would not move the metrics we had agreed to move. Twelve months later we have built two of those three things, in the order the data justified, paid for by the savings from the first release.

Web application development

Web application development is still where most modern software development companies spend the majority of their hours, because the browser remains the cheapest and most universal way to put a product in front of users. The web stack has matured enormously over the past five years: server components, edge rendering, streaming HTML, typed end-to-end APIs and design tokens have collectively raised the floor for what a small team can ship.

iCentric builds web applications on a small, deliberately boring stack. The default is Next.js with TypeScript for anything that benefits from server-side rendering, hybrid routing or edge deployment, with Remix as an alternative where data-loading patterns favour it and Astro where the project is largely content with islands of interactivity. On the backend we use NestJS or Fastify in TypeScript, Laravel in PHP where the team or domain favours it, or .NET 8 for enterprise contexts. PostgreSQL is the default datastore; we only reach for MongoDB, DynamoDB or Cosmos DB when the data model genuinely justifies it.

We treat Core Web Vitals as a delivery KPI, not a launch-week panic. Every project has a documented performance budget covering Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, enforced in continuous integration via Lighthouse CI and synthetic monitoring. We refuse to ship a release that regresses the budget without an explicit override sign-off, because we have seen too many projects launch with a 5-second LCP on mobile - including, frankly, two of the three top-ranking competitors for this very keyword.

Design and engineering are run as a single discipline. The design system is built in Figma against design tokens (colours, type ramps, spacing, motion), exported via a token pipeline, and shipped as a typed React component library that powers both the production app and the Storybook documentation. Accessibility is built in to the components - focus states, ARIA roles, keyboard navigation and prefers-reduced-motion are non-negotiable defaults, not optional extras.

A representative example: a B2B insurance technology client asked us to replace a legacy portal that 40,000 brokers logged into every month to manage policies. The legacy stack was a 2014-era AngularJS single-page app talking to a SOAP API, with a TTFB north of two seconds, a 7-second LCP on mobile 4G and an accessibility audit that flagged 312 issues. We rebuilt it on Next.js 14 with server components, a fresh GraphQL gateway over the existing SOAP services (so the back-of-house systems did not need to change), and a new design system. Production LCP at p75 is now 1.7 seconds on mobile, accessibility is WCAG 2.2 AA across the journey, and broker NPS rose 28 points in the first quarter after launch.

If you are evaluating web development partners, the questions worth asking are not about frameworks. They are: who owns performance? Who owns accessibility? Who owns the design system? On a healthy team, the answer is "everyone, with a named lead" - not "we will look at it before go-live".

Mobile app development

Mobile app development is the right answer when one or more of three things is true: the user is away from a desk and needs the product in their pocket, the experience genuinely benefits from device capabilities (camera, biometrics, GPS, push notifications, offline), or the brand expectation in your sector is that there will be an app on the store. If none of those are true, a good progressive web app is usually cheaper, faster to ship and easier to update - and we will tell you that during discovery.

When mobile is the right answer, the next decision is native versus cross-platform. We build native apps in Swift and SwiftUI for iOS and Kotlin and Jetpack Compose for Android when performance, platform integration or App Store review risk justifies the duplicated effort. We build in React Native when the team will share a meaningful proportion of business logic with a web product, the design system can be expressed cleanly across platforms, and the app does not lean heavily on bleeding-edge platform APIs. We use Flutter less often than the marketing suggests we should, and only on greenfield projects where the client's longer-term team will be Flutter-fluent.

A realistic native build for a single platform with a sensible feature set - authentication, a primary list-and-detail experience, push, offline, in-app purchases, analytics - sits between £70,000 and £180,000 over twelve to twenty weeks. Cross-platform with React Native for both stores typically saves 25-35% over building both natively, but only if the design system is genuinely shared. If your iOS and Android experiences need to diverge significantly, the savings evaporate and you would have been better off going native.

We treat offline-first as a default for any field operations app. Sync is hard; doing it badly produces silent data loss and angry phone calls. Our reference architecture uses WatermelonDB or Realm locally, an event-sourced sync protocol with idempotent server endpoints, conflict resolution rules agreed in design, and a visible sync state in the UI so users know whether their last action has actually been persisted. CI/CD runs through Fastlane, EAS Build or Bitrise, with internal distribution via Firebase App Distribution or TestFlight and a release train that ships to production every two weeks.

A case from the past year: a national logistics client needed a driver app to replace a clipboard-and-radio workflow across 1,200 vehicles. We delivered a React Native app with offline-first proof-of-delivery capture, signature, photo, barcode scanning and route optimisation, syncing to their transport management system. After six months in production, proof-of-delivery disputes are down 80%, average drop-off time is down by ninety seconds, and the depot ops team has reclaimed roughly twenty hours a week previously spent chasing paperwork. The app's crash-free rate sits at 99.94% across both stores.

App Store and Play Store submission is included in our mobile engagements. We handle the metadata, screenshots, privacy nutrition labels, App Tracking Transparency declarations and data safety forms, and we have a high-touch relationship with both review teams. We have never had a launch slip because of an unanticipated review rejection.

SaaS product development

SaaS product development is its own discipline. The technology choices overlap with web app development, but the product, commercial and operational decisions are completely different. Pricing model, packaging, onboarding, activation, expansion, churn and revenue recognition are all part of the build, not afterthoughts. A good SaaS software development company treats those questions as engineering questions, because they are.

We build SaaS products on a multi-tenant architecture by default. The right shape of multi-tenancy depends on the data sensitivity and the customer profile. For most B2B SaaS products under £10m ARR, a shared schema with a tenant_id column on every row plus rigorous row-level security in Postgres is the right answer. For regulated sectors or enterprise customers demanding data residency, we move to schema-per-tenant or even database-per-tenant patterns, with infrastructure as code making the per-tenant provisioning automatic rather than artisanal. The decision is documented in an architecture decision record at the start of the build and revisited only when the business case changes.

Billing is where SaaS founders most often regret early shortcuts. We use Stripe Billing for the long tail of self-serve plans, with our own subscription state machine on top of it so that we are never reliant on Stripe's data model for product logic. Metered usage is captured to Stripe Meters or a dedicated usage table replicated to a warehouse, with idempotent event ingestion so that a network blip never double-charges a customer. Dunning, proration, plan changes, trial extensions and seat true-ups are all handled in code we own, not in a Zapier flow that breaks at 2am. Revenue recognition (ASC 606 / IFRS 15) is handled through a finance-facing export to your accounting stack from day one - investors and auditors will thank you for it later.

Onboarding and activation are designed and instrumented as carefully as the product itself. Every SaaS build ships with a defined activation event, an in-product analytics layer (PostHog, Amplitude or Mixpanel depending on the data sensitivity), a feature-flagging system (LaunchDarkly or Unleash) and a small number of in-product growth experiments queued for the first ninety days. We will not let you launch a SaaS product without these, because launching without them means flying blind through the most important period of the product's life.

The realistic eighteen-month path for a SaaS MVP looks like this. Months 0-1: discovery, design system, pricing and packaging hypothesis, technical foundation. Months 2-4: MVP build covering the smallest set of features that justifies the headline price. Months 5-6: private beta with five to fifteen design partners, weekly iteration on activation. Months 7-9: public launch, paid pilots, first integrations, SOC 2 readiness or ISO 27001 stage one. Months 10-12: scaling go-to-market, second pricing tier, first enterprise features (SSO, audit logs, SCIM). Months 13-18: scaling the engineering team, hardening, and preparing the data room for a Series A. We have run this playbook with multiple clients; the most recent reached £2.3m ARR fourteen months after we shipped the MVP.

Enterprise software development

Enterprise software development is what happens when the people buying the software are not the people using it, when security and procurement teams have veto rights over architectural decisions, and when the existing IT estate is a forty-year-old mosaic of mainframe, mid-range, on-premise and cloud workloads that all need to keep working. The technical work is rarely the hard bit; the hard bit is moving through the organisation without breaking it.

We come into enterprise engagements expecting to spend significant time with three groups outside the immediate sponsor team: information security, enterprise architecture and procurement. We will arrive at the first technical workshop with a draft data flow diagram, a draft threat model, a draft architecture decision record covering hosting and data residency, and a question list for your CISO's team. If we do not have those documents on day three, we have done discovery badly.

Our enterprise reference architecture is opinionated. Single sign-on through SAML 2.0 or OIDC, with SCIM 2.0 for provisioning, is non-negotiable; we will not build a separate username and password store inside a tool a Fortune 500 company is meant to roll out to 30,000 employees. Audit logging is structured, tamper-evident and exportable to your SIEM (Splunk, Sentinel, Elastic). Role-based access control is policy-driven, with OPA / Rego or a comparable policy engine when the matrix is more than trivially complex. Data classification flows through the architecture from the ingestion layer to backups, so that DLP and DSAR processes can be answered without an engineering archaeology project.

Integration with SAP, Oracle, Microsoft Dynamics, Salesforce and ServiceNow is core enterprise work. We default to event-driven integration over a message bus (Azure Service Bus, Amazon EventBridge, Kafka at scale) rather than synchronous point-to-point calls, because point-to-point integration is what creates the next decade of legacy. Where the existing landscape mandates synchronous APIs, we wrap them in idempotent, retry-safe adapters with circuit breakers and dead-letter handling so that a downstream outage cannot bring the new system to its knees.

Change management and training are part of the deliverable. We build training materials, run train-the-trainer sessions, and write the runbooks your service desk will need on day one. We have rolled software out to user populations as small as 50 and as large as 28,000, and the pattern is the same: pilot, lessons-learned, controlled wave rollout, full deployment, hyper-care, steady state. Skipping any of those steps is how enterprise software projects end up on the front of trade press for the wrong reasons.

AI and machine learning integration

AI is now an expected feature, not a differentiator. Buyers expect their products to summarise, classify, search semantically, generate drafts and act on natural language input. The question for a serious software development company is no longer whether to integrate AI but how to do it responsibly, observably and economically.

We build AI features along three patterns. Retrieval-augmented generation (RAG) is the most common: index your private content into a vector store, retrieve the relevant chunks at query time, and have an LLM answer with citations. We use pgvector when the corpus fits comfortably in Postgres, Pinecone or Weaviate at higher scale, and we treat chunking strategy, embedding model choice and retrieval evaluation as engineering disciplines rather than party tricks. The second pattern is structured extraction - turning unstructured documents (PDFs, emails, call transcripts) into typed records using a combination of OCR, layout-aware models and constrained LLM output. The third is agentic orchestration, where multiple model calls and tool invocations are coordinated to complete a task; we use LangGraph, LlamaIndex and the Vercel AI SDK depending on the runtime, with explicit guard rails and a strict step budget so that no agent ever loops itself into a six-figure OpenAI bill.

Guard-railing is where most production AI features fail. We use a layered approach: input validation against a schema, output validation against a Zod or Pydantic model, content moderation on both input and output, and a fallback path when the model returns low-confidence results. Evals are written before the feature ships and run continuously in CI against a frozen test set, so that a prompt or model change cannot silently regress quality. Costs are tracked per request and surfaced in the same dashboards as latency and error rate.

We are increasingly asked about the EU AI Act and the emerging UK regime. Most product features we ship are minimal- or limited-risk under the Act, but anything touching employment decisions, credit scoring, education or critical infrastructure is high-risk and requires a documented risk management system, data governance evidence, technical documentation and human oversight design from day one. We build that documentation as part of the engineering work, not as an afterthought, and we are comfortable working alongside in-house legal or external counsel on the higher-risk categories.

A recent example: a professional services firm asked us to build a research copilot over fifteen years of internal memos, client deliverables and CPD materials - several million documents, much of it scanned PDF. We delivered a RAG pipeline using Azure OpenAI, pgvector, Azure Document Intelligence for OCR, a fine-tuned reranker and a citation-first user experience. Partners now self-serve research that used to require a knowledge management team, and the average research turnaround on internal queries fell from 36 hours to under three minutes. Crucially, every answer is grounded in retrieved sources the user can click through to verify.

Cloud-native development and DevOps

The phrase "cloud-native" has been hollowed out by marketing, but the underlying engineering discipline matters more than ever. A cloud-native software development company is one whose teams treat infrastructure, deployment, observability and cost as first-class engineering concerns, expressed in code, reviewed in pull requests and tested before they reach production.

We deliver on AWS, Azure and Google Cloud, with deliberate choices made during discovery based on the client's existing relationships, regulatory needs and the actual technical fit of the workload. We do not have a religious preference. AWS is the default for greenfield SaaS; Azure is the default where the client already runs Microsoft 365 and has Azure AD at the heart of identity; GCP is the right answer for data- and ML-heavy workloads that benefit from BigQuery and Vertex AI.

Infrastructure is expressed as code. Terraform is our default, with Pulumi where the team prefers typed languages and the AWS CDK where the workload is AWS-only and the team is fluent in TypeScript. We write modules, not monolithic stacks, and we maintain a small internal catalogue of opinionated modules (VPC, RDS, ECS, ALB, S3 + CloudFront, observability) so that new environments stand up in hours rather than weeks. Manual changes in the console are an incident, not a workflow.

Kubernetes gets used when it is actually justified - typically when you have multiple teams shipping multiple services with independent deployment cadences, or when workload portability across clouds is a real requirement. For most clients under fifty engineers, ECS Fargate, Azure Container Apps or even good old Vercel and Fly.io deliver 90% of the benefit at 20% of the operational overhead. We will tell you when Kubernetes is the right answer, and we will tell you - more often - when it is not.

Observability is built in from day one. OpenTelemetry instrumentation across services, traces and logs exported to Datadog, Grafana Cloud or Honeycomb, frontend errors to Sentry, RUM to Datadog RUM or Vercel Analytics, and a small number of carefully curated SLO dashboards so the team knows what "healthy" looks like at a glance. We refuse to launch a production workload without an on-call rotation, a runbook for the top ten alert types and a documented incident response process.

Cost engineering - increasingly called FinOps - is real money. On inherited cloud estates we typically find 30-45% of monthly spend can be removed in the first quarter through right-sizing, reserved capacity, savings plans, lifecycle policies on storage, removal of zombie resources and a more thoughtful approach to data egress. We treat cloud cost as an engineering metric on the same footing as latency and error rate, and we publish a monthly cost report to clients on managed retainers.

API and systems integration

A large proportion of the value our clients get from us is not net-new features but the removal of manual work between systems they already own. Every business of a certain size accumulates a swivel-chair tax: people copying data from one system into another, reconciling spreadsheets, chasing CSVs by email. A well-designed integration kills that tax permanently.

We approach integration as an architectural discipline, not a Zapier-and-pray exercise. The first decision is synchronous versus asynchronous. Synchronous (REST, GraphQL) is right when the caller genuinely needs the result before continuing; asynchronous (events, queues) is right almost everywhere else, because it isolates failures, smooths spikes and gives you a natural audit trail. We default to event-driven integration on Amazon EventBridge, Azure Service Bus, SQS with SNS fan-out, or Kafka at scale.

Idempotency is non-negotiable. Every integration endpoint we ship accepts an idempotency key, handles retries safely, and has a documented behaviour for partial failures. Dead-letter queues are configured with alerts, and we build a small replay tool into every integration so that operations can reprocess a failed batch without engineering involvement. The boring discipline of doing this properly is the difference between an integration that runs unattended for years and one that wakes someone up every other Tuesday.

We also work with iPaaS tools - Workato, Zapier, Make and the open-source n8n - when the integration is genuinely low-complexity, low-volume and well within the tool's reliability envelope. We will not, however, run mission-critical financial integrations on a Zapier flow; the failure modes are too opaque and the cost model breaks above modest volumes. Knowing where the line is is part of what you are buying.

A representative engagement: an e-commerce client had a twelve-year-old ERP that exposed only SOAP and flat-file integration, sitting underneath a brand-new Shopify Plus storefront, a Klaviyo marketing stack and a 3PL warehouse running its own WMS. Order data was being moved between these systems by a fragile combination of nightly CSV jobs, a contractor's PHP script and a part-time operations manager. We replaced the lot with an event-driven integration layer on AWS - EventBridge bus, Lambda transformers, idempotent ERP adapters wrapping the SOAP calls, a small admin UI for re-runs and exceptions. Order-to-warehouse latency fell from up to 14 hours to under 90 seconds, mispicks fell 38% in the first quarter because stock levels were finally accurate, and the operations manager moved to higher-value work.

Legacy modernisation

Most organisations over ten years old are carrying a legacy system that is more important than its budget suggests and more fragile than its uptime numbers admit. Legacy modernisation is the most under-rated, under-marketed and arguably most valuable thing a serious software development company does. Done well, it removes risk, reduces operating cost and unlocks years of frozen product roadmap. Done badly, it is the single most expensive way to fail in enterprise IT.

We do not believe in big-bang rewrites. The graveyard of failed seven-figure rewrites is large and well-documented; we have been called in to clean up several. Our default approach is the strangler-fig pattern: stand a new system up alongside the old one, route an initial slice of traffic to the new system behind a feature flag, validate, route more, repeat, and decommission the old system one slice at a time. Done properly, the business never experiences a high-risk cutover weekend; it experiences a sequence of small, low-risk releases.

We have run strangler-fig migrations away from PHP 5, ColdFusion, classic ASP, on-prem .NET Framework, Java EE on WebSphere and a memorable Delphi desktop application. The pattern is broadly the same regardless of the source stack: reverse engineer the data model and the business rules, write them down as the team's first ADRs, build a thin anti-corruption layer that translates between the legacy and the new domain, and migrate functionality slice by slice in priority order.

Database modernisation often runs alongside. We have lifted dozens of workloads from Oracle and SQL Server to PostgreSQL, typically saving six-figure annual licensing costs. The technical work is largely mechanical (schema translation, query translation, sequence and identity differences, lock semantics); the project management work is where the value is. Running new and old in parallel, dual-writing for a defined window, comparing outputs row-for-row and only switching reads when the comparison is clean for thirty consecutive days is how we make this work without losing data.

A recent example: a UK financial services client was running its core operations on a 2008-vintage classic ASP application talking to a SQL Server 2008 R2 database, both years out of support. The system processed roughly £180m a year of transactions. A previous attempted rewrite had failed and been written off. We spent three weeks documenting the existing system, agreed twenty-three discrete functional slices in priority order, and shipped the first slice into production in week ten. Eighteen months later the legacy app is fully decommissioned, the new platform runs on .NET 8 and PostgreSQL, infrastructure cost is down 62%, and the client has shipped more new features in six months than they did in the previous four years.

Product discovery, UX and UI design

Discovery and design are not a phase that happens before "the real work"; they are the work that decides whether the real work succeeds. We run discovery as a structured, time-boxed engagement that produces concrete artefacts: a problem statement, a small number of opportunity areas, a recommended phasing, a technical risk register, a draft architecture, a clickable prototype of the riskiest user journey, and an indicative budget and timeline you can take to a board.

A standard iCentric discovery sprint runs for two weeks and costs between £18,000 and £35,000 depending on complexity and stakeholder count. The team is typically a product lead, a senior designer, a tech lead and - on more complex briefs - a domain specialist. We run user research interviews (five to eight users minimum, more for B2C), a stakeholder workshop, a competitor and adjacent-market scan, and a technical landscape review. The output is a written report and a working prototype, both yours to keep whether or not you go on to engage us for the build.

Design is run against tokens, not screens. The design system starts with design tokens for colour, typography, spacing, radius and motion, agreed early and shared with engineering. Components are built in Figma with auto-layout, variants and properties that map one-to-one onto the React component library, so that what designers ship in Figma is what engineers ship to production - not a pixel-perfect interpretation, an actual handover. Storybook documents the production components, with accessibility and interaction tests running in CI.

Accessibility is a default, not an option. We design to WCAG 2.2 AA and audit against it before launch using a combination of automated tools (axe-core, Pa11y) and manual screen-reader and keyboard testing. We have shipped products against DTAC (the NHS Digital Technology Assessment Criteria) and the public sector accessibility regulations, and the discipline that comes from designing for those standards from day one makes the product better for every user, not just those with declared accessibility needs.

Quality assurance, testing and security

Quality is the cumulative product of dozens of small disciplines: typed languages, code review, automated tests, performance budgets, security testing, observability and a culture that treats production incidents as learning opportunities rather than blame events. A software development company is only as good as the floor it puts under its own work, and our floor is high.

Automated testing is built into every project. Unit tests with Vitest or Jest, integration tests at the API boundary with the real database in a containerised harness, and end-to-end tests with Playwright running in CI against ephemeral environments spun up per pull request. We target meaningful coverage of business logic rather than chasing a line-coverage number, because chasing coverage produces brittle tests that engineers learn to ignore. Visual regression testing on critical components, contract tests at API boundaries between services, and load tests with k6 on hot paths before every major release.

Performance budgets are enforced in CI through Lighthouse CI for web, Bundle analyser thresholds for JavaScript payload size and synthetic monitoring in production. A pull request that regresses LCP, INP or bundle size beyond the agreed budget fails the build by default and requires an explicit override.

Security follows a secure SDLC aligned to OWASP ASVS and NCSC secure development guidance. Static analysis runs on every pull request via Semgrep, CodeQL or equivalent, dependencies are scanned and auto-bumped via Dependabot or Renovate, secrets are managed in AWS Secrets Manager, Azure Key Vault or HashiCorp Vault - never in environment files committed to a repo. Penetration testing before every major launch is done with CREST-accredited partners and remediation is tracked to a defined SLA. We carry professional indemnity and cyber liability insurance commensurate with enterprise expectations.

Pre-launch readiness reviews are a hard gate. We run a structured launch checklist covering performance, accessibility, security, observability, runbooks, on-call rotation, rollback plan, data protection, support process and stakeholder communication. No client of ours has ever discovered on launch day that nobody owned the incident pager - because the checklist makes it impossible to ship without that question being answered.

Our software development process, week by week

Process matters less than people, but in our experience clients sleep better when they can see the shape of the next twelve weeks before they sign. Our process is deliberately boring and predictable, because predictable is what turns a quote into a delivered product.

Week 0 - Commercial and technical discovery. A senior engineer and a product lead spend two to three days with your team to confirm scope, identify risks and agree the success metrics. The output is a written scope artefact, a fixed-price quote or a dedicated-squad rate card, and a draft Statement of Work. If we do not believe the project will succeed as scoped, we will say so and propose an alternative.

Weeks 1-2 - Foundations. The squad stands up. Architecture decisions are recorded as ADRs, the design system kicks off in Figma, the CI/CD pipeline is built, environments are provisioned via Terraform, observability is wired up, the data model is drafted, and the team agrees its ways of working. By the end of week two we have an empty but production-grade skeleton deployed to a real environment, with the first thin feature slice working end-to-end.

Weeks 3-N - Build sprints. Two-week sprints. Monday sprint planning, daily stand-ups, Friday demo to your team. Every sprint ends with a written sprint report showing what was committed, what was completed, what slipped and why, and what is in the next sprint. The product backlog lives in your tooling, not ours. You can see the actual hours, actual progress and actual risks at any time without asking.

Beta and hardening. A defined beta period - typically two to four weeks - with real users on the real system. Bugs are triaged daily, performance is measured continuously, and the readiness checklist is completed item by item. We do not move from beta to launch on a date; we move when the checklist is clean.

Go-live and warranty. Launch happens behind feature flags, with a defined rollout plan and a documented rollback. A 30-90 day warranty period covers defects against the agreed scope at no additional cost. The on-call rotation is live and tested with a fire-drill before launch day.

Steady state. Most clients move into a steady-state retainer covering ongoing development, support, security patching, observability monitoring and a continuous improvement roadmap. Retainers run on 30-day rolling notice; we have never lost a client to a contract dispute, because the contract assumes the relationship is voluntary on both sides.

Engagement models and pricing

There is no single right way to buy software development, but there are several wrong ways. We offer three engagement models, deliberately, and we are honest about which one fits which situation.

Fixed-scope engagements are right when the deliverable is well-understood and the success criteria can be written down up front. An MVP build for a clearly scoped product, a defined modernisation slice, an integration with known endpoints. We quote a fixed price against a written scope, include a capped change budget (typically 15% of the contract value) for small in-flight adjustments, and absorb the cost of estimation errors that are our fault. Fixed-scope MVPs start at £45,000 for tightly scoped work and typically sit between £80,000 and £250,000. Anything materially larger or longer than that should not be bought as a fixed-scope engagement, because the scope cannot honestly be fixed.

Dedicated squads are right when the work is ongoing, the priorities will evolve, and you want a stable team building consistently against a roadmap. A squad is priced as a monthly rate per engineer-equivalent (we count tech lead, product, design and QA against the same unit so the maths is clean). Senior engineer-equivalent rates start at £18,500 per month in the UK and rise with seniority and specialism. Squads come with a named delivery lead, two-weekly sprints, full transparency on what was delivered each sprint, and a 30-day rolling notice on either side. There is no minimum term beyond the first three months, and we have never used a long lock-in to keep a client who wanted to leave.

Time and materials is right for genuinely exploratory work: research spikes, proof-of-concepts, R&D where the destination is not known. We price by the day, cap the budget at the spike level, and produce a written recommendation at the end. T&M is the wrong way to buy production software; we will steer you firmly away from it for anything else.

We also operate a Build-Operate-Transfer (BOT) model for clients who want to internalise the team over time. We build the product, operate it for an agreed period (typically 12-24 months), then transfer the engineers - either ours moving to your payroll, or the knowledge transferred to a team you have hired in parallel. BOT pricing combines the dedicated-squad rate with a defined transfer fee.

What we do not do: bid against ten other agencies on a closed RFP with no access to the client, sign master services agreements that try to assign all risk to us, or accept payment terms longer than 30 days from invoice. Those are the things that produce bad software and bitter relationships.

Industries we serve

We are deliberately not industry-specialists in the marketing sense - we do not call ourselves a fintech agency or a healthtech agency. We are software development specialists who work repeatedly across a defined set of sectors and have built up the patterns, compliance posture and reference architectures to deliver well in each of them.

Financial services and fintech. Including FCA-regulated firms operating under the FCA Handbook, PSD2 and the FCA's Consumer Duty. We have worked with brokers, asset managers, payment institutions, FinTech start-ups and the technology arms of high street banks. We understand SCA, Open Banking, KYC/AML workflows, sanctions screening, audit trail requirements and the Senior Managers and Certification Regime as it touches technology change.

Healthcare, medtech and life sciences. Including NHS bodies, private providers, digital health start-ups and pharma. We have shipped against DTAC, DCB0129 and DCB0160 clinical safety standards, MHRA requirements for Software as a Medical Device, and standard data protection patterns for special-category data. Our healthcare squads include team members with formal clinical safety training.

Retail, e-commerce and consumer marketplaces. Shopify Plus and headless commerce, BigCommerce, custom storefronts, marketplace platforms with sellers and operators, loyalty and subscription. PCI DSS scope reduction, payment orchestration across multiple PSPs, and integration with the long tail of marketing, fulfilment and customer service tools.

Logistics, supply chain and field operations. Driver apps, depot platforms, transport management, warehouse integrations, route optimisation, offline-first mobile and IoT data ingestion. This sector is where the disciplines of distributed systems, offline sync and ruggedised UX collide, and it is one of our strongest delivery areas.

Professional services, legal tech and B2B SaaS. Knowledge management, document automation, billing platforms, client portals, AI-assisted research, practice management. The work blends sophisticated data modelling with thoughtful UX for users who are time-poor and intolerant of friction.

If your sector is not on this list, please still get in touch. The patterns transfer, and we will be honest about whether we are the right partner for your specific problem.

Our technology stack

We pick technology to fit the problem, not to fit our CVs. That said, we maintain a deliberately narrow primary stack so that engineers can move between projects without re-learning the basics and so that we can guarantee senior-level fluency across the team.

Frontend. TypeScript everywhere. React is the default, deployed via Next.js for most applications and Remix where data-loading patterns favour it. Vue 3 and Svelte/SvelteKit are supported for clients with existing teams in those stacks. State management with Zustand, TanStack Query and React Hook Form as our default trio; we avoid Redux for new builds.

Backend. Node.js with NestJS or Fastify for TypeScript backends, Python with FastAPI or Django for data- and AI-heavy work, .NET 8 for enterprise contexts and Microsoft estates, Laravel in PHP where the team or codebase favours it, Go for high-concurrency services where the workload justifies it.

Mobile. Swift and SwiftUI for native iOS, Kotlin and Jetpack Compose for native Android, React Native for cross-platform, Flutter where the longer-term team will be Flutter-fluent.

Data. PostgreSQL is the default. MySQL, MongoDB, DynamoDB and Cosmos DB when justified. Redis for caching and queues. ClickHouse for analytics-heavy workloads. Snowflake and BigQuery for analytical warehouses. dbt for transformation, Airflow or Dagster for orchestration, Fivetran and Airbyte for ingestion. Metabase and Looker for BI.

Cloud and DevOps. AWS primary, Azure and GCP as needed. Terraform, Pulumi, AWS CDK for infrastructure as code. GitHub Actions for CI/CD. Docker containers on ECS Fargate, Azure Container Apps, Cloud Run or Kubernetes (EKS, AKS, GKE) when the scale justifies it. Vercel, Fly.io and Cloudflare for edge workloads. Datadog, Grafana Cloud and Sentry for observability.

AI and ML. OpenAI, Anthropic and Azure OpenAI for hosted LLMs. AWS Bedrock, Vertex AI and self-hosted Llama or Mistral on vLLM where data residency or cost demand it. pgvector, Pinecone, Weaviate for vector storage. LangGraph, LlamaIndex and the Vercel AI SDK for orchestration.

The stack is not the value. The value is the judgement to know which combination is right for which problem, and the discipline to use it consistently across the team.

How to choose a software development company in the UK

If you are not yet sure iCentric is the right partner for your build, we would still rather you made a good choice than a quick one. Here is what we tell friends-of-the-firm to look for when they are choosing a software development company - whether or not they choose us.

Look past the case studies. Every agency has glossy case studies. The real signal is the documentation: ask for an example architecture decision record, a sample sprint report, and a redacted post-incident review. Agencies that produce these as a matter of course will share them. Agencies that do not, will not.

Check how seniority is distributed. Ask, in writing, what the average years-of-experience is on the team that would actually deliver your project, and what the ratio of senior to mid to junior engineers is. The answer should be specific, not a marketing line. If the people on the pitch deck are not the people on the project, that is a red flag that compounds over time.

Ask how they handle scope change. Scope will change. The question is how. A serious agency will describe a written change-control process, a capped change budget within the contract, and a clear escalation path when something is genuinely out of scope. An agency that says "oh, we are flexible" is one that will either burn out trying to absorb every change or send you a surprise invoice in month four.

Verify the compliance basics. ISO 27001 certification, Cyber Essentials Plus, evidence of a documented information security management system, professional indemnity and cyber liability insurance at sensible levels, and a written data processing agreement they have signed before. If they cannot produce these in week one of conversation, they cannot produce them in week ten.

Reference calls. Ask for two reference calls with past clients in your sector or with a similar problem shape, and insist on at least one client whose engagement ended (rather than is ongoing). How an agency behaves after a contract ends is more informative than how they behave during it.

Beware the cheapest quote. Software development has a narrow range of honest prices for any given outcome. A quote 40% below the others is not a bargain; it is either a misunderstanding of the scope, an understaffed team, or a bait-and-switch on change orders. The cheapest quote is almost always the most expensive once delivered.

Compliance, security and UK data protection

If you are buying software development in the UK in 2026, the compliance and data protection baseline is non-trivial - and rising. A serious software development partner treats that baseline as part of the build, not as an external audit to be passed.

UK GDPR and the Data Protection Act 2018 apply to almost everything we ship. We embed data protection by design and by default: data classification flows through the architecture, retention is configured per data category, deletion is supported (not just hidden), and DSAR responses are a self-serve admin function rather than a quarterly engineering project. We produce or update Records of Processing Activities and Data Protection Impact Assessments as part of delivery on any project that involves personal data of more than trivial sensitivity.

ISO 27001 is the operating standard for our internal information security management system. Cyber Essentials Plus is renewed annually. We carry professional indemnity and cyber liability insurance at levels appropriate to enterprise contracts. Where the client requires it, we extend our ISMS controls to the project environment (access controls, MFA, audit logging, vulnerability management, supplier risk).

Encryption at rest and in transit is a default. We use AWS KMS, Azure Key Vault or GCP Cloud KMS for key management, TLS 1.3 in transit, AES-256 at rest. Secrets never live in code or configuration files; they live in a secrets manager and are injected at runtime via IAM roles.

PCI DSS scope reduction is core work on any e-commerce or payments engagement. We default to tokenisation through Stripe, Adyen, Braintree or a comparable PSP so that primary account numbers never touch our clients' infrastructure, dropping PCI scope from full SAQ-D to SAQ-A or SAQ-A-EP wherever possible.

Sector-specific compliance is built in where relevant. FCA SYSC and operational resilience requirements for financial services. DTAC, DCB0129 and DCB0160 for NHS-adjacent healthcare. MHRA Software as a Medical Device classifications for medtech. The Online Safety Act for consumer platforms with user-generated content. The EU AI Act for in-scope AI features. None of these are reasons not to ship; all of them are reasons to engage a partner who takes them seriously from day one.

Client outcomes and case studies

We judge ourselves by the outcomes our clients can take to their boards. A selection from the past 24 months:

Lloyd's-market insurance broker - quote-and-bind platform. Replaced an inbox-and-spreadsheet workflow with a typed React and NestJS quoting platform integrated with the broker's policy admin system. Manual handling per quote down 71%, error rates down 84%, freed underwriting capacity used to win £3.2m of new gross written premium in the first year.

National NHS triage service - patient-facing web and mobile app. Built to DTAC and DCB0129 standards in 16 weeks, with WCAG 2.2 AA accessibility throughout. 18,000 patients onboarded in the first six months, 92% completing self-triage without contacting the service desk, and a clinical safety case the client could present to commissioners on day one.

Mid-market UK e-commerce brand - headless replatform. Migrated from a heavily customised legacy storefront to Next.js commerce on Shopify Plus headless, with a fresh design system and an event-driven integration layer. Conversion rate up 34%, TTFB down 52%, organic non-brand traffic up 41% within six months of launch.

National logistics operator - driver and depot platform. React Native driver app with offline-first sync, plus a depot operations web app, replacing a clipboard-and-radio workflow across 1,200 vehicles. POD disputes down 80%, average drop-off time down 90 seconds, depot ops admin time reduced by 22 hours per depot per week.

B2B SaaS scale-up - MVP to Series A. Discovery, MVP, beta and public launch over 14 months. From zero to £2.3m ARR, SOC 2 Type I in month nine, 14 enterprise design partners, and a successful Series A close on the strength of the product the squad shipped.

UK financial services - legacy modernisation. Strangler-fig migration from classic ASP and SQL Server 2008 R2 to .NET 8 and PostgreSQL across 23 functional slices. Legacy fully decommissioned in 18 months, infrastructure cost down 62%, feature velocity up 4x compared to the year before engagement.

References and longer case-study write-ups are available on request after an initial scoping conversation.

Working with iCentric versus offshore-only providers

We are often asked how we compare on price with offshore-only providers. The honest answer is that we are typically 1.5x to 2.5x more expensive per engineer-hour than a Tier-1 offshore agency in South or South-East Asia, and roughly comparable with strong nearshore providers in Eastern Europe. Whether that gap is justified depends on what you are buying.

What you get for the premium: a UK timezone working day with synchronous availability for your stand-ups and stakeholder workshops, a UK contract with UK case law as the dispute mechanism, senior-led pods with no pyramid staffing, product thinking that pushes back on scope rather than accepting whatever ticket arrives, and continuity of personnel measured in years rather than months.

What you do not get: rock-bottom blended rates, an army of junior engineers on a project that does not need them, or a partner who is asleep when your customers are awake.

For many clients, the right answer is a blended model: a UK-based product, design and tech-lead capability provided by iCentric, plus a tightly integrated offshore engineering team either through us or through a partner agency we have worked with for years. We are completely transparent about this when we propose it, we never disguise offshore work as UK work in our rate card, and we have a network of partners we trust enough to share clients with.

The wrong answer is to buy your entire engineering function from the cheapest available offshore provider, hope for the best, and discover at month nine that nobody has been thinking about your product strategy, your security posture or your scope. We have rescued enough of those engagements to be opinionated about it.

Frequently asked questions

How much does custom software cost in the UK? For a clearly scoped MVP, expect £45,000 at the lowest end and £80,000-£250,000 for most production-grade first releases. Larger enterprise platforms typically sit between £400,000 and £2m for an initial release, with ongoing investment beyond that. Dedicated squads at iCentric start at £18,500 per month per engineer-equivalent. Anything materially below those numbers usually reflects misunderstood scope rather than genuine market pricing.

How long does an MVP take? A tightly scoped MVP can ship in 8-12 weeks. A more typical SaaS MVP takes 14-20 weeks from kick-off to public launch, with a private beta period in the middle. Enterprise builds and regulated-sector products take longer, primarily because of the security, accessibility and integration work, not because of the core engineering.

Do you sign NDAs and IP assignment up front? Yes, we sign mutual NDAs before the first technical conversation if you would like one, and our standard Statement of Work assigns all intellectual property in the deliverables to you on payment. We have no interest in retaining rights to client-specific code.

Who owns the code, the cloud accounts and the third-party subscriptions? You do. We work in cloud accounts you own, with third-party subscriptions (Stripe, Auth0, Datadog, etc.) billed to your accounts. We use seat-based access into your tooling. If we part ways, there is nothing to transfer because we never had it in the first place.

What happens after go-live? Most clients move into a steady-state retainer covering ongoing development, support, security patching and continuous improvement. Retainers run on 30-day rolling notice. We do not believe in lock-ins.

Can you take over a project from another agency? Yes, regularly. We run a structured takeover process covering code review, security review, infrastructure inventory, knowledge transfer and a stabilisation sprint before resuming new feature work. Honest takeover engagements take 2-6 weeks of stabilisation before velocity is comparable to a greenfield squad.

Do you work with start-ups or only with established businesses? Both. We have a specific engagement model for funded start-ups (Seed and Series A) that combines a fixed-scope MVP with an option to convert into a dedicated squad on launch. We do not work with pre-funded start-ups on equity-only or deferred-fee terms.

Where are your team based? UK-wide, with offices in London and Manchester. All client-facing roles are UK-based. Some specialist engineering work is delivered through long-standing nearshore and offshore partners, always disclosed up front and never disguised as UK-delivered.

Book a scoping call with our software development team

If you have read this far, you already know more about how we work than most agencies will tell you across an entire sales cycle. The next step is a 45-minute scoping call with a senior engineer and a product lead - no slide deck, no pitch theatre, just a working conversation about the problem you are trying to solve.

Within five working days of the call, we will come back with an indicative budget and timeline, a recommended engagement model, and an honest view on whether we are the right partner. If we are not, we will tell you who we think is. If we are, we will propose either a fixed-price first phase or a two-week paid discovery sprint depending on which is the lower-risk way to start.

We sign mutual NDAs on request before the first conversation. We deliver UK-wide from offices in London and Manchester, with senior engineers across the country. To get started, drop a note via the contact form or email hello@icentricagency.com with a sentence or two about what you are trying to build. We will reply the same working day.