Feel & Heal
§ 03 · Services
Fourteen practice areas

A catalogue of
technical work.

The list below is the full inventory of work FEEL AND HEAL LTD accepts. Each entry describes what the service includes, the problem it addresses, the typical stages of the work, the value it produces, and how we approach it.

We publish scope and approach rather than prices. Prices depend on the size of the system, the level of assurance required, and the constraints of the organisation, and we prefer to discuss them in writing after a first conversation.

01
Practice area

Custom software development

Includes

End-to-end design and implementation of software written specifically for a client's operational context — from initial technical assessment through architecture, build, test, deployment, and post-launch operation.

Problem it solves

Off-the-shelf software forces the business to reshape itself around the tool. Custom software reshapes itself around the business, at the cost of ownership.

Typical project stages
  1. 01Discovery and technical assessment
  2. 02Architecture and design notes
  3. 03Iterative build with weekly increments
  4. 04Instrumentation and observability
  5. 05Release and post-launch operation
02
Practice area

Web application development

Includes

Design and construction of web software — server-rendered, single-page, or hybrid — including front-end, back-end, authentication, data layer, and delivery infrastructure.

Problem it solves

Web software is where most organisations meet their customers. Slow, inaccessible, or unreliable web applications cost trust in ways that are difficult to recover.

Typical project stages
  1. 01Interaction and information architecture
  2. 02Component and design system implementation
  3. 03Server, API, and data-layer construction
  4. 04Performance and accessibility hardening
  5. 05Delivery pipeline and content workflows
03
Practice area

Mobile application development

Includes

Native (Swift, Kotlin) and cross-platform (React Native, Flutter) mobile clients, along with the back-end services, offline behaviour, and release engineering they require.

Problem it solves

Mobile software operates in adversarial conditions: variable networks, constrained batteries, and app-store gatekeepers. Naïve mobile builds break in the field in ways that are invisible during development.

Typical project stages
  1. 01Platform strategy and technology selection
  2. 02Offline-first data design
  3. 03UI implementation aligned with platform conventions
  4. 04Store submission and release pipeline
  5. 05Crash reporting and analytics wiring
04
Practice area

UI and UX implementation

Includes

Translation of interface designs into production code — component libraries, design tokens, accessibility, responsive behaviour, motion, and interaction detail.

Problem it solves

A designed interface that is implemented approximately is worse than one that is not designed at all. Fidelity between design and implementation is a discipline of its own.

Typical project stages
  1. 01Design-system and token architecture
  2. 02Component implementation with documentation
  3. 03Cross-browser and device verification
  4. 04Accessibility audit against WCAG guidance
  5. 05Handover artefacts for design and engineering
05
Practice area

Cloud solutions

Includes

Cloud architecture, migration, cost review, and multi-region topology work across AWS, Google Cloud, Azure, Cloudflare, and specialist providers.

Problem it solves

Cloud spend, latency, and reliability are outcomes of architecture. Once a topology is in production, it becomes progressively more expensive to change.

Typical project stages
  1. 01Current-state review of accounts and workloads
  2. 02Reference architecture and design notes
  3. 03Migration plan with rollback path
  4. 04Automation of environments as code
  5. 05Cost and reliability baselining
06
Practice area

Infrastructure modernization

Includes

Replatforming legacy systems onto contemporary infrastructure with minimum operational risk. Includes containerisation, orchestration, CI/CD, and observability rebuilds.

Problem it solves

Older systems accumulate manual operational knowledge that lives in the heads of a small number of people. When those people leave, the system becomes fragile.

Typical project stages
  1. 01Inventory of existing workloads and runbooks
  2. 02Target architecture and migration waves
  3. 03Automation of build, test, and deploy pipelines
  4. 04Cutover with parallel-run verification
  5. 05Decommissioning and documentation
07
Practice area

API development and integration

Includes

Design and construction of internal and external APIs — REST, GraphQL, gRPC, event streams — and the third-party integrations that surround them.

Problem it solves

APIs are contracts. Poorly designed contracts are difficult to evolve, and integrations built on them become a source of continuous defects.

