To choose a software development company, compare evidence of relevant work, a defined first release and the team responsible for delivery. Agree how changes, acceptance, access and ongoing support will work. Apply the same questions to a mobile app, a web application or the infrastructure behind them.
Give each shortlisted company the same brief: users, main workflow, existing systems, data, constraints and the outcome you need first. Ask them to explain their assumptions. Comparable proposals make it easier to understand what your money buys and what remains undecided.
Define the first release and its acceptance criteria
Describe a complete user journey, supported platforms and the integrations it needs. Separate the first release from later ideas. For a customer portal, specify who signs in, which records they can access and what happens when a request fails. Ask the company to state exclusions and dependencies before estimating the work.
What will we demonstrate to accept the first milestone, and what is outside it?
Verify relevant work and the company’s role
Open available products and review the workflow most relevant to yours. Ask which parts the team designed, built and maintains. Distinguish an owned product from a client engagement and a prototype from a public release. With permission, discuss delivery and support with references. Treat awards as context; verify the issuer and date rather than using recognition as proof of engineering quality.
Can you show a comparable workflow and explain exactly what your team delivered?
From our portfolio
See the products behind the guides.
Explore three products built, owned and operated by Brainbaby Labs. Start with the interface, then review the case study for the product decisions and engineering context relevant to your project.
Mobile applications
Baby Astro
Review how Baby Astro brings chart navigation, learning and daily insights into a mobile experience.
Web applications and AI
Brainbaby AI
See how Brainbaby gives coding and presentation work their own browser workspaces.
Catalogues and connected systems
Cardboom
Explore Cardboom’s catalogue journey and the engineering decisions behind its collector tools.
These are owned-product examples. Screens show the documented interface versions; the case studies explain their capture context and the scope of the engineering review.
Meet the people responsible for delivery
Identify the technical lead and the person who makes scope decisions. Agree how often you will see working software, how issues are recorded and who approves changes. Ask the team to explain its technology choice against your requirements and existing systems. A useful first meeting resolves a specific uncertainty instead of presenting a list of tools.
Who owns technical decisions, and how will we review progress and changes?
Agree ownership, access and the handover
Review source-code rights, third-party licenses, service accounts and release documentation. Decide who controls the repository, domains, hosting, app-store accounts and recovery access. Ask for a practical handover plan so another team can build and operate the software. Account access and intellectual-property rights are separate questions; record both in the agreement.
What rights, accounts, documentation and access will we receive, and when?
Compare the full cost and change process
Compare proposals against the same scope. Separate implementation from hosting, provider usage, licenses and maintenance; record the assumptions behind recurring costs. Ask how a fixed scope or time-based engagement handles discoveries and revisions. Link milestone payments to agreed deliverables and identify who can approve additional work. A price alone does not explain what is included.
What changes the estimate, and how are extra work and recurring costs approved?
Plan security, release and ongoing operation
Discuss the access rules, test evidence, deployment process, backups and recovery needs of your product. Ask how defects and security issues are received, prioritised and resolved after launch. Agree support responsibilities and any response commitments explicitly. For AI features, include representative task evaluations and usage costs. The checklist below records your review; it does not certify a supplier or replace project-specific due diligence.
Who operates the release and responds when users or infrastructure encounter a problem?