What founder-led delivery changes: why the people who win a project should build it

Founder-led delivery means the people who scope your project, estimate it and make promises about it are the same people who design and build it. What it changes is the gap between the sale and the work: there is no handoff in which context is lost, no estimate made by someone who will not have to meet it, and no layer between your question and the person who knows the answer. What it costs is capacity, and we think a buyer should weigh both.

This is an opinion piece, and we have an obvious interest: Authect is a founder-led studio. So rather than tell stories about our own projects, we will argue the case from well-known research on how software gets delivered, and be specific about where the model is weaker. If the argument holds, it should hold whoever you hire.

The usual model, and why it exists

In a typical agency or outsourcing firm, a project passes through several groups of people. A salesperson or business development lead qualifies the opportunity. A pre-sales architect or solutions consultant scopes it and writes the proposal. An account manager owns the relationship. Once the contract is signed, a delivery manager or project manager takes over, and a team of developers, often assembled from whoever is available, does the work.

This structure is not foolish. It lets a firm win many projects in parallel, keeps expensive engineers on billable work, and gives large clients a single commercial contact. For big programmes with dozens of people, some of these roles are necessary. Our argument is narrower: for most products built by small teams, each handoff in that chain costs more than it saves, and the costs land on the client.

Handoffs lose the part that matters most

Lean thinking, applied to software by Mary and Tom Poppendieck, lists handoffs and relearning among the main forms of waste in software development. The reason is that what survives a handoff is the explicit part of the knowledge: the requirements document, the proposal, the call notes. What does not survive is the reasoning. Why did the client rule out a mobile app? Which stakeholder cares most about the reporting? Which 'nice to have' was actually the thing that won the deal?

Software is built out of thousands of small decisions that no specification covers. A developer who heard the client explain their business makes those decisions differently from one who read a summary. When the details are wrong, the cost is rarely a dramatic failure. It is a slow accumulation of reasonable-sounding choices that do not quite fit, each one requiring a meeting to discover and a change to fix.

The authors of the Agile Manifesto put this at the centre of their principles: business people and developers must work together daily throughout the project, and the most effective way to convey information to and within a development team is face-to-face conversation. Two decades on, direct conversation, on a video call as much as in a room, remains the cheapest way we know to stop context leaking. The simplest way to make it happen is to have no one standing in between.

Estimates are better when the estimator has to meet them

An estimate made during a sale serves two purposes at once: predicting the work and winning the deal. When the person estimating will not be the person delivering, the second purpose has no natural counterweight. Nobody needs to be dishonest for this to go wrong. Optimism is enough.

The Scrum Guide's position is unambiguous: the Developers who will be doing the work are responsible for the sizing. The reasoning is simple. The people doing the work know where the hard parts are, and they have a stake in the estimate being right, because they will live with it.

We should be honest that this is not sufficient on its own. Psychologists have long documented the planning fallacy, our tendency to underestimate our own tasks. In a well-known study by Buehler, Griffin and Ross, students predicted their theses would take an average of 33.9 days; they took 55.5, and only about 30% finished by the date they predicted. Interestingly, outside observers tended to err in the other direction. So being the person who does the work does not make your estimates accurate. What it does is make them accountable, and give you the experience to correct them.

The fix for the planning fallacy is to compare a new project with how long similar past projects actually took, rather than imagining the best case. That comparison is only possible when the estimator remembers the past projects in detail, because they built them. A founder who has delivered the last ten integrations knows how long the eleventh is likely to take, including the week lost to the vendor's sandbox being down. A pre-sales consultant working from a template does not.

An estimate is a promise made by someone. The question to ask is who, and whether they will be in the room when it falls due.

Accountability needs one owner

When a project with five layers between client and code goes wrong, each layer has a reasonable explanation. Sales scoped what the client asked for. The architect designed what sales scoped. The project manager tracked what the architect planned. The developers built what the tickets said. All of it can be true, and the project can still have failed.

Short chains make bad news travel faster. DORA's research on software delivery has repeatedly found that a culture with high trust and good information flow is predictive of software delivery performance. Its description of such a culture, borrowed from the sociologist Ron Westrum, includes messengers being trained rather than punished and failures leading to inquiry rather than blame. In a long supplier chain, every messenger has a commercial reason to soften the message. When the person who made the promise is the person writing the code, there is no one to pass the bad news to, so it reaches the client early, while there is still time to act on it.

There is also a simpler point about incentives. A founder's reputation is the firm's reputation. A missed deadline is not a line in someone else's utilisation report; it is a problem with the business we own. That does not make founders better people. It makes their incentives easier for a client to understand.

Fewer people in the loop, fewer paths for misunderstanding

Fred Brooks observed in The Mythical Man-Month that the number of communication channels in a group grows as n(n − 1)/2: four people have six possible conversations, eight people have twenty-eight. His famous corollary, that adding people to a late software project makes it later, is about the same arithmetic. The usual supplier chain adds people to the conversation who do not write code: each one is another path a requirement travels and another place it can be changed.

The industry has largely accepted this for teams. The Scrum Guide recommends teams of ten or fewer, noting that smaller teams communicate better and are more productive. Amazon's 'two-pizza team' rule, which AWS describes in its DevOps guidance, makes the same point more memorably. Founder-led delivery applies the logic to the client relationship as well as to the team: the smallest possible number of people between your problem and its solution.

Melvin Conway's 1968 observation is relevant here too. He argued that organisations which design systems are constrained to produce designs which copy their own communication structures. If the communication between you and your supplier runs through an account manager, a project manager and a ticketing system, the product tends to grow seams in the same places. When the people deciding and the people building talk directly, the design can follow the problem rather than the org chart.