Typical project stages
  1. 01Domain modelling and contract design
  2. 02Versioning strategy and deprecation policy
  3. 03Implementation with automated contract tests
  4. 04Documentation and client SDKs
  5. 05Rate-limiting, authentication, and observability
08
Practice area

Cybersecurity consulting

Includes

Threat modelling, source and configuration review, identity and access architecture, incident response readiness, and supply-chain risk analysis.

Problem it solves

Most security incidents are the result of ordinary engineering mistakes, not exotic attacks. Preventing them is an engineering discipline before it is a security discipline.

Typical project stages
  1. 01Scope and asset inventory
  2. 02Threat model workshop
  3. 03Code and configuration review
  4. 04Findings report with prioritised remediation
  5. 05Follow-up verification
09
Practice area

Data analytics

Includes

Data ingestion, warehousing, transformation, and analytical modelling. Includes descriptive analytics, forecasting, and applied machine learning where warranted.

Problem it solves

Organisations are frequently rich in data and poor in evidence. The gap is usually a lack of trustworthy pipelines, not a lack of dashboards.

Typical project stages
  1. 01Source system audit and event definition
  2. 02Warehouse and lake architecture
  3. 03Transformation and testing with dbt or equivalent
  4. 04Analytical models with monitored inputs
  5. 05Consumer-facing reporting and self-service
10
Practice area

Business automation

Includes

Replacement of manual, repetitive operational tasks with software workflows — internal tools, back-office automation, workflow engines, and integration glue.

Problem it solves

Operational teams spend significant fractions of their day on work that could be automated. That work is usually invisible to leadership until it fails.

Typical project stages
  1. 01Mapping of current-state processes
  2. 02Identification of automation candidates by risk and volume
  3. 03Iterative delivery of tools with human-in-the-loop where appropriate
  4. 04Runbook and training material
  5. 05Post-launch measurement
11
Practice area

Quality assurance and software testing

Includes

Test strategy design, test automation implementation, exploratory testing, accessibility auditing, and evidence collection integrated into continuous integration.

Problem it solves

Test suites that were written without a strategy accumulate flakiness and coverage gaps that erode confidence in the pipeline.

Typical project stages
  1. 01Risk-based test strategy
  2. 02Test framework and infrastructure selection
  3. 03Automation of unit, integration, and end-to-end suites
  4. 04Non-functional testing (performance, accessibility, security)
  5. 05Reporting and evidence capture
12
Practice area

Technical support and maintenance

Includes

Ongoing operation of software built by FEEL AND HEAL LTD or by others — monitoring, dependency upgrades, incident response, and periodic architecture review.

Problem it solves

Systems degrade even when nothing changes on the surface. Dependencies age, certificates expire, and quiet defects accumulate until a visible one arrives.

Typical project stages
  1. 01Runtime and dependency inventory
  2. 02Monitoring and alerting baseline
  3. 03Scheduled dependency and security updates
  4. 04Incident response with post-incident reviews
  5. 05Quarterly architecture review
13
Practice area

IT consulting

Includes

Independent advisory work on technology strategy, vendor selection, engineering-organisation design, technical due diligence, and executive briefings.

Problem it solves

Technology decisions made without engineering input tend to be reversed at greater cost later. Independent advice, delivered in writing, changes that trajectory.

Typical project stages
  1. 01Framing conversation with the requesting stakeholder
  2. 02Structured interviews with affected teams
  3. 03Written assessment with options and trade-offs
  4. 04Presentation and question-and-answer session
  5. 05Follow-up as requested
14
Practice area

Digital transformation

Includes

Programme-level modernisation of an organisation's technology estate — combining software, infrastructure, security, data, and operational change into a coherent multi-year plan.

Problem it solves

Transformation programmes fail more often than they succeed, usually because they attempt too much at once, or because they treat technology change as separable from operational change.

Typical project stages
  1. 01Current-state assessment across systems and teams
  2. 02Target architecture and phased roadmap
  3. 03Foundation work (identity, platform, data model)
  4. 04Wave-based delivery with measurable outcomes
  5. 05Handover to internal engineering leadership