01
Write it down
Decisions that only exist in conversation are lost. Scope, assumptions and trade-offs are recorded where anyone involved can read them.
An IT company
organised around
long-lived systems
GEMS CREATION ARTS builds and maintains software for organisations that depend on it daily. This page describes how we work, what we hold ourselves to, and what a working relationship with us looks like in practice.
01Overview
What the company does
We are a software engineering practice. Our work covers custom applications, web platforms, process automation, integrations between existing systems, and the ongoing maintenance those systems require once they are in daily use. Engagements range from a focused technical review through to designing and delivering a complete application.
We do not position ourselves as a supplier of a single product or a single methodology. The right answer depends on the constraints — the data, the people who will use the system, the platforms already in place and the time available. Understanding those constraints is the first part of every engagement.
02Purpose and approach
Software should reduce effort, not relocate it
A system that removes a manual step but introduces two new ones has not helped anyone. Our purpose is to leave an organisation demonstrably better off: fewer repeated tasks, fewer places where information can go wrong, and clearer visibility of what is actually happening.
That requires paying attention to the work as it is performed today, including the informal steps that never appear in a process document. Those details are usually where the real requirements are hiding.
03Working principles
Four rules we apply without exception
02
Prefer the simple version
The smallest design that satisfies the requirement is the one that survives. Complexity is added only when a real constraint demands it.
03
Make failure visible
Systems fail. Ones that fail loudly, with useful logs and clear errors, are repaired in minutes rather than days.
04
Leave it operable
Work is finished when someone else can run, deploy and modify it without needing us in the room.
04Engineering mindset
Treating software as an object that must be maintained
Code is read far more often than it is written. We optimise for the person who opens the file eighteen months from now — clear naming, obvious control flow, boundaries that match the domain, and comments reserved for explaining why rather than what.
We are cautious about dependencies. Every library added is a long-term commitment to someone else's maintenance schedule, so each one has to earn its place.
Measurement precedes optimisation. Performance problems are diagnosed with real numbers, not intuition, and fixed where the evidence points.
05 — Collaboration philosophy
Fewer status reports, more visible progress
We prefer to show working software rather than describe it. Regular, short demonstrations replace long written updates, and questions are raised as soon as they appear rather than saved for a scheduled meeting.
Disagreement is treated as useful information. If a requested approach looks likely to cause problems later, we say so, explain the reasoning, and set out the alternatives — then implement the decision that is made.
06Quality standards
What "done" means here
A feature is not complete when it works on one machine. It is complete when it has been reviewed, tested, verified against the requirement and is deployable by a repeatable procedure.
- Review
- Every change is read by someone other than its author before it is merged.
- Testing
- Automated tests cover the behaviour that matters most, particularly business rules and data transformations.
- Static analysis
- Type checking and linting catch a large class of defects before code is ever executed.
- Verification
- Features are checked against the written requirement, on real devices and realistic data volumes.
07Responsible technology
Handling data and access with care
Collect less
Systems should store the data they genuinely need. Reducing what is collected reduces both risk and the obligations that come with it.
Restrict access
Permissions are granted at the narrowest useful scope, credentials are kept out of source control, and access is reviewed when roles change.
Build for accessibility
Semantic structure, keyboard operability and readable contrast are part of the implementation, not a remediation project after launch.
08Long-term value
The second year matters more than the first
Any competent team can deliver a first version. The difference appears later: when a regulation changes, a supplier's interface is replaced, usage doubles, or a new person has to take over the codebase. Systems built without regard for that moment become expensive to keep alive.
We aim to leave behind software that can be handed to another team without apology — documented, tested, consistent in structure, and free of hidden dependencies on the people who wrote it. That independence is deliberate, and it is part of what we consider a successful engagement.
09Contact
Questions about how we work
If anything here raises a question about scope, process or suitability for your situation, write to us. See the Contacts page for what to include.
anthonydean199359@gmail.com