Software Fails Between the Handoffs

A business owner pays an agency to design an app. The design is good. The agency hands over a file and moves on. A contractor builds most of it, invoices the last milestone, and rolls off. A third party inherits the repository to keep the lights on. Nine months later the payment integration stops working on a Saturday, and the owner is on the phone with three vendors who each explain, politely and correctly, why it is not their part.

Nothing in that story required bad code. Everyone did roughly what they were paid to do. The software failed anyway, because the failure lived in the space between them, and nobody owned that space except the person paying for all of it.

Failures cluster at the seams

When a project goes wrong, the instinct is to look for the weak link: the sloppy developer, the designer who did not think about edge cases, the maintenance shop that is slow to respond. Sometimes that is the answer. More often the work inside each boundary is fine and the trouble is at the edges, where one group's output becomes another group's input and a lot of unwritten context gets dropped on the floor.

A design file does not carry the reasoning behind it. A repository does not carry the four decisions the team made in a call about how the pricing rules work. A deployment does not carry the knowledge that a particular third-party account is on a personal credit card. Handing work over transfers the artifact. It does not transfer the understanding, and the understanding is most of the value.

Here is where it tends to break:

• Design to build: the screens describe the happy path. Nobody specified what shows up when the list is empty, when the upload fails, when a user has permission to see part of a record but not all of it. The builder invents answers, quickly, under deadline.
• Build to launch: the code works on a laptop. Environment variables, domains, DNS, email deliverability, app store accounts, and payment credentials belong to whoever happened to set them up, and half of them are in someone's personal login.
• Launch to maintenance: the team that inherits the code did not choose the architecture and does not trust it. Their safest move is to touch as little as possible, so small changes get quoted like large ones.
• Vendor to vendor: when something breaks across a boundary, diagnosis requires access on both sides. Each party can see half the evidence. The client becomes the message bus.

Why the client ends up holding the pieces

Each vendor scoped their piece, priced it, and delivered it. None of them scoped the integration of all the pieces, because that is not a deliverable anyone sells easily. It is a continuing responsibility, and continuing responsibility is hard to put in a fixed-price statement of work.

So it defaults to the client, who is usually the least equipped person in the arrangement to carry it. The owner of a service business is not going to arbitrate whether a bug belongs to the front end or the API. They just know the thing that cost real money does not work, and that asking about it produces three different explanations.

Questions to ask before you sign

You can find most seam problems before they exist by asking about ownership rather than about features. Ask any vendor, including us:

1. Whose accounts are these? Hosting, domain, database, payment processor, email, analytics, app store listings. Every one of them should be created under your organization with the vendor invited in, not the other way around. This is the single most common way a business gets stuck.
2. Who do I call at 9pm on a Saturday, and what does that cost? If the answer is vague, you do not have support. You have a hope.
3. What happens on the last day of the engagement? You want a specific handover: repository access, credentials, a written architecture overview, how to deploy, how to restore from backup, and what is still unfinished.
4. Who is accountable when the cause is unclear? If the design, the build, and the hosting come from three parties, decide in advance who investigates first. Otherwise the default investigator is you.
5. Can I export everything, and have you ever done it? Ask for the export path for your data in a usable format. A vendor who has actually run that export will describe it in detail.
6. What do you consider out of scope that a client usually assumes is included? Good answers here tell you more about a vendor than any portfolio does. Common gaps: data migration, content entry, training, accessibility, and anything about email deliverability.

What a single accountable team changes

The reason we run design, build, and deployment with the same people is not that the work is more pleasant that way. It is that the arguments happen internally, before they cost you anything. When the person drawing the screens and the person modeling the database are in the same conversation, the interface and the schema never end up contradicting each other three weeks later. When the people who wrote the code also run it in production, the on-call pain is their own, so they build it to not page anyone.

There is also a simpler effect. When one team is responsible end to end, nobody gets to say it is not their part. That sounds like a small thing. In practice it is most of the difference between software that keeps working and software that quietly stops.

When splitting the work is the right call

This is not an argument that every project should have one vendor. Splitting makes sense in a few real cases.

• You have an in-house team. If you employ engineers who will own the system afterward, bringing in outside help for a defined piece is sensible, as long as your team sets the architecture.
• The boundary is a genuine product boundary. A separate vendor for a payment processor or a mapping provider is fine. Those have documented interfaces and their own support obligations.
• The work is genuinely specialist. Security review, a branding system, or a legal compliance assessment are rightly separate, because you want independence rather than integration.
• You are large enough to run vendors. Coordination is a job. If someone on your side owns it and has the authority to make a call, multiple vendors work fine.

The failure mode is not having several vendors. It is having several vendors and no one whose job is the whole.

The takeaway

When you evaluate a proposal, read past the feature list and look for who is on the hook after launch. Most of the risk in a software project is not in the difficulty of the work. It is in the assumption that every piece will fit together because everyone was competent at their piece. Competence at the piece is table stakes. Someone has to own the seams, and if the contract does not say who, the answer is you.

If you are in the middle of that right now, holding pieces from three vendors and trying to work out whose problem it is, that is worth a conversation. Tell us what you are dealing with and we will be straight about whether consolidating is worth it or whether your current setup is fine and the problem is somewhere else.