About us

A software company built around clarity, not volume

TABLE OF THE ELEMENTS LTD provides software engineering and technology services to organisations that rely on custom systems. We work on new applications, long-running internal tools and integrations between platforms that were never designed to talk to each other.

The material on this page describes how we intend to work. It is draft content prepared for company review and makes no claim of certification, partnership or guaranteed outcome.

Company overview

What we do and who we work with

Our engagements typically fall into three shapes: building a new application around a defined operational process, taking over an existing system that has outgrown its original design, or connecting separate tools so data stops being copied by hand.

Whichever shape a project takes, the first deliverable is written understanding: what exists today, what must change, and what will be considered done. Everything after that — estimates, iterations, testing, hand-over — refers back to that document.

Application source code on a monitor in a quiet development workspace

Mission and principles

The commitments that shape our work

Mission

To deliver software that the people who own it can understand, operate and change — long after the original engagement has ended.

Accuracy over optimism

We describe risks, unknowns and estimate ranges plainly. A comfortable forecast that fails is more expensive than an uncomfortable one that holds.

Small, reviewable steps

Work is delivered in increments that can be inspected in a running environment, so direction can be corrected while correction is still cheap.

No hidden dependencies

Environments, credentials and deployment steps are documented and handed over. Nothing essential should live only in one person's head.

Approach

How we solve technology problems

Most difficult software problems turn out to be description problems first. Our sequence is deliberately slow at the start and fast afterwards.

  1. 1. Establish the current state

    We read the code, run the system, review the data and speak with the people who use it daily. The output is a plain-language description of behaviour, including the parts nobody documented.

  2. 2. Separate symptoms from causes

    A slow report and a duplicated record often share one underlying cause. We group observed problems by cause before deciding what to build, so fixes are not applied to the surface alone.

  3. 3. Choose the smallest sufficient change

    Rewrites are a last resort. Where a targeted change, an added test or a data correction resolves the issue, we prefer it and say so, even when a larger project would be commercially attractive.

  4. 4. Verify against the original description

    Completion is measured against the acceptance criteria written at the start, not against the impression that the work feels finished.

Colleagues discussing system diagrams drawn on a whiteboard during a planning session

Project collaboration

Working alongside internal teams

We are usually one part of a wider group that includes internal developers, operations staff and subject-matter experts. Our practices are designed to fit into that arrangement rather than replace it.

  • A single shared backlog, so priorities are visible to everyone rather than negotiated privately.
  • Code review in both directions, with internal engineers reviewing our work and vice versa where that is welcome.
  • Scheduled demonstrations at the end of each iteration, open to anyone who depends on the system.
  • Decision records kept in the repository, so the reasoning behind a choice is available to whoever revisits it later.

Commitment

Maintainable software and clear communication

Maintainability is a property of a system that has been documented, tested and simplified on purpose. It does not appear on its own, and it is the first thing sacrificed when a project is rushed.

Readable code

Consistent structure, meaningful names and comments reserved for the reasons behind non-obvious decisions.

Living documentation

Setup guides, runbooks and architecture notes updated with the change that made them out of date.

Direct communication

Plain language in status updates, with problems named as problems. Enquiries reach us by email at tamikafields198@gmail.com.