Choosing a partner to build custom software is a big decision. You'll be trusting them with your workflows, your data and a significant budget, and you'll likely work with them for years. Many businesses choose based on a polished presentation or the lowest quote and regret it later. This guide covers what really matters and the questions worth asking.
Relevant experience
Ask to see work similar to yours — not necessarily in your exact industry, but with similar kinds of workflow: field teams with mobile apps, shop-floor tracking, approvals, customer portals, dashboards. Ask:
- Can you show us a live system, not just screenshots?
- What was the hardest part of that project and how did you handle it?
- Can we speak to a client?
Pay attention to whether they talk about the client's business results or only about technology.
How they understand your business
The best indicator of a good partner is the quality of their questions. In early conversations, do they ask about your users, exceptions, existing data and goals? Or do they jump straight to features and technology? A partner that challenges you — "do you really need this in the first phase?" — is usually more valuable than one that agrees with everything.
Discovery process
Ask how they turn your idea into a specification. A good process typically includes workshops with users, review of current spreadsheets and forms, workflow mapping, prototypes or wireframes, and a written scope with priorities. Discovery may be a paid phase — that's normal and often money well spent, because it reduces risk in the build.
Communication and transparency
- Who will be your main contact, and will you talk to the people actually building the software?
- How often will you see working software?
- How are progress, risks and issues reported?
- Which tools do they use for tracking tasks and sharing builds?
- What time zones and languages are involved?
Regular demonstrations of working software are the best protection against surprises.
Handling changes
Requirements will change — that's normal. Ask how changes are requested, estimated and approved. A clear change process protects both sides; a vague one leads to disputes about what was included.
Ownership, access and data
Agree in writing:
- Who owns the source code written for you, and on what terms.
- Where the code is stored and whether you'll have access.
- Who owns the data, and how you can export it.
- Whose accounts the hosting, domains and app store listings are under.
- What happens if the relationship ends — handover of code, documentation and credentials.
These questions are uncomfortable at the start but far more uncomfortable later.
Quality practices
Ask how they ensure quality: code reviews, automated and manual testing, staging environments where you can test before release, backups, security practices and monitoring after launch. You don't need to be technical to ask "how do you test before a release?" and judge whether the answer is confident and specific.
Security and hosting
Ask where the application will be hosted, how data is backed up, how access is controlled, how passwords and sensitive data are handled, and how security updates are applied. If you have specific regulatory or customer requirements, raise them early and ask how the partner would address them — and be wary of anyone who promises compliance without understanding your obligations.
Support after launch
Software needs care after go-live: bug fixes, updates for new phone and browser versions, security patches, small improvements and help for users. Ask what's included after launch, for how long, what response times apply and how ongoing support and enhancements are arranged.
Comparing quotes
Quotes for the same project can differ widely. Before comparing prices, check that each quote covers the same scope: discovery, design, development, testing, deployment, data migration, training, documentation and support. Ask each vendor to state their assumptions — what they included and excluded. A low quote with many exclusions isn't cheaper. See what drives custom software cost.
Red flags
- A fixed price for a large, vague scope without discovery.
- No questions about your business before quoting.
- Reluctance to show live work or provide references.
- Promises that everything is possible, quickly and cheaply.
- Unclear code and data ownership.
- No staging environment or testing process.
- Long periods without working software to see.
- Guaranteed integrations with third-party systems before checking what those systems allow.
Start with a small engagement
If you're unsure, start with a paid discovery or a small first phase. You'll learn how the partner works — communication, quality, reliability — before committing to the full project. Good partners welcome this.
Questions checklist
- Can you show a similar live system and a client reference?
- What does your discovery process look like?
- How often will we see working software?
- How are changes handled?
- Who owns the code and data, and how is handover done?
- How do you test and release?
- Where is it hosted and how is it backed up and secured?
- What support is included after launch?
- What assumptions and exclusions are in your quote?
Corposol has built web apps, mobile apps and business systems since 2018. We're happy to answer every question on this list. Talk to us.
Frequently asked questions
Should we choose the cheapest quote?
Not on price alone. Quotes often differ because vendors understood the scope differently. Compare what's included — discovery, design, testing, deployment, support — and how changes are handled.
Who should own the source code?
Agree this in writing before starting. Many businesses expect to own the code written specifically for them; some vendors license reusable components. Either can be fine if it's clear and fair.
Fixed price or time and materials?
Fixed price suits well-defined scopes; time and materials suits evolving requirements. Many projects use a fixed-price discovery phase followed by phased delivery.
How important is industry experience?
Helpful but not essential. A partner who has built similar workflows — field service, manufacturing, approvals — will ask better questions and avoid known pitfalls.
What support should we expect after launch?
Bug fixes for a defined period, a clear process and response times for issues, and an agreed way to request and price enhancements.
