Fewer people than you expect

The team

Small teams that go deep, and a smaller bill

Everyone who works on your system knows it well enough to have opinions about it, and there is no layer of people whose job is to relay information between the people who decide and the people who type. You pay for the people building your system, and very little else.

That is the argument, and it is arithmetic rather than philosophy. A team of four has six communication paths. A team of twenty has a hundred and ninety. Most of what a large team produces is the coordination required to be a large team, and you pay for all of it.

You pay for four engineers, not for the coordination of twenty.

How four people carry forty repositories

Not long hours. The same method on every engagement, most of it decided before the first line of code is written.

Each of these is taken further down this page, and in the engineering notes.

Engagement

Three shapes, and which one you need

Most engagements start as one and become another. The lending platform above was shape one; several of our longest relationships are now shape two on systems we originally built.

Domain

We already know your industry

On a normal engagement the first month is the supplier learning your industry, and you pay for it twice — once in fees, and once in your own people’s time spent explaining things they already know. It is the least visible cost in a software contract and often one of the largest.

In the areas we work in, that month is mostly already spent. Domain knowledge is not vocabulary; it is the thing that decides the design. Four examples, each of which changed an architecture rather than just a glossary:

Outside those areas we are learning your domain at the same rate as anyone else. We would rather say so in the first conversation than have you find out in month three.

Scope

We only build what you can’t buy

The reason four people could build that platform is not that they worked unusual hours. It is that most of the system was deliberately not built.

Identity verification, bank statement aggregation, credit bureau access, mandate execution and disbursal were all integrated rather than written. They are commodity, regulated, or both — building them would have consumed the team without differentiating the product. What stayed in-house was the part that was genuinely the client’s: the credit decision, the scoring engine, and the orchestration holding it together.

We apply the same test on every engagement, and it is usually the most valuable conversation of the first month. What here is actually yours? Everything else should be bought if it can be, and the discipline to accept that is what keeps teams small.

Integration

The hard part is usually the other system

Deciding to buy rather than build moves the work rather than removing it. On the lending platform, five stages were ours and six services were somebody else’s — government identity, the credit bureau, fraud screening, the employment and tax registry, bank statements through an aggregator, and the partner who actually moved the money. The ratio is why the team was four people, and the integrations are where most of the difficulty went.

The interesting ones are those where the other side is outside your control: a national scheme, a regulator, a partner whose test environment is available by appointment. You cannot make them faster, you cannot make them available, and you frequently cannot test against them at all. The test suite you control is the easy half.

Two things follow. When the counterparty cannot be tested against, we build the other side of the conversation — a simulator good enough to fail in the ways the real one does, which is described in one of the notes. And where an external certification exists, that is the quality signal worth having: the IMPS stack went through the scheme operator’s own review across nineteen distinct transaction flows, which is not something an internal test suite can tell you about itself.

The honest cost is schedule. Integration is where dates slip, because the other side’s timeline is not yours and no amount of staffing changes that. We plan for it explicitly rather than discovering it in the last fortnight.

Architecture

No big design up front

We design for what the business needs now and what it can clearly see coming, and no further. We don’t spend months on a design for every future the business might have, or build a platform before there is a product to run on it. The architecture grows as the business does.

That is not an excuse for skipping the thinking. Every substantial system we build has a written architecture describing it from several angles: what it does, how the code is organised, how it behaves at runtime, and where it deploys. Those documents state the decisions and the alternatives that were rejected, because the code will tell a future engineer what was chosen and only the document can tell them what was considered.

We publish the reasoning from some of them as engineering notes, which is the best evidence we can offer that the thinking actually happens.

Depth

Where the hundred milliseconds went

Most performance problems are not solved by adding servers, and most teams reach for servers because the alternative requires knowing exactly where the time goes. A response budget of a hundred milliseconds at volume is spent in three places — your own code, the database, the network — and each has a different answer.

In the code it is structure: microservice boundaries drawn where the domain actually divides, and the design patterns that earn their keep rather than the ones that decorate a CV. In the database it is a data model in third normal form, denormalised deliberately where slowly changing dimensions demand it, with hash and B-tree indexes chosen rather than defaulted, tables partitioned and replicated across availability zones. Command-query separation where reads and writes have genuinely different shapes — and eventual consistency accepted knowingly, as a decision with a cost, not as a fashion.

On the network it is the part most teams never reach. Edge-terminated API gateways close to users, and HTTP/3 over QUIC instead of TCP where the handshake and head-of-line blocking are what is actually costing you. None of this is exotic. It is just further down than most teams go.

Delivery

What a month looks like

Two-week sprints, a product backlog you own, a review and a release at the end of each. No mystery, no methodology we will try to sell you on.

The parts worth knowing about are the ones that differ:

• You talk to the people building it. There is no account manager between you and the engineers, because at our size there is no one spare to be one.
• Architecture is written down before it is built, and revised when it is wrong. You get the document, not just the system.
• We build what we cannot get access to. When a dependency is outside your control and on the critical path — a payment scheme, a partner’s core system — we build a simulator of it so work is never blocked on somebody else’s booking calendar.
• Security is designed, not audited in later. Encryption, key management, access control and audit trails are part of the architecture document.

Afterwards

We are still here in year seven

Our engagements are measured in years rather than months, which changes how we build. A team that will still be maintaining a system in 2031 makes different decisions from one that ships and leaves — fewer clever shortcuts, more written-down reasoning, and a strong preference for boring technology in the places that matter.

After launch that means monitoring and reporting on real performance, handling incidents and anomalies, managing availability and capacity, version upgrades, releases, and keeping the infrastructure and its configuration honest. Unglamorous, and the reason systems stay alive.