Build vs hire
What you are actually buying when a dev shop quotes you
Almost every agency uses engineering you never meet. That is not the problem. Not knowing who is accountable when it goes wrong is the problem. Six questions that get you a straight answer.
There is a version of this article that says offshore development is the problem and you should hire local. It would be good marketing and it would be wrong.
Distributed engineering is how most shops of any size deliver, including ours. Kingbird is US-led, which means one senior US operator is accountable for your engagement start to finish, and engineering is scaled to your budget. We are not going to pretend that means every keystroke happens in Arizona, because it does not, and you can find shops making that claim who are not being straight with you.
The real question is not where the engineers sit. It is whether anyone is accountable, whether you can name them, and what you are left holding when it ends. Here are the six questions that surface that.
1. Who is the named senior person on this, and will they be here in month four?
Not the account manager. Not the "engagement lead" who appears on the kickoff call and then goes quiet. The person who will read your code, make the architecture calls, and answer for it when something breaks.
You want a name. If the answer describes a process, a pod, or a methodology instead of a human, you have learned something.
Follow up with: what percentage of their week is on my project? A senior operator spread across nine engagements is a reviewer, not an owner.
2. Who else touches the code, and in what time zone?
Ask plainly. Most shops will tell you. The ones that get uncomfortable are usually the ones marketing themselves as something they are not.
Time zone matters more than geography, because it determines how long a blocked question stays blocked. A team eleven hours out is workable if the handoffs are structured and someone senior overlaps with your day. It is painful if every clarification costs a full cycle.
3. What do I own when this is over?
Write down the list and put it in the agreement:
- The repository, in your organization, not theirs
- The deploy pipeline and the ability to run it
- Environment variables and secrets, in your vault
- Domain, hosting, and third-party accounts in your name
- A written runbook a new engineer can follow without calling anyone
If any of these sit in the vendor's account by default, you do not own a product. You own a subscription to that vendor, and the price of that subscription is whatever they decide it is the day you want to leave.
4. What happens if the person running my project leaves your company next month?
This is the best single question on the list, because it tests whether knowledge lives in a system or in one person's head.
A good answer describes where things are written down: the runbook, the architecture decisions, the reason the weird thing is weird. A bad answer is reassurance. Reassurance means the knowledge is in the head, and when the head leaves, you are paying someone to rediscover your own product.
5. Show me a project you inherited from someone else
Anyone can show you a greenfield build that went well. Ask to hear about a takeover: a codebase they walked into cold, what they found, what they told the client, and what it cost to stabilize.
The answer tells you two things. Whether they have the seniority to read unfamiliar code, and whether they will tell a client bad news. You want both, because at some point you will be the client receiving bad news.
6. What would you refuse to build for me?
A shop that will build anything you describe is a shop that will take your money for the wrong thing. You want to hear a real boundary: a category of work they turn down, a project shape that does not fit, a technology they will not touch.
We turn down foundation model training, for instance, because integrating and applying models is our work and training them is not. Saying so costs us occasional projects and saves clients from a bad engagement.
The pattern
Every one of these questions is asking the same thing in a different way: when this gets hard, who is on the hook, and will they tell me the truth?
The portfolio does not answer that. The case studies do not answer that. The rate does not answer that. Six direct questions, asked before money moves, mostly do.
If you have a quote in front of you and you want a second read on it, send it over. We will tell you what we would want clarified before signing, whether or not you end up working with us. If you want our version of the answers above, they are on how we work and US-led development.
Frequently asked questions
Is it bad if a development shop uses offshore engineers?+
No. Distributed engineering is normal and it is how most shops of any size deliver. What matters is whether one senior person is accountable for the outcome, whether they work in your time zone, and whether you can name them. A shop with excellent offshore engineers and clear accountability beats an all-local shop with none.
How do I find out who will actually write my code?+
Ask directly, in writing, before you sign: who is the named senior person accountable for this engagement, will they still be on it in month four, who else touches the code, and what time zones do they work in. Any shop can answer that in a sentence. Watch for answers that describe a process instead of naming a person.
What should I own when the engagement ends?+
The repository, the deploy pipeline, the environment variables and secrets, the domain and hosting accounts, and a written runbook that lets a new engineer deploy without calling anyone. If any of those live in the vendor's account, you have a dependency rather than an asset. Get it in the agreement.
What is the single best question to ask a dev shop?+
Ask what happens if the person running my project leaves your company next month. The answer tells you whether the knowledge lives in a documented system or in one head, which is the difference between a delay and a rebuild.
Where this goes next
If this helped
You can put this thinking to work directly. Run the diagnostic on a stuck product, or book a 30-minute call to talk through your situation.