There’s a common way to run a software shop. Win the project, then farm the building out to whoever is cheapest and free: a backend contractor here, a freelance designer there, QA in a timezone that overlaps with yours for two hours a day. On a spreadsheet it looks like leverage. In the repository it looks like four different opinions about how to handle an error.
Everything we take on is designed, built and shipped by our own team. That’s a constraint, not a slogan, and it costs us work we could otherwise accept.
What a handoff actually loses
The polite version is that something gets lost in translation. The real version is more specific than that.
What gets lost is the stuff nobody wrote down. The client mentions, offhand, in the third call, that the warehouse tablet gets used with gloves on. That never becomes a ticket. Nobody logs it, because it wasn’t a requirement, it was a fact about the world. And the person implementing the touch targets is two companies away from the room where it was said, so the buttons ship at a size that works beautifully on a designer’s monitor and is unusable at the only place it matters.
Multiply that by every unrecorded detail in a project. That’s the tax, and it doesn’t appear on any invoice.
When one team carries the work from the first call to launch, the person who heard it is connected to the person building it. Frequently they’re the same person.
Speed isn’t a headcount problem
People assume in-house means slower, on the theory that fewer hands means less throughput. In practice the opposite happens, and the reason isn’t mysterious.
Software projects don’t lose their time to typing. They lose it to waiting. Waiting for a reply. Waiting for a clarification. Waiting for a contractor’s other client to stop being on fire. Waiting for three vendors to agree on whose piece owns the retry logic. Every one of those is a queue, and queues are where a calendar goes to die.
A team that sits together deletes the queues. The decision that would have been a two-day email thread is a two-minute conversation, and nobody has to be re-briefed on Monday about what was agreed on Friday.
You own it, and that has to outlast us
This is the part that bites people who went the subcontractor route, and it usually bites about six months after launch.
Something needs changing. The freelancer who wrote that part is unreachable. The agency that coordinated them has rotated its staff twice. The codebase is three dialects with no translator, so the honest quote for a small change is a rewrite, because nobody can safely touch what they can’t read.
We build end to end so that the thing that ships is one system, written one way. The code is yours, it’s documented, and the people who wrote it still work here.
Where this is the wrong answer
We’re not going to pretend the model has no cost.
If you need forty engineers on something next month, we’re the wrong call and a firm that brokers contractors is the right one. If your project is genuinely three unrelated products in a trenchcoat, splitting it across specialist vendors may well beat one team doing all of it. We’ve turned work down for both reasons and we’d do it again.
What we won’t do is take the project and quietly subcontract it anyway. That’s the option that looks like a yes and behaves like a no, and it’s the one that produced every rescue job we’ve ever inherited.
We’ve shipped more than 100 projects this way, and we run our own products through the venture program, which means we’re also the client who has to live with a codebase years after launch. That changes what you’re willing to ship.
If you want software built by the people who’ll stand behind it, start here.