About us
An engineering
company, first
BASIC SHIRTS MN LIMITED designs, builds and maintains software systems. Our work covers custom application development, cloud infrastructure, integration between existing systems, and the technical planning that keeps those systems maintainable over time.
Overview
What the company does
We work with organisations that depend on software to operate, and that need engineering judgement rather than a catalogue of features.
Engagements usually begin with an existing situation: an application that has outgrown its original design, a manual process that should be automated, systems that hold the same data in incompatible shapes, or infrastructure that has become expensive and difficult to reason about.
From there we define the smallest technical change that produces a meaningful result, implement it carefully, and then extend the work in deliberate increments. We prefer systems that are boring to operate: documented, observable, and predictable under load.
The company works across custom software development, web application development, cloud solutions, systems integration, IT consulting, and long-term maintenance and technical support.
Mission
Software that stays useful
Our mission is to build systems that continue to serve their purpose after the first release — systems a team can understand, change and operate without fear.
Software rarely fails because a feature is missing. It fails because nobody can safely change it, because its behaviour under real conditions was never measured, or because knowledge about it lived in one person's head.
We treat clarity as a deliverable. Architecture decisions are written down with their trade-offs. Interfaces are explicit. Operational behaviour — logging, metrics, failure modes, recovery steps — is designed alongside the functionality it supports.
That focus is what allows a system to be handed over, extended by another team, or maintained years after it was first delivered.
Working principles
How we hold ourselves to account
01
Understand before building
Requirements are validated against how work actually happens, not only against how it is described in a document.
02
Small, reversible steps
Changes are shipped in increments that can be verified independently and rolled back without drama.
03
Explicit over implicit
Contracts, data shapes, error handling and configuration are stated openly rather than inferred from behaviour.
04
Automate the repeatable
Builds, tests, deployments and environment provisioning are scripted so that outcomes do not depend on who runs them.
05
Measure, then optimise
Performance and cost work starts from observed data, so that effort is spent where it changes the outcome.
06
Leave systems handover-ready
Documentation, runbooks and access arrangements are maintained as part of delivery, not written retroactively.
Problem-solving
Our approach to technical problems
We separate the symptom from the cause before proposing a change, and we resist the urge to rebuild what can be repaired.
- Reproduce the problem in a controlled environment and describe it in measurable terms before any code is written.
- Map the system boundaries involved — data stores, services, jobs, third-party dependencies — and identify which of them can be changed.
- Compare options honestly, including the option of doing less, and record why the chosen path was selected.
- Verify the fix against the original measurement, then add the check that would catch a regression automatically.
Collaboration
Working alongside your team
We aim to be a straightforward technical counterpart: clear about progress, direct about risk, and easy to plan around.
Every engagement has an agreed written channel, a shared backlog, and a regular rhythm of updates that state what changed, what is next, and what is blocked. Decisions that affect scope, cost or architecture are raised in writing when they arise rather than at the end of a phase.
Where an internal team is involved, we work in their repository conventions and review process, and we document what we build so knowledge is not concentrated on our side of the engagement.
Quality practices
What quality means in practice
Quality is the sum of small habits applied consistently, not a phase at the end of a project.
Q1
Code review as standard
Every change is reviewed by another engineer, with attention to readability, error handling and the tests that accompany it.
Q2
Layered automated testing
Unit tests for logic, integration tests across boundaries, and end-to-end checks for the paths users depend on most.
Q3
Continuous integration
Builds, linting, type checks and test suites run automatically on each change, so defects surface early.
Q4
Security-minded engineering
Least-privilege access, validated inputs, managed secrets, dependency review and encrypted transport are treated as baseline requirements.
Q5
Observability by design
Structured logs, metrics and alerts are added with the feature, so production behaviour can be understood without guesswork.
Q6
Documented operations
Deployment steps, configuration, dependencies and recovery procedures are written down and kept current.