Skip to content

Topic · 9 articles

Build & architect

Once the decision is made, the next set of choices determines whether the thing can be maintained by the people who inherit it. Architecture is not a diagram. It is the set of decisions that are expensive to change later: where state lives, how services talk, what owns the truth, how a release reaches production, and who is on call when it breaks.

These articles cover the build side of the work — the software development life cycle, agile and waterfall in practice, monolith versus microservices, how cost actually accumulates, how modernisation is sequenced, and how a team should be shaped so decisions do not queue behind one person.

We write about the boring parts because they are the parts that decide the outcome. A modular monolith with clear boundaries beats a distributed system the team cannot operate. A two-week release cadence beats a quarterly release with a hero engineer. A cost model that separates build from run beats a single number that hides the second year.

You will not find a universal stack recommendation here. The right answer depends on your constraints, your team and the life expectancy of the product. What you will find is how to reason about the trade-off and what evidence to demand before you commit.

If you are modernising an existing system, read the rewrite-versus-refactor comparison before you approve a rebuild. If you are starting from nothing, start with the custom software development guide and the SDLC overview.

All articles in this topic

Need help with a decision in this area?

Tell us what you are weighing up. We will share how we frame the trade-offs and what evidence we would need.

Email is the best way to reach us.