Coherent design needs a small number of minds

Brooks also argued that a system needs conceptual integrity, a consistent set of design ideas, and that this comes from a single architect or a small group deciding what the system is. In a chain where one person designs the solution in a proposal and another team interprets it months later, conceptual integrity is the first thing to go. Each team member fills gaps with their own idea of the product, and the result feels like several products stitched together.

When a senior engineer who shaped the proposal also leads the build, the design ideas that won the project are the ones that ship. The same engineer reviews the work, so the architecture stays coherent as the product grows. This is also why we think every project should be led by a senior engineer, whoever the supplier is: someone has to hold the whole design in their head.

Faster decisions, smaller batches

DORA's research recommends working in small batches because it shortens the time to feedback and makes problems easier to find and fix. It suggests that any batch taking more than a week to complete and check is too big. Small batches need quick decisions: what to do next, whether a trade-off is acceptable, whether a change is in scope. In a layered supplier, many of those decisions wait for a meeting, a change request or someone's approval. In a founder-led team, the person who can make the call is usually the person who noticed the question.

This matters more now that AI tools make code faster to produce. The same DORA guidance links AI adoption to higher delivery instability and describes small batches as a countermeasure. Our reading is that producing code is becoming cheaper while judging it is not. The scarce resource is senior judgement close to the work: someone who understands both the client's problem and the code, and reviews every line before it ships.

What it looks like from the client's side

Arguments about structure are abstract, so here is what the difference looks like at the moments in a project where it shows most. None of this is unique to us; it is what any project looks like when the decision-makers and the builders are the same people.

1. The first call. You explain your business to someone who will build the product, and they ask the awkward technical questions straight away: where the data really lives, which system is the source of truth, what happens when the integration is down. Some of those questions change the scope before a proposal exists.
2. The estimate. It arrives with its assumptions written out and the risky parts named, because the person writing it will have to deliver it. If the honest answer is a range, you get a range, and a suggestion for how to narrow it.
3. The first demo. The person showing the software is the person who built it, so when you say a workflow feels wrong, the conversation moves straight to why and what to try instead.
4. The first surprise. A third-party API behaves differently from its documentation, or a requirement turns out to be harder than expected. You hear about it the day it is found, with options, rather than at the next status meeting.
5. A change of mind. You want to swap one feature for another. The trade-off is discussed with the people who know what each one costs, and decided in the same conversation.
6. After launch. The people supporting the product are the people who designed it, so diagnosing a problem does not start with someone reading the code for the first time.

The trade-offs, stated plainly

Founder-led delivery is not free, and a supplier that tells you it has no downside is selling. These are the real costs, and what we think a founder-led studio should do about each.

Key-person risk deserves a closer look, because it is the objection we hear most. It is real, but it is not unique to small firms. A study of 133 popular open-source projects estimated that 65% had a 'truck factor' of two or fewer, meaning the loss of two developers would leave most of the code without anyone who knows it well. Large suppliers rotate people between accounts too. The protection is not the size of the supplier; it is whether the knowledge lives in places you control: your repository, your documentation, your accounts.

When a larger supplier is the better choice

• You need many engineers across several workstreams to start within weeks.
• You need round-the-clock operational support from a dedicated operations team.
• Your procurement process requires a supplier above a certain size, or specific certifications held at company level.
• The work is a long programme of mostly well-specified tasks, where throughput matters more than judgement.
• You already have strong product and technical leadership in-house and want extra hands rather than a partner.

In those situations, the coordination roles of a larger firm are doing real work, and paying for them makes sense. Our guide to choosing a software development company covers how to compare suppliers of different sizes on more than price, and the software development outsourcing guide compares the engagement models in detail.

How to tell whether you will talk to the people who build

Whichever kind of supplier you choose, the questions below will show you how much distance there is between the people you meet and the people who do the work.

1. Who in this meeting will write code or review it on our project? Can we have their names in the contract?
2. Who produced the estimate, and will they be on the project?
3. If we message on a Tuesday afternoon with a technical question, who answers, and how long does it usually take?
4. What happens to our project if the lead engineer leaves or falls ill?
5. Can we see the repository, the board and the deployed environment from the first week?
6. Who decides whether a change is in scope, and how quickly?

Vague answers are informative. 'We will assign the best available team after signing' means the people you met will not be the people you work with. That may be acceptable for your project; it is better to know before the contract than after it.

What it changes in a contract

Founder-led delivery also changes which contract models work well. Because the people estimating are the people delivering, fixed prices can be offered on well-defined work without a large buffer for the gap between sale and delivery. Because changes can be discussed and decided directly, flexible models such as monthly sprints need less paperwork to stay under control. Our comparison of fixed price and time and materials explains when each fits.

How Authect works

Authect is founder-led. You talk to the founders who build your project, never to a salesperson. Every project is led by a senior engineer, and our teams are deliberately small. We use AI to speed up delivery, and an engineer reviews every line before it ships. You own the code, infrastructure and designs from day one, so there is no lock-in and the knowledge stays with you whatever happens to us.

We work through fixed-price projects, monthly sprints, and support and evolution. Our headquarters is in Dubai Silicon Oasis, with the team in Dubai and Spain and partners in Lithuania, working with clients across Europe, the Middle East and beyond. The capacity trade-off applies to us: we take on a limited number of projects at once, and we would rather tell you a realistic start date than overcommit. You can read more about how we work and who leads Authect, or talk to the founders directly.