Services

What the work actually consists of

Fer Eman builds, integrates and maintains software systems. Each service below is described by what it includes, why it is usually needed, how we approach it and what has to be decided along the way.

Ten areas of work. Written enquiries: tiffanygriffin462@gmail.com

Disciplines

The same engineers who design a system are the ones who run it, so nothing here is described more confidently than we can support in production.

01 / 10

Web application development

Applications that live in a browser and are used daily by staff, customers or partners.

What it includes: Interface implementation, application logic, server-side code, database schemas, authentication, permissions and the deployment pipeline that puts changes in front of users.
Why it is needed: Work usually starts because a process has outgrown spreadsheets, email threads and manual handovers, or because an existing application has become too slow and fragile to extend.
How we approach it: We describe the process in writing first, agree the smallest version that is genuinely useful, then build it in short increments that can be reviewed by the people who will use it.
What has to be considered: Browser support, accessibility, load patterns, data ownership and who will maintain the application after handover are decided before implementation, not after.

02 / 10

Product engineering and first versions

A working first version of a product idea, built to be extended rather than demoed.

What it includes: Scope shaping, technical design, implementation of core flows, instrumentation, and a release process that allows frequent small changes.
Why it is needed: Teams come to us when an idea has to become something real that can be shown to users, tested against reality and changed quickly afterwards.
How we approach it: We separate what has to be right at the start (data model, boundaries, deployment) from what can be revised cheaply later (layout, copy, secondary flows).
What has to be considered: Early products change direction. We keep the structure simple enough to redirect and avoid building infrastructure for volumes that do not exist yet.

03 / 10

Systems integration

Making separate systems exchange data reliably and in a way that can be audited.

What it includes: API clients and endpoints, message queues, scheduled synchronisation, data mapping, retries, idempotency and logging of every exchange.
Why it is needed: Integrations are requested when data is re-entered by hand between tools, or when an existing connection fails silently and nobody notices until numbers disagree.
How we approach it: We treat failure as normal: every exchange is retryable, every record has a traceable identity, and mismatches surface as alerts rather than as quiet drift.
What has to be considered: Third-party rate limits, contract changes, ordering guarantees and how much history has to be reconciled during the first synchronisation all affect the design.

04 / 10

Cloud infrastructure

The environments applications run in, described in code and reproducible from scratch.

What it includes: Environment definition, networking, secrets handling, deployment automation, backups, monitoring and cost visibility.
Why it is needed: This work is needed when deployments are manual and undocumented, when environments differ from each other, or when nobody is certain a restore would succeed.
How we approach it: Infrastructure is written as configuration and versioned alongside the application, so any environment can be rebuilt deliberately rather than remembered.
What has to be considered: Data residency, recovery objectives, expected traffic and the operational skills of the team that inherits the setup shape how much automation is appropriate.

05 / 10

Data engineering and reporting

Moving operational data into a shape that questions can be answered from.

What it includes: Schema design, extraction and transformation jobs, validation rules, historical loads and reporting views or dashboards.
Why it is needed: Requests arrive when reports are assembled by hand each month, or when two departments produce different figures from the same underlying records.
How we approach it: We define each metric in writing with the people who use it, then implement it once, in one place, so the definition and the number cannot diverge.
What has to be considered: Data quality at the source, timezone handling, late-arriving records and retention rules matter more than the choice of visualisation tool.

06 / 10

Security practice

Reducing the ways a system can be misused, and knowing when it has been.

What it includes: Authentication and authorisation review, dependency and configuration auditing, secrets management, access control, logging and incident procedure.
Why it is needed: Security work is commissioned before launch, before an audit, after an incident, or when access has accumulated across years of staff changes.
How we approach it: We work from the boundaries inwards: identify what is exposed, verify who can reach it, remove privileges that are no longer needed and make remaining access observable.
What has to be considered: Regulatory obligations, third-party processors, the sensitivity of stored data and the realistic threat model determine how far controls should go.

07 / 10

Testing and quality engineering

Automated checks that make change safe rather than merely reported.

What it includes: Unit and integration tests, end-to-end coverage of critical journeys, test data management and continuous integration that blocks broken changes.
Why it is needed: Teams ask for this when releases are followed by firefighting, or when developers hesitate to touch code because the consequences are unknown.
How we approach it: We cover the paths whose failure would be expensive first, keep the suite fast enough to run on every change, and delete tests that only assert implementation details.
What has to be considered: Test suites are code and need maintenance. We prefer fewer meaningful checks over broad coverage figures that hide untested behaviour.

08 / 10

Maintenance and system care

Ongoing responsibility for software that is already in production.

What it includes: Dependency and runtime updates, monitoring and alert response, performance work, bug fixing and small changes requested during normal operation.
Why it is needed: Maintenance is arranged when a system matters to daily work and there is no internal team to keep it patched, observed and understood.
How we approach it: Recurring work is scheduled instead of postponed: updates in batches, an alerting policy that distinguishes urgency, and written records of every change made.
What has to be considered: Response expectations, access arrangements and the boundary between maintenance and new development are agreed in writing before work begins.

09 / 10

Legacy modernisation

Changing systems that are still in use and cannot be switched off.

What it includes: Assessment of the existing system, documentation of current behaviour, incremental replacement of components and data migration.
Why it is needed: Modernisation is needed when a system still works but is unsupported, undocumented, expensive to host, or impossible to hire for.
How we approach it: We replace parts in sequence behind stable interfaces, keeping the old and new paths running together until the new one has proven itself with real data.
What has to be considered: Undocumented behaviour is usually load-bearing. We verify what a system actually does before assuming any of it is unnecessary.

10 / 10

Technical consulting and review

An outside reading of architecture, code or plans, delivered in writing.

What it includes: Architecture review, code and dependency assessment, cost and risk analysis, technology selection and delivery planning.
Why it is needed: Consulting is requested before committing to a direction, during due diligence, or when internal opinions about a rebuild are deadlocked.
How we approach it: We read the system and talk to the people running it, then write findings with the trade-offs stated plainly and the recommendations ordered by consequence.
What has to be considered: A review is only useful if it can be acted on, so recommendations account for the team, budget and timeline that actually exist.

How engagements run

Written scope, short increments, visible progress.

Every engagement begins with a written description of the problem and ends with documentation, access and the ability for someone else to continue the work.

Close view of an application interface being reviewed on a wide display

Server infrastructure racks in a cooled data centre aisle

Diagram of a data architecture drawn across a whiteboard

Engineer inspecting access logs and security configuration on screen