Custom software engineering
Product surfaces, internal tools, back-office systems and integration layers written from scratch or continued from a previous vendor.
Est. Practice
Index / 01
Considered technology
engineered with restraint,
delivered without drama.
SEC AUDIOLOGY LIMITED is an independent technology practice. We design, build and operate software, data systems and cloud infrastructure for organisations that need work done properly — once, with a small team, and with the discipline to hand it back in working order.
§ 02
Practice
A quiet studio for serious systems.
Our work sits at the boundary between product engineering and operational technology. We are usually invited in when a system has outgrown its original shape — when the team that built it has moved on, when the load has changed, or when the organisation around it has changed faster than the code.
We prefer engagements where the outcome matters more than the schedule of demos: replacing a fragile pipeline, rewriting a legacy interface, standing up a private cloud environment, bringing a first version of a product to a state where it can be trusted with real customers.
§ 03
Principles
Technology principles we work by.
- 24
Simplicity is a feature.
Fewer moving parts. Fewer services than the diagram wants. Fewer clever abstractions than seem justified at first.
- 27
Reversible decisions first.
We prefer choices that can be undone cheaply, and we resist committing to expensive ones before we have to.
- 25
Observability by default.
Systems we ship report on themselves. Logs, metrics and traces are part of the delivery, not something added afterwards.
- 24
Boring where it matters.
Databases, queues and language runtimes are chosen for durability and staffability rather than novelty.
- 30
Ownership handed back cleanly.
Documentation, runbooks and access transfer are treated as project deliverables, not favours.
§ 04
Service areas
Where our work concentrates.
Cloud & infrastructure
Environment design, migration work, cost consolidation and platform engineering across the major public clouds and self-hosted estates.
Data engineering & analytics
Pipelines, warehouses, event streams and the reporting layer that sits above them.
Cybersecurity practice
Threat modelling, access review, secrets hygiene, dependency posture and incident preparation.
System integration & APIs
Bringing separately built systems into a coherent whole through well-defined interfaces.
Application modernisation
Rewriting or extracting portions of long-lived applications so the parts that still earn their keep can continue to do so.
§ 06
Problems we take on
Business problems worth engineering for.
Systems that no longer match how the business actually operates.
A tool built around a workflow that has since changed twice.
Costs that grew without anyone deciding they should.
Cloud bills, licence sprawl, duplicated services, environments nobody remembers standing up.
Data that exists but cannot be answered from.
The report is a person, and the person is overloaded.
Security posture that has drifted since the last audit.
Credentials in code, unpatched images, permission grants nobody has reviewed in eighteen months.
A product that works for early users but not for scale.
The next order of magnitude will break something predictable — pick which and rebuild it.
§ 07
Software approach
How we build software.
We work in short, honest iterations. A written specification precedes serious code; the first version is deployable; and the production environment exists on day one, not week ten. We keep the number of concurrent branches small, and we prefer merging early over integrating late.
Languages
TypeScript, Python, Go, Rust and Java, chosen for the workload rather than the fashion of the quarter.
Runtimes
Containers on Kubernetes or managed platforms; serverless where the workload genuinely fits.
Interfaces
HTTP APIs, event streams and gRPC, documented from the same source that generates the client.
§ 08
Cloud & infrastructure.
We design environments to be understood, not just to work. That usually means fewer accounts than the reference architecture suggests, network topologies that can be drawn on a single page, and identity models that can be reviewed without an expert present.
- Platforms
- AWS, GCP, Azure, on-premises.
- Provisioning
- Terraform, Pulumi, Ansible.
- Delivery
- GitHub Actions, GitLab CI, Argo.
- Observability
- OpenTelemetry, Prometheus, Grafana.
§ 09
Cybersecurity as a discipline.
Security work is not a report; it is a set of habits inside the engineering process. We review dependencies before they enter production, treat secrets as first-class infrastructure, and draft incident procedures before they are needed rather than afterwards.
- — Threat modelling at the architectural level.
- — Access, identity and least-privilege review.
- — Supply-chain and dependency posture.
- — Logging and detection engineering.
- — Written incident response procedures and drills.
§ 10
Data & analytics
Data that answers questions.
Pipelines
Batch and streaming pipelines built with tools that operations teams can reason about — Airflow, dbt, Kafka, Flink — with documented lineage from source to dashboard.
Warehouses
BigQuery, Snowflake, Redshift and Postgres, sized to the workload rather than the largest option on the menu.
Modelling
Business logic captured in versioned, tested SQL so that a chart can be traced back to the definition it depends on.
Reporting
Dashboards and internal reports designed with the person who will actually read them, not the person who requested them.
§ 11
Transformation
Digital transformation, without the theatre.
Transformation programmes usually fail at the join between the technology and the people who have to use it. We spend the early weeks understanding the current shape of work, and the later weeks removing the parts of the new system that would have made it feel like a downgrade.
Phase
Current-state mapping
Phase
Sequenced migration plans
Phase
Change readiness
§ 12
Industries
Sectors where our work has been useful.
- —Healthcare technology and patient-facing services
- —Financial services and payments infrastructure
- —Public sector and civic technology
- —Logistics, mobility and supply-chain systems
- —Media, publishing and subscription products
- —Industrial and manufacturing operations
- —Education technology and research platforms
- —Energy, utilities and metering
§ 13
Delivery
How an engagement runs.
01
Framing
We begin with a written brief describing the outcome, the constraints, and the definition of done. No work starts until this is agreed.
02
Discovery
A short structured period spent reading the existing code, watching the current process, and speaking with the people who rely on it.
03
Prototype
A minimum end-to-end version, running in a real environment, used to expose the assumptions that need to be corrected.
04
Build
Iterative delivery with regular releases. Scope is renegotiated openly when reality changes.
05
Handover
Documentation, runbooks, credentials and knowledge transfer sessions treated as project deliverables.
06
Aftercare
An agreed period during which we remain available to the team that will operate what we built.
§ 14
Quality
Quality is a process, not a stage.
Testing is written alongside the code it protects. Continuous integration is treated as a system that has to remain green. Code review is a conversation about the design, not a rubber stamp on the diff.
Unit
Fast, deterministic, close to the code.
Integration
Real dependencies, real data shapes.
End-to-end
The critical journeys, kept few and kept passing.
Non-functional
Performance, load, and failure-mode tests where they matter.
§ 15
Collaboration
A small team, close to yours.
We favour engagements where a compact team of senior engineers works directly with the people who own the problem. There is no account layer between the client and the person writing the code. Meetings are short, scheduled, and end with written decisions.
§ 16
Questions
Questions we are often asked.
- What size of engagement is typical?
- Most of our work runs between a handful of weeks and several months. We rarely take on assignments where the outcome cannot be described in a paragraph.
- Do you work alongside an existing engineering team?
- Yes. A great deal of our work is done in partnership with in-house engineers, which is also the arrangement most likely to produce something the client can maintain afterwards.
- Do you sign non-disclosure and data-processing agreements?
- Standard practice. We prefer to review these early so that discovery work can begin without administrative friction.
- How do you price work?
- By written scope, on a time-and-materials or fixed-outcome basis, agreed before work begins. Details are handled in direct correspondence.
- Where are you based?
- We operate remotely by default, and travel on-site when the problem benefits from it.
§ 17
Correspondence
Reach the practice directly.
Enquiries about engagements, non-disclosure agreements, and scoping conversations are handled by email. We aim to reply within two working days.
- Email —
- dianeperry197759@gmail.com
- Website —
- secaudiology.com
- Entity —
- SEC AUDIOLOGY LIMITED