An engineering
practice, in the older sense of the word.
FEEL AND HEAL LTD is an independent technology practice. We design, build, secure, and operate software systems on behalf of organisations that depend on those systems to function.
The practice is organised around a small number of engineers, architects, and analysts who take direct responsibility for the work they sign. We do not maintain a sales team, and there is no separation between the people a client speaks to and the people who edit the code.
We work on the parts of technology that are permanent — the parts that are still there after the redesign, after the rebrand, after the change in leadership. That is a quieter form of work than the industry usually advertises, and it is the work we are interested in.
Make software worth trusting.
Our mission is to produce software and infrastructure that clients can operate confidently, extend safely, and understand thoroughly. Trust in software is earned in small, verifiable increments. Every engagement is measured by whether the client has more or less of it at the end.
A quieter kind of technology company.
We want FEEL AND HEAL LTD to be a practice that outlasts trends. That means growing carefully, refusing work we cannot deliver responsibly, and holding to engineering standards even when they are inconvenient. The measure of the practice is the systems still running years after we hand them over.
Six values, applied to the work rather than to the wall.
- 01Rigour
We prefer being correct to being fast, and we prefer being fast to being clever. Rigour is what allows an engineering team to move quickly without breaking things it did not intend to break.
- 02Transparency
Estimates, risks, and setbacks are shared as soon as they are known. Every architectural decision is written down. Nothing about an engagement should be a surprise to the client.
- 03Restraint
We add technology when the problem justifies it, and remove technology when the problem no longer does. A smaller system is easier to reason about, easier to secure, and cheaper to operate.
- 04Continuity
The engineers who design a system are the engineers who operate its first incidents. Continuity between design and operation is one of the strongest predictors of software that stays running.
- 05Trust
Client systems, credentials, and data are handled as if they were our own. Access is minimised, audited, and revoked promptly at the end of an engagement.
- 06Curiosity
The technology industry rewards people who keep reading. We treat time spent studying — languages, papers, other people's code — as part of the work, not a distraction from it.
The habits we return to on every project.
- Read before writing. No proposal is issued before we have read the existing systems, the tickets, and the runbooks. Nothing is invented in a vacuum.
- Design in writing. Every non-trivial technical decision is documented in a short design note. Verbal design decays.
- Deliver in small pieces. Working software in production every week, not every quarter. Small changes are easier to review, revert, and reason about.
- Automate the boring. Anything a person does more than three times becomes a script, a template, or a workflow. Human attention is reserved for judgement.
- Leave the campsite better. Every pull request improves the surrounding code, not just the line that changed.
A working relationship, not a supplier relationship.
Clients meet the engineers who will do the work in the first conversation, not later. Statements of work are written in plain language and describe outcomes and constraints, not activities.
We prefer to work as a named team embedded in the client’s engineering process — attending stand-ups, reviewing pull requests, and participating in incident response — rather than a black box behind a project manager.
We do not sub-contract work outside the practice without the client’s written agreement, and we do not resell the labour of others as our own.
Build the smallest useful thing, then the next.
We favour incremental product development: identify the smallest slice that delivers a real outcome, build it end-to-end, ship it, learn, and repeat. Big-bang releases are avoided wherever the domain permits.
Product decisions are validated with data where possible, and with structured user conversations where the data does not yet exist. Assumptions are labelled as such in writing.
Quality is not audited in at the end.
Testing, review, accessibility, observability, and documentation are built into the pipeline from the first commit. A feature that lacks tests, telemetry, or documentation is not considered finished.
We use static analysis, dependency review, and automated security scanning on every change. Issues found late are treated as process defects, not code defects.
Security is a design property, not a checklist.
We treat security and privacy as design constraints on every system we build. Access to client environments follows least-privilege principles; credentials are rotated; work is performed on managed workstations with disk encryption and endpoint protection.
Client data is not copied outside authorised environments except where the engagement explicitly requires it. Documentation, credentials, and repositories are inventoried and either transferred or destroyed at the end of an engagement, at the client’s instruction.
Our privacy commitments as an application operator are documented separately in the Privacy Policy.
The best engagements at FEEL AND HEAL LTD are the ones that quietly extend for years — a first project, followed by an operational partnership, followed by another project. We do not chase renewal for its own sake, but we design every relationship so that continuing is easy and stopping is graceful. Handover, in our practice, is not a phase; it is a design property present from the first day.