Software Engineering
Software built around your business. Not the other way around.
Most software does not fail on the day it ships. It fails eighteen months later, when the person who wrote it has gone, nobody is sure what the code does, and a small change takes three weeks. We build applications that survive that stage.
For teams carrying systems that are hard to change, integrations that keep breaking, or an idea that needs to be built properly the first time.
Discuss a software engineering projectChallenges we solve
The system works, but nobody wants to touch it
Changes take longer than they should, estimates are padded with fear, and the people who understand the risky parts have left. The code is not necessarily bad — it is undocumented, untested and entangled, so every change is a gamble.
Two systems that should talk, don't
Data is re-keyed by hand between tools, exports are emailed around, and a spreadsheet has quietly become part of the process. The integration was never built because it was never quite anyone's job.
The prototype became production
Something built quickly to prove a point is now carrying real users and real data. It was never designed for that, and the decisions that made it fast to build are now the ones making it fragile.
Rebuild or repair?
A rewrite is proposed roughly once a year and never happens, because nobody can say with confidence what it would cost or what would be lost. The question needs an honest technical answer, not an opinion.
What we do
Custom web applications
Applications built for how your business actually works, rather than configured around a product that nearly fits. We favour straightforward, well-understood technology that another team could pick up.
Backend services and APIs
Services with explicit contracts, sensible error handling and behaviour that stays correct when a request is retried. An API is a promise to other systems, so we design it as one.
System integration
Connecting the tools you already run, including the ones with awkward or undocumented interfaces, with attention to what happens when the other side is slow, down or has changed without warning.
Internal business tools
The unglamorous software that quietly runs operations. Built properly, these remove manual work permanently rather than moving it somewhere else.
Software architecture
Boundaries drawn around business capabilities, decisions written down with their trade-offs, and a shape the team can hold in their heads.
Application modernisation
Improving a system in place, in reviewable steps, with tests added around behaviour before it is changed — rather than a rewrite that stops all other work for a year.
Technical discovery and prototyping
When the right answer is not yet obvious, a short, time-boxed investigation that produces evidence instead of a longer meeting.
Architecture Explorer
An illustrative architecture for a typical business application. Select any part to see what it is responsible for and the engineering questions that come with it. This is a teaching example, not a diagram of any client's system.
Illustrative architecture — not a client system.
Selected component highlighted; everything it talks to is outlined.
Client application
What the user actually touches — a web app, an internal tool, or both.
Engineering considerations
- Keeping state predictable as screens multiply
- Accessibility and keyboard support as first-class, not retrofitted
- Behaving sensibly when the network is slow or absent
Typical deliverables
Illustrative of what an engagement can produce. Not a record of completed client work.
- A working, deployed application
- Architecture decisions recorded with their trade-offs
- API documentation that matches the implementation
- An automated test suite covering the important paths
- A build and deployment pipeline your team can run
- Handover documentation and a walkthrough with your engineers
Our approach
- AssessWe read the existing code, talk to the people who maintain it, and establish what is actually true today rather than what the documentation claims.
- PlanWe agree the smallest first piece that produces something real, and name the risks we expect to hit. Plans that survive contact with reality are short.
- ImplementWork arrives in reviewable increments. You see progress continuously, not at the end.
- VerifyTests are written alongside the code, and we are explicit about what is covered and what is not.
- Hand overDocumentation, a walkthrough and whatever your team needs to own it. We aim to be easy to stop working with.
This sits inside our wider Design, Build, Verify, Improve cycle.
Engagement options
Technical assessment
Short, fixed scope
We review an existing system or plan and report on risks, effort and options. Useful before committing to a rebuild or a large piece of work.
Defined-scope project
Agreed outcome and timeline
A specific thing built and delivered — an application, an integration, a modernisation step — with the scope written down before we start.
Ongoing engineering support
Continuing, reviewed regularly
Continuous work alongside your team, for products that need steady development and maintenance rather than a one-off push.
Ethora Labs is a small, senior team. We take on work we can do well, and we say so when something falls outside that. We do not run offshore delivery centres or bench teams.
Talk to us about software engineering
Tell us what you are working on. We will tell you honestly whether we are the right people for it.