How we work · the team model
Two, six, ten and eleven. Those are the teams, and you can check all four.
Every supplier publishes an org chart of roles. Almost none publishes the sizes it has actually run, because the sizes are either embarrassing or invented. These four numbers come from the four cases on this site and each one is printed on the case it belongs to.
What follows is the shape behind each number, and then the more useful half: when each role is not needed at all.
The real numbers
Four engagements, four different shapes
The ratio matters more than the total. Each of these was staffed to where the difficulty actually was, and the difficulty was in a different place every time.
Eleven · regulatory compliance
One project manager, one system analyst, one designer, five ML, data and trading analysts, one QA engineer, one DevOps engineer, one full-stack developer. Five analysts against one developer: the difficulty was understanding what a regulation requires and what abusive trading looks like, not building screens. The case
Ten · SMS threat detection
One project manager, one system analyst, one designer, three ML, data and trading analysts, one QA engineer, one DevOps engineer, one back-end and one front-end developer. Three analysts against two developers: detection is won by people who can tell a fraud campaign from a marketing one and keep being right after the fraudsters adapt. The case
Six · municipal platform
A full delivery team for a system with a real workflow, several roles and two clients over one core — built, handed over, and running since 2020 without us. The size that suits a system where the domain is knowable and the volume of screens is the work. The case
Two · payment application
One mobile engineer and one backend engineer on a PHP service, maintaining and migrating a payment application that stayed in production throughout. A well-understood product with a hard external deadline does not need a team; it needs two people who are not interrupted. The case
The roles
What each person is for, and when they are not needed
- System analyst. Turns what the business does into entities, states, rules and the cases nobody mentions because they are obvious to anyone who does the job daily. On a domain-heavy system this role saves more than any other — and it is the first one inexperienced buyers cut. Not needed when the domain is genuinely simple or you already have a business analyst who writes things down.
- Project manager. The plan, the schedule, the risks and the fortnightly review. Not needed below about four people, and we will not invoice you for one. Never a translator between you and the engineers.
- UI/UX designer. Needed when an interface will be looked at by people who did not choose to use it — the public, customers, inspectors. Not needed when the system is internal, the users are trained, and consistency matters more than appearance.
- QA engineer. Needed where a defect reaches money, a regulator or a person's day. Not needed when you have QA who already know your business, which is worth more than ours who do not.
- DevOps engineer. Needed when the deployment path does not exist yet, or exists and nobody dares use it. Not needed when you have a platform team — then our engineers fit into your pipeline instead of building a second one.
- Analysts, ML and data. Needed when the product is a judgement rather than a screen. This is the role that scales with difficulty rather than with volume, and the two engagements above show it going to five and to three.
- Developers. Fewer than people expect on domain-heavy systems, and the ratio is the point rather than the headcount.
Staffing rules we keep
Four things that decide the shape before any CV appears
01 · Staff the difficulty, not the deliverable
Count where the project can actually fail. If it is the domain, the analysts outnumber the developers and nobody should be surprised by the invoice. If it is the deadline, the team is small and uninterrupted.
02 · One name accountable
Not a committee and not a role title. On small teams the senior engineer, on larger ones the project manager, and the name is in the proposal rather than discovered during the first incident.
03 · Assigned to a phase, not reserved
People are committed to the phase in front of them, and we tell you honestly whether the same people will be free for the next one. Promised continuity that does not arrive is worse than continuity never promised.
04 · Named people, with their weak spots
You meet the engineers before the contract, and we say what each is weaker at — strong on the platform, new to your domain; excellent engineer, quiet in a meeting of twelve. You would find out in week three anyway.
Questions
The ones that come up when the proposal arrives
Why are your teams so small?
Because the second developer on a system costs more than half a developer in coordination, and the fifth costs considerably more than that. We staff to the shape of the problem instead: the compliance engagement carried five analysts and one developer because the difficulty was understanding regulation rather than writing screens, and the payment application ran on two people because it was a well-understood product with a hard deadline. A supplier whose teams are all the same size is staffing from a rate card.
Do we get a project manager?
On an engagement large enough to need one, yes, and their job is the plan, the schedule and the risks — not translating between you and the engineers. Below about four people a project manager is overhead and we will not invoice you for one. If you ever find yourself explaining something technical to somebody who cannot answer a technical question, that is a staffing failure of ours.
What does a system analyst actually do?
Turns what the business does into something a developer can build and a tester can check — the entities, the states, the rules, the cases nobody mentioned because they are obvious to everyone who does the job daily. On domain-heavy systems this role saves more money than any other, and it is the first one inexperienced buyers try to cut.
Can we use our own designer, QA or DevOps?
Yes, and you should where you have them. We would rather fit into a capability you already own than duplicate it and charge you twice — and a QA engineer who already knows your business is worth more than ours who does not. Tell us what you have and the proposal is staffed around it.
Who is actually accountable if it goes wrong?
One named person on our side for the engagement, and it is not a committee. On small teams that is the senior engineer; on larger ones the project manager. The name is in the proposal rather than discovered during the first incident.
What happens to the team between phases?
People are assigned to a phase, not reserved indefinitely, and we will tell you honestly whether the same people will be available for the next one. A supplier who promises continuity it cannot deliver produces the worst version of this: the same names on the proposal and different faces in the stand-up.
Next step
Tell us what you already have
Design, QA, a platform team, an analyst who knows the domain. Every one of those makes the proposal smaller, and that conversation is better had before the proposal than after it.