The contract is the easy part
Choosing a software development company is one of the few decisions where you pay first and find out later whether you chose well. Portfolios look polished. Sales calls go smoothly. Everyone promises quality, speed and transparency.
The real differences show up months later: when a feature is late, when the original developer leaves, when you want to switch providers and discover you don't hold the keys. The good news is that you can surface most of those differences before you sign. You just need to ask the right questions and listen carefully to the answers.
Here are ten questions we'd ask if we were in your seat. They work whether you're looking for custom software development locally, comparing a software development company in Bulgaria with one elsewhere in Europe, or hiring a freelancer for a smaller project.
Ownership and control
1. Who owns the code, the data and the accounts?
This is the question that matters most and gets asked least. The answer you want is simple: you do. The source code repository, the cloud accounts, the domain, the database and every third-party subscription should be registered to your company, with the provider given access, not the other way around.
Ask to see this written into the contract. If the answer is vague ("we host everything for you, don't worry"), you're renting your own product. That might be fine for a while. It becomes a serious problem the day you want to leave.
2. What happens if we part ways?
Good partners plan for the breakup on day one. Ask what a handover looks like: documentation, credentials, a walkthrough for the next team. A confident provider answers this calmly. A defensive answer tells you a lot.
The people and the process
3. Who will actually do the work?
The person who sells the project is often not the person who builds it. Ask who writes the code, who designs the interface and who you'll talk to when something breaks. Ask whether any part of the work is subcontracted, and to whom.
There's no single right model. A small, founder-led team and a large agency can both deliver well. What matters is that you know who's on the other end and that the people in the sales meeting stay involved after it.
4. How do you turn our idea into a plan?
Strong teams don't start with code. They start by asking about your business: who uses the system, which process hurts today, what success looks like six months after launch. Expect a discovery phase that ends with something concrete, such as a written scope, wireframes or a clickable prototype.
If a provider gives you a fixed quote after one short call, be careful. Either they haven't understood the problem, or the quote is padded to cover what they haven't understood.
5. How often will we see working software?
Not status reports. Working software. Ask how often you'll get a demo you can click through yourself. Regular demos keep the project honest: misunderstandings surface in days, not months, and you can change direction while it's still cheap to do so.
At DSX we prefer short cycles with a live demo at the end of each one, because a ten-minute demo answers more questions than a ten-page report.
After launch
6. What happens after we go live?
Launch is the beginning, not the finish line. Software needs security updates, bug fixes, monitoring and small improvements as your business changes. Ask who handles that, how quickly they respond, and how support is agreed and billed.
A provider who only talks about the build and goes quiet on support may be planning to hand you a finished product and move on. That's a legitimate model, but you should know it upfront. If you want one team from design to long-term support, look for ongoing IT support and managed services as part of the offer, not an afterthought.
7. How do you handle security and GDPR?
If your software stores customer data, and almost all business software does, you carry responsibility under GDPR. Ask how the provider handles access control, encryption, backups, and where the data is physically hosted. Ask whether they'll help you think through what personal data you actually need to collect.
You don't need a security lecture. You need clear, specific answers. If the provider can't explain their approach in plain language, they probably don't have one. For a deeper look, see our cybersecurity and IT auditing service.
Communication and trust
8. How will we communicate, and how fast?
Agree on the channel, the rhythm and the response time before the project starts. Weekly call? Shared task board? One contact person on each side? Small details like these decide whether a project feels calm or chaotic.
Language and time zone matter too. Working with a team in your time zone that writes clearly in your language saves hours of back-and-forth every week.
9. Can we talk to someone you've worked with?
A portfolio shows what was shipped. A reference tells you what it was like to get there. Ask for a conversation with a past client, and ask that client one question in particular: "What happened when something went wrong?" Every project hits problems. How a team behaves under pressure is the thing you're really buying.
10. What would you advise us not to build?
This is our favourite question because it's hard to fake. A good partner will push back: suggest an off-the-shelf tool for part of the job, cut a feature from the first version, or tell you a simpler approach will do. A provider who agrees with everything is selling hours, not solving your problem. Our build vs. buy guide goes deeper on this decision.
Red flags worth walking away from
- The code and accounts stay in the provider's name with no clear plan to transfer them.
- A fixed quote with no discovery, especially for a complex system.
- No demos until the end. "Trust us, it'll be ready" is not a process.
- Nobody can tell you who writes the code.
- Pressure to sign quickly, with discounts that expire this week.
- Silence about support, security or GDPR until you bring them up.
One red flag isn't always a deal-breaker. Two or three together usually are.
A simple way to compare offers
Put every shortlisted provider through the same ten questions and write the answers down side by side. Price will differ, but so will ownership terms, support and how each team thinks about your business. The cheapest offer that leaves you without your own code is rarely the cheapest in the long run.
If you're weighing up custom software development and want a straight answer to any of these questions, talk to us. We'll walk you through how we work, including what we'd advise you not to build.