BYD TechThe short answer
Choose a software development company on four things: who owns what they build, who actually does the work, how you will see progress, and how they handle changes and problems. Ask for evidence on each, talk to a past client if you can, and start with a small, defined first piece of work before committing to a large project.
Key points
- Ownership first: code, cloud and accounts should be in your name from day one.
- Ask who will write the code, and who you will talk to.
- You should be able to see working software, not only status reports.
- A good partner tells you when something off the shelf would do.
- Start small. A short, defined first phase shows how they work.
Ownership: the first question
Before price or portfolio, ask who will own the code, the cloud account, the domain and the app store accounts. The safe answer is you, from the first day, with the code in a repository under your company’s account. If a partner keeps any of these, leaving them becomes hard, and that changes every later negotiation.
- Is the code in my GitHub, or yours?
- Are the cloud and store accounts in my company’s name?
- When is intellectual property assigned to me?
- Could another team take over from the repository alone?
Who does the work
- Who will write the code, and will I know their names?
- Who will I talk to: the people building it, or an account manager?
- Is any work passed to other companies, and will I be told first?
- How is AI used in writing the code, and who reviews it?
The last question matters more now than it did. AI can speed up good work, and it can also produce a lot of unreviewed code. See Vibe coding to production.
How you will see progress
- Will I get a preview link I can open myself, as the work progresses?
- Is there a shared board I can read, in plain English?
- How are decisions and their reasons written down?
- How will I hear about a problem, and how early?
Working software you can click is the only progress a non-technical founder can verify. Be wary of updates that are all words and no screens.
How they handle change and estimates
- How do you estimate, and what happens when scope changes?
- Do you start with a scoping phase, and what do I keep from it?
- Have you ever told a client to use an existing tool instead of building?
- What happens after launch: fixes, support, and handover?
Red flags
- A firm price and date for a product nobody has scoped yet.
- Reluctance to put the code in your account.
- No way to see working software until the end.
- Every question answered with a yes, including the ones that should be "it depends".
- Case studies they cannot let you verify with the client.
Start with something small
A short, defined first phase, such as scoping and a clickable prototype, shows how a team communicates, how it handles disagreement, and what its work looks like. You keep what it produces either way.
These are the questions we expect to be asked. At BYD Tech the code lives in your GitHub from day one, you talk to the founders, and AI-drafted work is reviewed by a named engineer. Our MVP development and web app development both start with scoping.
Sources
Checked when this guide was written.
