Custom software development
Applications built for a specific operational need, from schema to interface, with the reasoning documented as the system grows.
IT company · fereman.com
Software that keeps working after launch
Fer Eman designs, builds and maintains software systems for organisations that need their technology to be dependable, understandable and cheap to change.
Custom applications, web platforms, integrations, cloud infrastructure, quality assurance, security-focused engineering and long-term maintenance.
Written enquiries
[email protected]
Who we are
We are a software engineering practice. Our work is the unglamorous part of technology: careful design, readable code, honest estimates and systems that can be handed to someone else without a translator.
Projects arrive in different shapes. Some are new products with an empty repository. Others are systems that have been running for years and now need to do something they were never designed for.
In both cases the method is the same: understand the domain first, agree on what success looks like, then build in increments that can be reviewed while they are still cheap to change.
We prefer fewer moving parts over more. Every dependency, service and abstraction has to justify the maintenance it will require later.
Core technology capabilities
The technical ground the team works on day to day. These capabilities combine differently depending on the system being built.
- 01
Application engineering
Typed, tested application code across the front end and the server, structured around the domain rather than the framework.
- 02
Data modelling
Relational schemas, migrations, indexing and query design chosen for the access patterns the product actually has.
- 03
Interfaces on the web
Accessible, responsive interfaces that behave predictably on slow connections and small screens.
- 04
Distributed services
Service boundaries, queues, background processing and retry behaviour designed for partial failure.
- 05
Cloud operations
Reproducible environments, deployment pipelines, observability and cost-aware infrastructure choices.
- 06
Automated verification
Unit, integration and end-to-end tests run in continuous integration so regressions surface early.
Fig. 01 — System map: services, storage and the paths between them.
Services in detail
Full descriptions at fereman.com/services
Web application development
Product interfaces and internal tools delivered as web applications, with attention to accessibility, performance and state handling.
Product design and user experience
Flows, wireframes and interface systems developed alongside engineering so the design survives contact with real data.
Cloud and infrastructure
Environments defined as code, deployment pipelines, monitoring and the operational routines that keep a service available.
API and systems integration
Contracts between systems that already exist, including data mapping, error handling and safe migration of live traffic.
Software modernisation
Incremental replacement of ageing components without stopping the business that depends on them.
Quality assurance and testing
Test strategy, automation and review practices that make the state of a release visible.
Security-focused engineering
Authentication, authorisation, secret handling and dependency hygiene treated as part of ordinary development.
Technical consulting
Architecture review, technology selection and written recommendations for teams deciding what to do next.
Maintenance and improvement
Ongoing updates, defect resolution and small improvements after the first release.
How we approach a project
Understand first, then build the smallest useful thing
Frame the problem
Before any code, we describe the current situation in writing: what people do today, where the friction is, which systems are involved and what must not break.
Reduce the scope
A first release should be small enough to finish and complete enough to use. We separate what is essential from what can wait, and say so plainly.
Build and review in cycles
Work is delivered in increments to a running environment. Decisions are revisited with evidence rather than defended because they were made earlier.
Technology and engineering principles
These are working rules rather than slogans. They decide what gets written, what gets deleted and what never gets added in the first place.
- Clarity outranks cleverness
- Code is read far more often than it is written. A plain solution that a new engineer can follow is worth more than a compact one that only its author understands.
- Boring technology by default
- Established tools with long support histories are chosen unless the problem genuinely requires something newer. Novelty is a cost paid during maintenance.
- Make behaviour observable
- Logging, metrics and error reporting are added while a feature is built, not after an incident makes them necessary.
- Small, reversible steps
- Changes ship in pieces that can be reviewed, deployed and rolled back independently.
- Data outlives code
- Schemas and migrations are designed with the assumption that the data will be there long after the current application is replaced.
- Automate the repeatable
- Builds, tests, checks and deployments run the same way on every machine, so results do not depend on who ran them.
How collaboration runs
Six recurring stages
Stage 01
Enquiry
A written description of the problem and its context arrives by email. We reply with questions rather than a proposal.
Stage 02
Discovery
Existing systems, data, users and constraints are examined. The output is a shared written understanding, not a slide deck.
Stage 03
Shaping
Scope, sequence and technical direction are agreed. Risks and unknowns are named explicitly so they can be scheduled.
Stage 04
Implementation
Development runs in short cycles with running software at the end of each one, deployed where the client can use it.
Stage 05
Verification
Automated tests, manual review and, where relevant, load or security checks run before a release is considered done.
Stage 06
Handover and care
Documentation, access and operational routines are transferred. Ongoing maintenance continues only if it is wanted.
Security, privacy and quality
Protection is part of the build, not a later phase
Access control, input validation, secret management and dependency updates are handled as ordinary engineering tasks with the same review as any other change.
Personal data is treated as a liability to be minimised. We collect what a feature genuinely requires, keep it for as long as it is needed, and make deletion possible by design rather than by request.
Quality is measured by what a system does under pressure: on poor connections, with unexpected input, and when a dependency is unavailable. Those cases are written into the test suite instead of discovered in production.
- Least-privilege access by default
- Reviewed dependency updates
- Secrets kept outside source control
- Encrypted transport for all traffic
- Auditable deployment history
- Backups verified by restore
Business contexts the team can support
The technical problems below recur across sectors. Domain knowledge is built during discovery with the people who do the work.
Professional services
Scheduling, project tracking, document handling and client-facing portals where accuracy of records matters more than volume.
Retail and commerce
Catalogue management, order flows, stock synchronisation and integrations between storefronts and back-office systems.
Logistics and operations
Dispatch tools, status tracking, device-friendly interfaces for field use and reliable synchronisation over unstable networks.
Manufacturing and industry
Production data capture, reporting layers over machine data and interfaces designed for shop-floor conditions.
Education and training
Course delivery platforms, progress tracking and content administration with clear roles and permissions.
Health and wellbeing services
Administrative and scheduling software built with strict data minimisation and access control.
Financial operations
Reconciliation tooling, reporting pipelines and integrations with accounting or payment providers, with auditability as a requirement.
Media and publishing
Editorial workflows, structured content models and delivery interfaces that stay fast as archives grow.
Public and non-profit organisations
Accessible services, transparent data handling and systems that remain maintainable on modest budgets.
Working with Fer Eman
What you can expect from the engagement
Direct contact with the people building the software
Questions are answered by the engineers doing the work, without a layer of account management in between.
Written reasoning behind technical decisions
Architecture choices, trade-offs and rejected options are recorded so future changes start from context instead of guesswork.
Code and infrastructure you own
Repositories, environments and documentation belong to the client from the beginning of the engagement.
Scope described in plain language
Estimates state assumptions and unknowns. When something turns out larger than expected, that is raised early rather than absorbed silently.
Software prepared for handover
Every project is built as if another team will maintain it, because eventually someone will.
Fig. 02 — Interface work is reviewed with real data, not placeholder content.
Fig. 03 — Application work and the infrastructure under it are planned together.
Frequently asked questions
- What kind of work does Fer Eman take on?
- Software that a business depends on: web applications, internal tools, integrations between existing systems, cloud infrastructure work, and the maintenance that follows a release. Engagements can start at the idea stage or continue work that already exists.
- How does an engagement usually start?
- With a written description of the problem sent by email. From there the discussion covers the current situation, constraints, existing systems, and what a first useful result would look like. Scope is agreed before implementation begins.
- Can Fer Eman work with an existing codebase?
- Yes. Work on existing systems begins with reading the code, mapping dependencies and understanding how the software is deployed. Changes are then introduced in small steps so behaviour can be verified as it evolves.
- How is progress shared during a project?
- Through working software and short written updates. Increments are deployed to an environment the client can open, so feedback is based on the real product rather than on descriptions of it.
- What happens after a release?
- Maintenance covers dependency updates, monitoring, defect fixes and incremental improvements. The scope and rhythm of that work is agreed per engagement rather than assumed.
- How can the company be reached?
- By email at [email protected]. Written enquiries that describe the system, the constraints and the desired outcome receive the most useful reply.
Company and contact information
Send a written description of the problem
Useful enquiries describe the system involved, the constraints around it and the result you are aiming for. Replies are sent from the same address.