Enterprise Software Development

Multi-tenant B2B SaaS platforms and enterprise systems where each customer organisation operates in a fully isolated data environment, with no possibility of data leakage between tenants regardless of query construction. Tenant isolation strategy chosen at the data model layer before development begins: row-level security (PostgreSQL RLS policies) for deployments where all tenants share a schema but access is filtered by tenant ID; schema-per-tenant for stronger isolation with easier per-tenant data export and deletion; database-per-tenant for the highest isolation tier required by enterprise security reviewers. Tenant provisioning automates the entire onboarding sequence: database schema creation or RLS policy seeding, default configuration population, initial admin user creation, and welcome email dispatch, a new customer goes from signed contract to working environment in under 60 seconds. Per-tenant configuration covers: feature flags (enterprise tier gets analytics, starter tier doesn't), custom branding (logo, colour scheme, domain), data retention policies, and SSO configuration. Subscription and licence management via Stripe Billing with usage-based metering where applicable. The admin panel your team uses to manage the tenant list, suspend accounts, impersonate users for support, and monitor per-tenant usage, built alongside the product, not as an afterthought.

Purpose-built ERP extensions and back-office systems for organisations whose processes don't map cleanly to a standard module, where the gap between the vendor's template and your actual workflow has turned into a permanent workaround maintained by staff who were trained on a process nobody intended. Custom approval workflows with configurable approval chains: multi-level sign-off, value-threshold routing (invoices under £10,000 auto-approve, above require finance director sign-off), delegation rules when approvers are unavailable, and an escalation path when approvals sit idle beyond a configurable window. Business rule engines built as configurable logic rather than hardcoded conditions: tax calculation rules by jurisdiction, pricing logic by customer tier and volume, compliance checks by product category or destination country, maintainable by business analysts without a code deployment. Document generation via WeasyPrint or a templated PDF engine: purchase orders, compliance certificates, customer-facing reports, and operational documents generated from system data and emailed or archived automatically. Inventory and procurement workflows: PO creation and approval, goods receipt confirmation, three-way matching (PO vs. goods receipt vs. invoice), and variance reporting. Built for the specific operational logic of your industry rather than a generic ERP template.

Middleware and integration layers that connect enterprise systems that weren't designed to talk to each other, SAP, Oracle E-Business Suite, Salesforce, Workday, Microsoft Dynamics, and third-party vendor APIs, so data flows between systems without manual re-entry or scheduled exports that arrive a day late. Integration patterns chosen per use case: REST API polling with incremental timestamp queries for systems that expose APIs, event-driven webhooks where systems support real-time notifications, Kafka-based event streaming for high-volume bidirectional sync where ordering and replay matter, and scheduled ETL for systems that only export batch files. Transformation logic maps field formats, data types, and business entity representations between systems, an "Account" in Salesforce and a "Customer" in your ERP are the same entity with different field structures, and the transformation layer maintains that mapping as both systems evolve. Error handling with dead letter queues: failed integration events are captured with the original payload, error reason, and retry count so they can be investigated and replayed manually without data loss. Integration health monitoring dashboard shows: events processed per hour per pipeline, current queue depth, failed events requiring attention, and last successful sync timestamp, giving your IT team visibility into what's flowing and what's blocked without reading log files.

Access control systems with fine-grained role and permission models reflecting your actual organisational structure: not just "admin" and "user" but department-level roles (Finance Manager can approve invoices, Finance Analyst can view only), team-level permissions, and record-level access (a salesperson sees their own accounts, a regional manager sees their region's accounts, the VP sees all). Attribute-based access control (ABAC) for complex rule sets that role-based models can't express without role proliferation. Full audit trails for data access, field-level changes, and approval decisions, stored in an append-only log table with a hash chain that makes tampering detectable. Audit exports formatted for compliance review: SOC 2 Type II evidence packages, ISO 27001 access reviews, HIPAA access logs, and GDPR data access records. SSO integration with Active Directory (SAML 2.0 or LDAP), Okta, Azure AD, and Google Workspace, users log in with their corporate credentials, account provisioning and deprovisioning follows HR system events. Multi-factor authentication (TOTP, hardware keys via WebAuthn/FIDO2) for roles with elevated access. Session management with configurable timeout, concurrent session limits, and session revocation for terminated employees. All compliance controls designed into the data model before development begins, not retrofitted after a security review requests them.

Enterprise mobile apps for field teams, inspectors, technicians, and operational staff who need access to enterprise systems away from a desk, on construction sites, in warehouses, during site visits, and in facilities with unreliable connectivity. Offline-first architecture using SQLite (Drift ORM for Flutter, Room for Android, Core Data for iOS) stores the data set the user needs for a full work day; background sync pushes completed work to the backend when connectivity resumes, with conflict resolution for records edited simultaneously on multiple devices. Data capture optimised for the field context: large tap targets for gloved hands, barcode and QR code scanning via the device camera, photo capture with automatic metadata tagging (GPS coordinates, timestamp, device ID), and voice-to-text for notes in environments where typing is impractical. Approval workflows that follow the user into the field: a site supervisor approves a purchase request on their phone; the approver receives a push notification and approves without opening a laptop. Integration with backend enterprise systems via REST APIs with retry queuing for intermittent connectivity. Distribution via MDM (Jamf, Intune), Apple Business Manager, or Android Enterprise Managed Google Play, no App Store review dependency for updates.

Planned migration from aging enterprise systems, on-premises platforms, unsupported desktop applications, end-of-life ERP modules, and proprietary systems the original vendor stopped supporting, to modern web-based enterprise software on a timeline the business controls. Migration begins with a structured audit: what the system actually does (including undocumented business logic embedded in stored procedures, macros, and hardcoded lookup tables), what data it holds (schema reverse-engineering and entity relationship documentation), what integrations depend on it, and what the replacement scope requires. Data migration strategy designed before development begins: data profiling identifies quality issues (duplicate records, referential integrity violations, inconsistent formats) that must be cleaned before cutover; migration scripts are tested against a non-destructive copy of production data with row count and integrity validation; at least 3 dress rehearsal runs confirm the migration completes within the cutover window. Parallel running period: old and new systems operate simultaneously while the new system is validated against real operational data; cutover happens in a planned window with a tested rollback plan. The strangler fig pattern incrementally decommissions modules rather than requiring a single big-bang cutover, the business continues operating throughout. Data archiving strategy for historical records that must be preserved for legal or compliance reasons but don't need to live in the active system.