System architecture
For teams planning something that has to scale
A written architecture before anyone writes code: services, data, hosting, cost, failure modes and growth, from someone who can also build it.
The problem
The expensive mistakes in a system are made early, before anyone can tell they’re mistakes: a database that suits the demo but not the data, services split along the wrong lines, hosting that’s cheap at a hundred users and alarming at a hundred thousand, and nothing in place to show what broke at 2am. By the time they surface they’re built into everything, and fixing them means rebuilding with the product still running.
An architecture consultation puts that thinking first. Before code is written, you get a written design for the system: the services and their boundaries, the data model and where it lives, hosting and what it will cost, observability, how it fails, and how it grows. It comes from someone who builds these systems, including Sunday’s rebuilt backend, so it’s a design that can actually be built.
What the architecture covers
Services & boundaries
What runs where, what talks to what, and where the lines between services fall, so each part can change without dragging the rest along.
Data model & storage
The shape of the data and the right store for each part of it, chosen for how it’s read and written, not for what’s fashionable.
Hosting & cost
Where it runs and what it costs, at today’s load and at the load you’re planning for, so the bill isn’t the surprise.
Observability
Logs, metrics and traces designed in from the start, so when something goes wrong you can see what and where.
Failure modes
What happens when a service, a database or a third party goes down, and how the system degrades instead of falling over.
How it grows
Which parts strain first, what changes at ten times the load, and what can safely wait until you get there.
How it works
Scope
We agree what the system has to do, the constraints it lives under, and what the written architecture will cover, in writing.
Explore
Conversations with the people who know the product, a look at any existing code and infrastructure, and the options weighed on paper.
Design
The architecture written up: diagrams, decisions, and the trade-offs behind each one, reviewed with you before it’s final.
Hand over
The document is yours, with a walkthrough for whoever builds it, whether that’s us or your team.
Related work
Working with Neelesh is like working with a whole team of developers. He can project manage, design, debug and execute across the full development stack. He's an absolute pleasure to work with.
Nat Martin
Common questions
What do we get at the end?
A written architecture: diagrams of the system, the decision behind each part, the options we ruled out and why, a hosting and cost picture, and what to build first. It’s written for the people who will build it, whether that’s us or your own team.
Can you look at a system we already have?
Yes. If something is already creaking (slow under load, costly to run, or hard to change) we start from what’s there: the code, the infrastructure, and where it hurts. You get the same kind of document: what to change, in what order, and what each change buys you.
Will you build it, or just design it?
Either. The person who designs it can build it, which keeps the design honest: nothing goes on paper that we wouldn’t want to build ourselves. If you have your own team, we hand it to them and walk them through it.
What does a consultation cost?
It’s quoted from the written scope before we start, based on the size of the system and how much of it the architecture needs to cover.
Have something to build?
Tell us what you're working on. We'll tell you how we'd approach it.
We reply within one working day.