Most software projects that go wrong don't fail because of the wrong technology. They fail because of the wrong partner. Developers who promise more than they can deliver. An agency that never understood the brief. A freelancer who disappears three months in. This is a guide to spotting those situations before you sign a contract and pay a deposit.
Portfolio: what to actually look for
Every developer and every agency will show you attractive screenshots. Screenshots tell you nothing about code quality, how the collaboration actually went, or whether the project is still running properly a year after launch.
Instead, ask specific questions:
- What technology does it run on, and why did they choose it? If the answer is "because we know it best," that's acceptable. If the answer is "because it's the most modern," be cautious — modern technology isn't automatically the right technology.
- Who maintains it now? If the current supplier maintains the system and the client has no access to the code or documentation, that's a warning sign.
- Can I contact a previous client? Serious suppliers have no problem providing references. If every project is "under NDA" or contact isn't possible, that alone isn't a dealbreaker — but ask why.
- How did the project actually go? Whether a project finished on time, on budget, and without disputes tells you more than the final product.
Real-world example: Brno-based Technoprojekt s.r.o. chose an agency based on a reference site that looked impressive. Only after signing the contract did they discover that site was built by a single developer who had since left the agency. The entire project had to be restarted with a new supplier six months later.
Communication: red flags in first contact
The first email or first call reveals more about a supplier than you might expect.
Bad signs:
- Vague answers to specific questions ("it depends on a lot of things, we'll discuss it at a meeting")
- No questions back — you receive a proposal without a single clarifying question
- Instant yes to everything — every requirement is "absolutely no problem"
- A proposal arrives within 24 hours for a complex project that deserved real analysis
- They talk exclusively about technologies, not about your business
Good signs:
- They ask questions you didn't expect ("Who will use this system?", "How do you do it now?", "What happens when it fails?")
- They identify things you left out of the brief
- They openly state what they can't do or wouldn't recommend for your case
- They propose how to gather more detail before giving a final price
A supplier who asks nothing either didn't understand your brief or doesn't care. Both are problems.
Pricing: what's too cheap, what's fair
Pricing is a sensitive topic, but a simple rule applies: custom software development cannot be priced like a commodity.
| Type of supplier | Approximate hourly rate (EUR) | Typical risk |
|---|---|---|
| Offshore / nearshore (outside CZ/SK) | €15–35 | Language barrier, time zones, low accountability |
| Junior freelancer | €20–40 | Limited scope, availability, continuity |
| Senior freelancer | €40–70 | Capacity, no backup |
| Small agency (3–10 people) | €45–75 | Overload, staff turnover |
| Mid-size agency (10+ people) | €60–100 | Overhead, anonymous projects |
If you receive a proposal with an hourly rate that seems suspiciously low for a web application built in Central Europe, be sceptical. Either it's offshore work disguised as local, or it's a developer who has underpriced the job and won't finish it.
Conversely, a high price doesn't automatically mean quality. Large agencies carry significant overhead — project leads, project managers, account managers. For the same money, you get less actual development.
Practical tip: Ask for a cost breakdown by specific line items. How much for analysis? How much for development? Testing? Deployment? A supplier who refuses to break down costs or can't explain what you get for each line item is a problematic partner.
Contract: what must be in it
Verbal agreements don't hold. Software projects are complex and disputes without a written contract are very hard to resolve. Here is what you should not sign without:
Source code ownership. The code you pay for must be yours after completion — explicitly. Some agencies retain copyright, which means you're effectively paying for access to your own system. The clause must read clearly: "All source code created within this project transfers to the client's ownership upon full payment."
Handoff documentation. A system without documentation is a system that keeps you dependent on the supplier. The contract must specify what documentation contains: technical architecture, API description, operational guide, database schema documentation.
Maintenance terms. What happens after launch? Who fixes bugs? At what rate? Within what timeframe? A warranty period for defects (I recommend a minimum of three months) should be explicitly written into the contract.
Escalation mechanism. What happens if the project isn't going to plan? How are disputes resolved? The mechanism should be described before you need it.
Real-world example: Prague-based e-commerce company Modexa.cz commissioned a mobile application from a freelancer with no written contract. The freelancer completed 70% of the project, then became unreachable. The code was written in a way that no other developer could take it over. The loss: 250,000 CZK and six months of time.
Discovery: agencies that skip requirements gathering will fail you
Serious software development begins with requirements analysis — a discovery phase. If a supplier jumps straight to proposing a solution or immediately to development, that's a problem.
What a discovery phase should cover:
- Mapping existing processes (how you do things now and why)
- Identifying the actual users of the system and their needs
- Prioritising features — what is essential for launch, what can come later
- Identifying risks and open questions
- Technical design and rough effort estimates
A discovery phase costs money — expect 10–20% of the overall budget. But the investment pays back: projects with solid analysis statistically overshoot budgets less and generate far fewer conflicts between client and supplier.
Practical tip: If a supplier offers to do discovery for free as part of their sales process, be careful. Either the analysis is superficial (a one-hour workshop isn't enough) or the costs are shifted elsewhere. Quality discovery cannot be done for free.
Freelancer vs. agency vs. in-house: when each makes sense
No option is universally better. It depends on your situation.
| Situation | Recommended choice |
|---|---|
| One-off web application, defined requirements | Senior freelancer or small agency |
| Long-term product, ongoing development | Small or mid-size agency, or in-house team |
| Critical system with complex business logic | Mid-size agency or in-house team |
| Startup, fast MVP, uncertain requirements | Small agency with MVP experience |
| Internal tool for 5 people | Freelancer |
| Project with sensitive data or regulatory requirements | Agency with explicit experience in that domain |
An in-house developer makes sense once you have continuous development in the range of 2,000+ hours per year. Below that volume, an external supplier is almost always cheaper — even if the hourly rate is higher, you don't pay sick days, holidays, hardware, or software licences.
5 questions to ask in every proposal meeting
These questions are effective precisely because there is no clean marketing answer to any of them:
-
"What was your hardest project in the last year, and what went wrong?" — A supplier who claims nothing ever goes wrong is either lying or not taking on complex enough work.
-
"Who specifically will work on our project, and how do you handle cover if they're unavailable?" — You want a name and a CV, not a generic answer about "a team of experienced developers."
-
"How do you handle scope changes that come up during a project?" — Every project changes. You want to know whether they have a defined change management process or whether they deal with it through ad hoc arguments.
-
"What happens when the project is complete and we move to a different supplier?" — The right answer: "We hand over all code, documentation, and access credentials to every system." The wrong answer: hesitation or caveats.
-
"Can you show me an example of the documentation you typically deliver at project handoff?" — Ask for an actual document, not a description of what a hypothetical document might contain.
Red flags: warning signs checklist
If you see three or more of the following with a potential supplier, we recommend looking further:
- Proposal submitted without any questions about the brief
- Unable to explain technical decisions without jargon
- References that cannot be verified
- Contract with no mention of code ownership
- Pricing without itemised breakdown
- Deadline promise without a defined scope
- A different contact person appears in every exchange
- Payment terms demanding a large upfront deposit (over 50%) before analysis
- Negative comments about previous clients
- Refuses to communicate in writing — everything "will be discussed at a meeting"
Real-world example: Jihlava-based manufacturer Kovotechna s.r.o. received a proposal for an ERP system at an unusually low price — roughly a third of the typical market rate. The supplier justified this through "efficient processes and standardised solutions." After signing, it turned out to be a heavily limited adaptation of a foreign off-the-shelf product. Adding any Czech-specific functionality came at extra cost, and the project eventually exceeded the original quote by 180%.
At BASAD Studios
At BASAD Studios, we start every project with a discovery phase — mapping your requirements, your processes, and a technical design — before writing a single line of code. A contract with clear code ownership and a full handoff package is something we treat as standard, not a premium extra. If you're looking for a partner for a web application and want to understand exactly how we approach projects, get in touch or check out our web application service.