Custom Software

Custom software development begins with the work, not a feature list. We observe who acts, what starts the process, which information they need, where a decision is made, what changes state, who owns an exception and how completion is recognised. The same business problem may be solved by removing a step, correcting data, configuring an existing platform, joining two systems or building a new product. Writing code is one option, not the default answer.

The build decision compares available products, licence and exit terms, configuration depth, integration access, security, accessibility, data portability, vendor dependence and total operating cost. Buying can be faster when the process is conventional. Extending can preserve a useful platform while covering a distinctive journey. Bespoke software earns its continuing maintenance burden when an evidenced workflow, domain model, integration boundary or product experience cannot be represented cleanly enough by the available choices.

A written product boundary names users, roles, journeys, features, data, reports, integrations, environments, devices, languages, accessibility target, migration, training, acceptance, release, intellectual-property terms and post-launch ownership. It also separates discovery, prototype, minimum viable product, production release and continuing operation. An MVP is the smallest coherent product that can test a stated risk; it is not the complete ambition delivered cheaply or an excuse to omit essential security and recovery behaviour.

Delivery does not guarantee adoption, revenue, efficiency, compatibility, security, availability or a fixed completion date before the scope and dependencies are verified. We can accept observable behaviour: a named user completes a defined task, the correct rule changes state, data reconciles, an unauthorised action is denied and the operator can detect and recover an agreed failure. Business effects are measured after release against a documented baseline rather than attributed to the existence of software.

A maintainable system uses the language of the operation. We define the important actors, records, events, rules, states and invariants with the people who own them. Terms that sound similar are separated when they carry different obligations; a lead, customer, account, contract and user are not interchangeable. State changes name their authority and evidence. This domain model becomes a shared reference for interface copy, data, APIs, tests, reports and operating decisions.

For every material field we identify its source of truth, owner, sensitivity, freshness, validation, edit authority, retention and conflict rule. Derived values expose their formula and source time. Imports and migrations include mapping, transformation, rejected records, reconciliation and rollback rather than assuming that a successful upload means correct data. Production information is not copied into development environments without an authorised and proportionate protection plan.

Architecture follows actual constraints. We consider transaction boundaries, expected load, latency, offline needs, geographic and contractual restrictions, recovery objectives, team capability, deployment model and the cost of change. A modular application may be safer and easier to own than premature microservices; a managed service may be more responsible than a bespoke component. We document the chosen boundaries and rejected alternatives so future teams know which conditions would justify a different design.

Integrations are explicit contracts. Each API, webhook, queue or file exchange names direction, identity, version, schema, validation, authorisation, idempotency, rate limits, expected delay, retries, ordering, error handling, observability and owner. OpenAPI can describe an HTTP interface, but a document alone does not settle business meaning or reliability. Consumer and provider behaviour is tested at the boundary, including partial failure, duplicate delivery, stale data and an unavailable dependency.

The delivery plan orders work by risk and usable outcome. A vertical slice joins interface, rule, data and integration for one real journey, making assumptions visible earlier than separate piles of screens and backend tasks. The backlog records purpose, acceptance, dependencies and unresolved decisions. Design prototypes answer interaction questions; technical spikes answer uncertainty; neither is presented as production-ready software. Demonstrations use representative scenarios, including failure and permission boundaries.

Source code lives in an agreed repository with review, traceable change and protected release rules. Automated checks are selected for the system: unit and component tests for rules, contract tests for interfaces, integration tests for boundaries, end-to-end tests for critical journeys, and migration or performance tests where risk requires them. Passing tests are evidence about the tested version and environment, not proof that no defect or vulnerability exists.

Build and release paths separate code from environment-specific configuration. Secrets are not committed to source; permissions, rotation and emergency access are defined. Dependencies are selected deliberately, pinned or constrained appropriately, scanned and updated through a controlled route. Development, test, staging and production differences are recorded. Continuous integration and deployment reduce manual variance only when approvals, artefact provenance, environment protection and rollback are also clear.

Changes remain small enough to review and recover. Database evolution considers old and new application versions, backfill, validation and rollback limitations. Feature controls, progressive exposure or parallel operation are used where they materially reduce release risk. Performance work starts from representative journeys and service indicators rather than synthetic vanity scores alone. Decisions, exceptions, known debt and residual risk remain visible at acceptance instead of disappearing inside a ticket history.

Security requirements begin with the product's users, data, actions, trust boundaries and plausible misuse. The threat model follows identity, authorisation, input, business logic, data storage, communications, administration, dependencies and recovery. NIST's Secure Software Development Framework provides a common structure for integrating secure practices into the development lifecycle. The selected practices and evidence are stated; mentioning the framework does not mean every task or outcome has been independently certified.

For web applications, an agreed subset and level of OWASP ASVS can turn vague security language into versioned verification requirements. We connect applicable requirements to design, implementation and tests, record what was checked, resolve material findings and disclose exclusions and residual risks. Independent penetration testing, certification, regulatory analysis, continuous security monitoring and incident response are separate scopes unless the proposal expressly includes them. No system is described as absolutely secure.

Privacy, accessibility and international use are product concerns. Data minimisation, retention, deletion, audit, test data, analytics and support access are considered with the responsible client and advisers. The agreed WCAG 2.2 target is reflected in structure, keyboard use, focus, errors, status, contrast, reflow, authentication and representative tasks; automated scans are only part of that work. Languages are written and tested as real interfaces, including right-to-left layout, dates, names, numbers and mixed-direction content.

Reliability is defined from user-relevant service indicators. Availability, latency, successful processing, data freshness, queue age or recovery may matter differently across journeys. An SLI measures an observed aspect; an SLO sets an internal target; an SLA is a contractual commitment with stated consequences. We do not turn one into another. Failure modes, monitoring coverage, backup, restoration, capacity and dependency limits are written alongside the target so the team knows what can be detected and recovered.

Acceptance uses representative roles, data and environments. It covers the intended journey, invalid input, denied action, duplicate request, unavailable integration, delayed job, partial migration, mobile and keyboard use, localisation, degraded performance and recovery where applicable. Evidence links a requirement to the tested build and result. A defect list distinguishes release blockers, accepted limitations and later improvements; a demonstration is useful, but it does not replace written acceptance.

Release planning names the artefact, environment, configuration, secrets, data movement, domain and certificate changes, communication, maintenance window, decision authority and rollback. A rehearsal is used for steps that could corrupt data or interrupt important work. Migration totals are reconciled, background jobs and integrations are observed, and the rollback boundary is honest: some external actions or irreversible data changes may require compensation rather than a simple technical reversal.

Handover covers repository and source access, intellectual-property terms, architecture and decision records, domain model, data dictionary, interface contracts, environment inventory, dependency register, build and release route, tests, known risks, operating runbooks and administrative procedures. Ownership follows the signed proposal; open-source and third-party rights remain subject to their licences. A source archive without reproducible build knowledge, credentials ownership and operating context is not a complete transfer.

Ongoing operation is a separate written responsibility. It may include monitoring, incident and problem handling, dependency maintenance, vulnerability response, backups, restoration tests, capacity, cost review and a defined change allowance. Hours, channels, response expectations, escalation and exclusions are explicit. No 24/7 cover, fixed response, uptime commitment, unlimited changes or indefinite support is implied by the development commission.

AI features receive their own boundary. We name the model and knowledge sources, data route, permissions, evaluation cases, human authority, refusal and fallback behaviour, logging, cost and change control. A model may assist search, classification, extraction or drafting, but it does not become the unobserved source of truth or take an irreversible high-impact action by default. Accuracy, availability and provider behaviour are measured within the agreed context rather than promised universally.