Fixed scope
Backend platform build
A greenfield product build to a defined scope: domain model, API, interface, deployment pipeline and the seams that let it be extended without unpicking.
Services / Backend, Web & Distributed Systems
Backends that scale past the first version without a rewrite.
Distributed patterns that survive growth, without the premature architecture that sinks a product first.
- Typical first engagement
- 8–16 weeks, fixed scope
- Starts with
- Domain model and the constraints that actually bind
- Ends with
- Deployed system, tests, CI and architecture records
The problem
What this practice is actually for.
Two ways to lose here: a monolith with no seams that hits a wall at scale, or twelve microservices for a product with four hundred users.
We size the architecture to the next eighteen months. Clear domain boundaries so it can be split when that is justified, and boring, well-tested code everywhere else.
- Domain boundaries defined before the service boundaries
- Contract tests between services, so independent deploys stay safe
- Migrations, tests and CI from the first commit rather than the last sprint
- Performance work driven by profiling rather than by intuition
In the work
What Backend & Web code looks like when we write it.
Running
0.0s
pipeline
main
● live run
Bulk-safe services, typed contracts, tested at load.
Spring Boot where transactional integrity matters, Node and Go where iteration speed does. Contract tests underneath, so one team can deploy without asking four others.
Capabilities
Backend, Web & Distributed Systems — the full stack.
10 capability groups
- Java & JVM
- Spring Boot, Spring Cloud, Spring Security, Hibernate/JPA, Maven and Gradle, JUnit and Testcontainers, Kotlin on the JVM
- Node & TypeScript
- Node.js, Nest.js, Express, Fastify, Prisma and TypeORM, end-to-end typed APIs
- Frontend
- React, Next.js, Vue.js, TypeScript, design-system implementation, SSR and edge rendering
- Additional stacks
- Go (Gin, Fiber), Python (FastAPI, Django), .NET Core, Rust (Axum) — for teams standardised outside our primary toolset
- Distributed design
- Microservices, event-driven architecture, Kafka, RabbitMQ, SQS, API gateway design, service-to-service authentication
- API paradigms
- REST, GraphQL (Apollo), gRPC, WebSockets, Server-Sent Events
- Architecture patterns
- Event sourcing and CQRS, saga pattern for distributed transactions, domain-driven design
- Data layer
- Advanced PostgreSQL indexing, partitioning and replication, MongoDB, multi-tenant data architecture, Redis caching strategy
- Auth
- OAuth2 / OIDC, JWT, RBAC and ABAC authorisation models
- Quality
- Contract testing with Pact, load testing with k6 and JMeter, observability-driven performance tuning
Typical engagements
How this work usually starts.
Indicative scope and duration
Fixed scope
Monolith decomposition
Strangler-fig extraction of the parts that actually need independence, with contract tests and a cutover sequence that keeps the old path available.
Advisory
Performance and scale review
Profiling, load testing and query analysis against a target volume, with a ranked list of what to fix and what the fix is worth.
What you get
Deliverables, every time.
01
Working system
Deployed, monitored, documented, with the infrastructure defined as code alongside the application.
02
Test suite
Unit, integration and contract tests running in CI, at a level of coverage your team can maintain rather than abandon.
03
Architecture decision records
Why the boundaries are where they are, what was rejected, and the conditions that should trigger a rethink.
04
Load-test baseline
Reproducible k6 or JMeter scenarios plus measured headroom at your projected volume.
Questions
What clients ask before they commit.
Start with a well-structured monolith and clear internal boundaries unless you have multiple teams needing independent deploys today, or a component with a genuinely different scaling profile. Splitting later is straightforward when the boundaries were drawn properly. Merging back after a premature split is not.
Yes, and we will be direct about its condition. The first two weeks are assessment: what works, what is load-bearing, what is undocumented, and what should be replaced rather than repaired. You get that written down before we commit to a delivery scope.
That is the design constraint. We work in mainstream stacks, in your repository, to your review standards, and we avoid clever solutions where an obvious one will do. Every engagement ends with a walkthrough and written architecture records aimed at the engineers who will own it next.
Also from Windsor Harlow
Other practices
→
AI, ML & MLOps
Most AI pilots die in month two. We build the parts that decide whether yours survives.…
→ →Salesforce Development
Governor-safe Apex, tested triggers, automation a new admin can read.…
→ →Cloud, DevOps & Infrastructure
Cost and operability designed in as requirements, not cleaned up after the invoice arrives.…
→Have a Backend & Web problem worth a senior pair of eyes?
Tell us the system, the constraint, and what happens if it is not solved. A senior engineer replies within one business day.