About us
An engineering practice, described plainly
Fer Eman is an IT company. We write software, integrate systems and look after the infrastructure that runs them. This page describes how the work is done and what we hold ourselves to, without claims that cannot be checked.
Sections: introduction, purpose, working principles, engineering mindset, collaboration, quality, responsible practice.
Introduction
We build software that other people have to live with. That constraint shapes every decision we make about structure, tooling and pace.
Work reaches us as a problem rather than a specification: a process that has outgrown spreadsheets, a product idea that needs a first working version, a system that behaves unpredictably under load, or an integration that keeps failing quietly.
We start by describing the situation accurately, in writing, in terms the people affected recognise. Only then do we discuss technology. This order prevents most of the expensive mistakes we would otherwise make later.
Company purpose
Make software a stable part of an organisation, not a recurring risk
Software becomes a liability when nobody understands it, when changes are frightening, or when the only person who could explain it has moved on. Our purpose is to remove that fragility from the systems we are responsible for.
In practice this means writing code that reads clearly, documenting decisions where they will be found, keeping deployment routine, and preferring solutions that a small team can maintain over solutions that impress on a diagram.
It also means being straightforward about limits. If an approach is likely to create problems later, we say so before it is built, even when it is the easier answer to give.
Working principles
- Say what is actually known
- Estimates come with assumptions attached. Unknowns are listed as unknowns rather than padded into a confident number.
- Write things down
- Decisions, constraints and open questions live in the repository and in short written updates, so context does not depend on memory.
- Deliver something usable early
- A narrow feature that works in production teaches more than a wide feature that is nearly finished.
- Leave the system tidier
- Every change includes the cleanup it implies. Deferred cleanup becomes the next team's problem.
- Respect the operational reality
- Software runs in an organisation with existing habits, tools and constraints. Solutions have to fit that reality to be adopted.
- Keep the feedback loop short
- Short cycles, visible environments and fast reviews reduce the cost of being wrong.
Precision at the small scale is what makes the large scale predictable.
Engineering mindset
Treat every system as something that will change
Requirements move. Traffic patterns shift. Integrations change their contracts without warning. We assume all of this from the start and design for replacement rather than permanence.
Concretely: clear module boundaries, dependencies pointing inwards towards the domain, side effects pushed to the edges, and tests written at the level where behaviour is actually meaningful.
We resist premature abstraction. A pattern earns its place after the third real use, not in anticipation of a use that may never arrive.
Performance is treated as a measured property, not an opinion. We profile before optimising and keep the measurement in the test suite so improvements do not quietly regress.
Approach to collaboration
Written first, meetings second
Most coordination happens in writing. A written question can be answered carefully, revisited later and shared with someone who was not in the room. Meetings are kept for the decisions that genuinely need discussion.
Clients see progress as running software in an environment they can open. That removes the ambiguity of status reports and lets feedback arrive while it is still cheap to act on.
Where a client has an internal team, we work alongside it: shared repository conventions, joint reviews and handover as a continuous activity rather than a final event.
- Enquiries and decisions recorded in writing
- Short written updates during active development
- Increments deployed to a reviewable environment
- Shared repository access from day one
- Reviews open to the client's engineers
- Documentation updated with the code it describes
Quality and maintainability
Maintainability is measured by how safely the next change can be made
Tests where they matter
Automated coverage concentrated on domain rules, integration boundaries and the flows a user depends on, rather than on percentages.
Consistent structure
One way of doing common things across a codebase, so a new contributor can predict where code lives before opening a file.
Operational readiness
Health checks, structured logs, alerting and a documented recovery path exist before a system carries real work.
Reviewed changes
Every change is read by another engineer. Review covers intent and consequences, not only syntax.
Controlled dependencies
Third-party packages are chosen deliberately, kept current and removed when they stop paying for themselves.
Honest defect handling
Bugs are reproduced, covered by a test and then fixed, so the same failure does not return unnoticed.
Responsible technology practices
Collect less, explain more, degrade gracefully
Data minimisation
A feature should ask for the least data that makes it work. Fields that exist only in case they become useful are not built.
Accessibility as a requirement
Keyboard operation, contrast, semantic structure and readable typography are part of the definition of done, not an audit item.
Transparency about behaviour
Systems explain what they are doing, what failed and what happens next, in language the person using them can act on.
Environmental restraint
Efficient queries, right-sized infrastructure and fewer redundant background jobs reduce both cost and energy use.
Third-party caution
External scripts and services are added only when necessary, and their data implications are reviewed before integration.
Graceful failure
When a dependency is unavailable, the system says so and preserves work in progress instead of losing it silently.
The everyday setting of the work
Planning happens on paper before it happens in code. Interfaces are sketched, flows are argued over, and only the parts that survive that scrutiny are implemented.
Written enquiries reach the team at tiffanygriffin462@gmail.com.