You're looking for an IT development company. You're doing what everyone does: comparing quotes, browsing portfolios, trying to figure out why one provider costs twice as much as another for what seems like the same project.
The thing is, projects that fail, in our experience, almost never fail because of price. Or because of a bad technology choice, for that matter. They fail because the provider didn't understand the real need, because the client saw nothing for four months, or because when it was time to switch providers, nobody could pick up the code.
At Dorima, we've been building custom software for over ten years. More than 150 projects delivered, for companies ranging from 5 to 500 people. We've seen projects go very well, and we've worked with many clients who came to us after a difficult first experience elsewhere. Over time, we've identified the criteria that actually make a difference. None of them appear in a quote.
What follows is what we would tell someone close to us who's about to choose their provider. Even if that provider is us.
Does the team understand your business, not just the tech? 🔍
The most underestimated criterion, by far.
A team can be technically excellent and deliver a product nobody uses. We've seen it. The software runs, it's fast, the code is clean. But it doesn't match the reality on the ground because nobody on the team took the time to understand how people actually work day to day.
In other words, the team built what they were asked to build. Not what the client actually needed. Those are two different things.
A good provider doesn't just take orders. They try to understand the problem behind the request.
The first conversations tell you a lot
Pay attention to the questions a provider asks you at the very beginning. Do they immediately ask how many pages you want, which features, what budget? Or do they start by asking about your business, your customers, what's not working today?
A provider who tries to understand your business first will push back on some of your requests. That's a good sign. An outside perspective combined with technical experience often leads to simpler solutions than what you'd originally imagined.
On the other hand, a provider who says yes to everything, takes your feature list and sends back a quote within 48 hours without asking a single meaningful question... that's not efficiency. It's a sign your project will be treated as an order to execute, not a problem to solve.
The question to ask
Ask them to tell you about a recent project in your industry or a similar one. How they approached understanding the need, what they discovered along the way, what changed from the initial brief. If the answer stays vague or purely technical, business understanding isn't their priority.
Will you see your project move forward, or wait in the dark? ⏳
We see the same scenario regularly. A client signs with an IT development company. They're told delivery is in six months. The first few weeks, a couple of emails. Then silence. The client follows up, they're told everything is going well. They ask to see something, they're told it's not ready yet. After five months, they're shown a version of the product. Which doesn't match at all what they had in mind.
That's the tunnel effect. And it's one of the most common reasons software projects end badly.
It's not necessarily bad faith
Some companies simply work that way: build everything, deliver at the end. It's simpler to manage on their side. But for you, it's a risk. During those months of silence, the team is building based on their own understanding of your need. Which is never exactly yours, even with the best requirements document in the world.
Small misunderstandings pile up. And the longer they pile up without being corrected, the more expensive they are to fix.
If you're not shown anything functional within the first two months, that's a warning sign.
What you should demand
Ask before you sign: how often will you show me what's been built? And by "show," we don't mean a written report or a PowerPoint presentation. We mean logging into a version of the product, even incomplete, and clicking around yourself.
A good provider shows you something functional every two to three weeks. Not a finished product — a prototype in progress. That you can test, critique, redirect.
If nothing concrete is offered within the first six to eight weeks, ask questions. If it's never offered at all, look elsewhere.
The question to ask
"Concretely, what does project tracking look like on the client side? Will I have access to a test version? How often?" Simple questions, but the answers speak volumes.
What happens if you want to leave? 🔓
The question nobody asks when signing a contract. And probably the one that should come first.
When you commission custom software, you're often investing tens of thousands of euros. That investment produces something tangible: code, an application, a database. But who owns all of that when the relationship ends?
Check the intellectual property clauses in the contract
In many contracts, code ownership is vaguely addressed. When it's addressed at all. Some providers keep ownership and grant you a usage license. Others transfer ownership but control the hosting. Others use proprietary building blocks that make you dependent on them for any future evolution.
Code built for you should belong to you. It's your investment, it's your working tool. Read the clauses before you sign.
The real question: could you switch providers tomorrow?
Beyond the contract, there's the technical reality. Imagine you want to change providers in two years. Can the new one pick up the existing code and keep evolving it? Or will they have to start from scratch because nothing is documented, the code is poorly organized, or it relies on tools only the original provider knows?
Well-written and documented code gives you freedom. Opaque code tied to a single provider is a prison — even a comfortable one.
The real test of your relationship with a provider is how easily you could leave them.
Concrete questions to ask
Before signing, check these points:
- Will I have permanent access to the source code?
- Is technical documentation included in the engagement?
- Does the code rely on open, widely-used technologies, or on proprietary tools?
- Is there a reversibility clause in the contract?
A serious provider won't have any trouble answering these. Usually, they'll have anticipated the question.
Certifications and labels: which ones actually matter 🏷️
When browsing IT development company websites, you'll see certification logos everywhere. Some hold the company to real standards. Others are there to fill up the "About" page. How do you tell the difference?
Three labels with concrete impact
The Innovation Tax Credit (CII) is an accreditation from the French Ministry of Higher Education and Research. If your provider is accredited, you can claim a 30% tax credit on innovation expenses. It's not a logo on a website — it's a direct financial advantage for your business.
Opquast certification means the developers have been individually trained and assessed on web quality best practices: accessibility, performance, security. It's an exam, not a badge you buy.
The RGESN (General Framework for Eco-design of Digital Services) is an official French framework for building responsible digital services. Committing to it means accepting to optimize resources and limit the environmental footprint of what you build.
The right reflex
When you see a certification on a website, ask yourself: does this label hold the company to verifiable standards? Does it have a concrete impact on my project or my budget? If the answer is no on both counts, it's decoration.
Communication when things don't go as planned ⚠️
You can choose the best IT development company on the market, with the best certifications and the best methodology. There will be surprises. That's the reality of this type of project.
A custom development project is construction work. There are uncertainties, constraints discovered along the way, adjustments to make. That's not a problem. The problem is when the provider tries to hide difficulties instead of flagging them.
What makes the difference
A good provider doesn't tell you everything is fine when it's not. They call you to say: "We've hit an obstacle on this point. Here's what it means for timeline and cost. Here are the options." It's uncomfortable in the moment. It's also infinitely better than discovering a problem that's been growing for weeks without anyone telling you.
If the answer to "tell me about a project that went wrong" is "that never happens to us", run.
The question to ask
Ask the provider to tell you about a project that didn't go as planned. How they handled it. What they learned. What they'd do differently.
If the answer is "that never happens to us" or "all our projects go smoothly"... be cautious. Either the company lacks experience, or they're not being honest. Neither is reassuring for what comes next.
Choosing beyond the quote 💡
Choosing an IT development company means choosing a partner for months, sometimes years. The quote amount matters, but it says nothing about the quality of the relationship, how rigorously the project is tracked, the longevity of what gets built, or the team's ability to handle setbacks.
The five criteria we just covered don't appear in any quote. They can't be verified by reading a brochure either. They're verified in conversations, in the questions you ask and the answers you get.
A provider who understands your business, who shows you the project regularly, who guarantees you ownership and portability of your code, who commits to verifiable standards and communicates honestly when things get tough — that's a provider you can build something solid with.
Take the time to verify these points before signing. Your project is worth it.
Summary: the questions to ask before signing 📋
| Question to ask | What you're checking |
|---|---|
| "Can you tell me about a recent project in my industry?" | Business understanding: does the provider care about your activity or just execute orders? |
| "How often will I see the product in progress?" | Project visibility: will you have regular check-ins or face a tunnel effect? |
| "Do I own the code? Will I have access to the source?" | Ownership and portability: could you switch providers if needed? |
| "What certifications do you hold, and what do they mean in practice?" | Verifiable commitments: real standards or window dressing? |
| "Tell me about a project that didn't go as planned." | Transparency: does the team handle difficulties or hide them? |
