Domain model you can argue about
Written in your language, not ours. If the finance team cannot read the model, the model is wrong.
Service 03
Backend and APIs that hold under load
Domain modelling, event architecture, contract-tested APIs, and the unglamorous migration off the system you cannot turn off.
Softrear designs and builds the backend: domain models, contract-tested APIs, event-driven workflows and the incremental migration path off legacy systems that cannot be switched off. This is the hardest part of an end-to-end build and the part most agencies under-invest in.
Who this is for
- Your monolith cannot take month-end load and everyone knows it.
- Every integration is bespoke, undocumented, and owned by one person.
- You have been quoted a two-year rewrite and the deadline is in five months.
What you get
Deliverables, not adjectives.
Contract-tested APIs
OpenAPI as the source of truth, consumer-driven contract tests in CI, so a breaking change fails a build instead of a customer.
Event architecture where it earns its place
Events for genuine decoupling and audit; direct calls where events would only add latency and mystery. We do not distribute a system for the pleasure of it.
Strangler migration
Small reversible cutovers behind the gateway, old and new running side by side, each cutover rollback-tested before it goes near production.
Load and failure testing
Your real peak, modelled and run, plus deliberate failure injection on the paths that would cost you money.
How it runs
- Model the domain and the load profile before choosing anything
- Gateway in front of the legacy system, so the seam is ours to move
- Extract one bounded context at a time, each with a rollback
- Retire the legacy path only when the new one has carried real peak traffic
Tools & standards
We choose per project and write down why. A stack chosen because it is what the last team knew is a stack nobody can defend at review.
Questions we get asked
Do we have to move to microservices?
No, and usually you should not. Most systems that struggle are not struggling because they are a monolith — they are struggling because of one hot table or one synchronous call. We measure first and extract only what the measurement justifies.
Can you work in our existing codebase?
Yes. Most of our backend work is in code somebody else wrote. We start by making the build reproducible and the tests trustworthy, because you cannot safely change what you cannot verify.
The rest of the stack
01
Product design
Research, flows, a design system your engineers can actually build against — not a Figma file that dies at handover.
02Mobile
Flutter, React Native and native iOS/Android — shipped through the stores, instrumented, and supported after release.
04Web frontend
Marketing sites, dashboards and customer portals built for Core Web Vitals, accessibility and the person maintaining it next year.
05Cloud & DevOps
Infrastructure as code, SLOs that mean something, a real on-call rotation, and a quarterly review of what it all costs.
06Managed support
SLA-backed support for systems we built and systems we inherited, with the metrics published to you monthly.
Tell us what’s stuck.
A senior engineer reads every one of these. If we’re not the right fit we’ll say so, and point you at someone who is.
Start the conversation
No spam, no drip sequence. A senior engineer replies within one business day.