Too Long; Didn't Read · 30 SECONDS
- 62% of IT budget overruns This is a common pitfall (PMI 2025). 50% of IT projects encounter it at some point. The most common cause: failure to define the SOW before signing the contract.
- Seven red flags in price lists and contracts: a fixed price with no scope defined, a proprietary framework (vendor lock-in), no buffer in the quote, a template-based assessment phase, no code transfer after launch, a senior rate for junior work, and an inappropriate IP clause.
- Key questions to ask before signing: Who owns the copyright, where the repositories will be hosted, who specifically is working on this (names, not roles), what is outside the scope, and what are the terms for terminating the contract.
- Four signs that you're already being ripped off: invoices for changes made before the first milestone, repositories in the agency’s account, no working prototype after four weeks, requirements documents in PowerPoint instead of Figma, and no binding scope document.
Statement of Work (SOW) vs. Contract. Two different documents. The contract provides the legal framework (who, when, how much, penalties, IP, termination). The SOW defines the scope of work (exactly what is being developed, what integrations are required, and what acceptance criteria apply). 90% of the pitfalls stem from the fact that the SOW is “indicative” or doesn’t exist at all. Without an SOW, every change during the project results in an additional invoice.
The founder sits down to issue an invoice after six months into the project. Base contract amount: 80,00PLN 0. Monthly invoice: another 12,00PLN 0 for “items outside the scope.” In total, the project has already cost 140,00PLN 0. The code has been delivered, but the documentation consists of a README file with three lines of text. Hosting is on the agency’s account, and the API keys are in their password manager. The founder sends an email requesting a transfer. The agency replies that the transfer costs an additional 8,000.
You know the feeling. Disbelief, frustration, helplessness. Because the contract looked standard, the provider seemed professional, and the offer sounded fair. And now you’re looking at the invoice and can’t remember when you agreed to pay extra for the transfer of your own code.
Three customers in 12 months
Sound far-fetched? This describes three clients who came to us over the past 12 months. Each of them had already paid for a first draft from someone else, believing that the contract they signed was “standard.” They were all wrong.
Who's really ripping you off?
The software company won't rip you off. You're signing a contract that lets him rip you off laterThe difference lies in which contract you read before signing.
Clauses that look like standard terms but aren't
The worst clauses aren’t written in 6-point font in the legal disclaimer. They’re written in 12-point font, look like industry standards, and appear in 80% of IT contracts. They aren’t standards. They are a map of the minefield spread out over the 12 months of the project. Each clause is a landmine that goes off in a different month if you don’t spot it before signing.
What you'll find in this article
We have implemented configurators and client dashboards for dozens of B2B compaNos in Poland. Most of them came to us after their first, unsuccessful collaboration. We have a map of the areas where their previous agency shortchanged them. These areas are predictable and recurring. You can spot them in the proposal, and you can spot them in the contract.
The text shows 7 red flags in price lists and contracts with Software House Plus 5 questionsquestions you should ask every supplier before signing, plus 4 signs that the project is already running behind schedule (if the contract has been signed, but it’s not too late to cancel it).
|
After the first unsuccessful collaboration? A 30-minute diagnostic call. We’ll go over your current contract and a list of questions for your next provider. No slides, no sales pitch. |
Fill out the form |
Why are these 7 flags easy to miss in the selection?
Because they all look like the industry standard. The salesperson will say, “That’s how we always do it,” and you’ll think, “If they always do it that way, it must be okay.” In reality, the industry standard in Poland favors the agency, not the client. This isn’t a conspiracy; it’s a consequence of the fact that agencies have more projects than clients, so they dictate the terms. A similar mechanism occurs with Customer Relationship Management implementations, where 70% of failed implementations fail due to a lack of user acceptance. We’ve described this in a separate article Why Customer Relationship Management implementations fail.
Second thing: most of the clauses that will come back to bite you in six months sound harmless when you sign the contract. “IP ownership remains with the contraCTOr until full payment” looks like a formality. In reality, it means the vendor owns the rights to the code and can resell it. “Scope changes will be billed separately” looks like fair play. In reality, it means that every change to the product you consider a clarification results in an additional invoice for the agency.
Third: time pressure. The agency tells you, “The decision has to be made this week; we’re booking the team.” The client doesn’t have time for a second lawyer, a second opinion, or due diligence. They sign under pressure. Artificially created time pressure is a red flag in itself, but we’re not writing about her today, because that would make it the eighth one.
Seven red flags in contracts and price lists
Red flag #1. “Fixed price, approximate scope”
A classic spricerio in the Polish IT industry: a vendor quotes a price of 80,00PLN 0 after a 30-minute conversation. No defined Statement of Work (SOW), no list of specific screens, integrations, or acceptance criteria. Any change during the project = an extra charge at the hourly rate.
Hard evidence: according to Project Management Institute 2025 62% of budget overruns in IT projects are due to scope creep. 50% of IT projects encounter this problem along the way. The main reason: the lack of a defined SOW before signing.
Reframe: A fixed price without a Statement of Work (SOW) isn’t a contract—it’s an invitation to negotiate during the project. If a vendor refuses to include specific details in the contract, it means one of two things: either they don’t know what they’ll be doing (quality risk), or they do know and are intentionally leaving room for additional invoices (budget risk). We’ve outlined realistic price ranges for an MVP in a separate article: How much will a web application cost in 2026?. That figure is the baseline against which you compare every given price.
What to ask: “Can we add an SOW appendix to the contract that includes a list of features, screens, and acceptance criteria, as well as a definition of the change procedure?” If the answer is “we don’t do that” or “it’s too much red tape,” then the first pitfall has been concompaNosed.
Red flag #2. “We have our own CMS, our own framework, our own platform”
The vendor builds on its own framework, which no one outside their team is familiar with. It sounds like an advantage (“we have a ready-made solution, so it’s faster”). In reality, it’s a classic case of vendor lock-in—a situation where the client cannot switch vendors without incurring excessive costs.
Polish legal context: Vendor lock-in is described in Polish IT practice (law compaNoss RPMS, BCLA). This occurs when the customer does not have operational access to the source code, technical documentation, or administrative tools. Resolving this situation costs more than having the application rewritten from scratch by a new provider.
Reframe: An agency’s custom framework is the agency’s asset, not yours. The standard tech stack (React, Next.js, Node.js, Postgres, Python with Django) is used by 100,000 developers in Poland. Agency X’s custom framework is used by 8 developers, all of whom work for Agency X.
What to ask: “What tech stack do you use? Do you use your own libraries or public ones? Who else besides you would be able to maintain this code in two years?” If the answer is “our framework is better because it’s custom-built,” it’s like a ticking time bomb.
Red flag #3. “Valuation = offer” (no buffer in the valuation)
The supplier estimates 80 hours of work and quotes 80 hours at a rate of 25PLN 0 in the proposal. Final price: 20,00PLN 0. It looks straightforward and sounds fair. The catch is that no buffer means no leeway for the unexpected.
In an IT project, the unexpected is the norm. The client changes a single requirement, a legal regulation changes, or integration turns out to be more difficult than anticipated. Without a buffer, the vendor has two options: accept the loss (and deliver the bare minimum just to finish), or charge for each change at an hourly rate (at a price 1.5–2 times higher than the original quote).
Reframe: A realistic estimate is the base figure plus a 20–30% buffer for the unexpected. Without a buffer, the supplier will either deliver the bare minimum or charge you extra after the fact. The third option—where the supplier absorbs the loss and delivers excellent quality without any additional charges—happens less often than you might think.
What to ask: “What kind of buffer do you build into your estimate for the unexpected? And what happens if the scope changes by 10% along the way?” The answer “we don’t build in a buffer; we’re precise” is a red flag, not a strength.
Red flag #4. “The research phase? We’ve got a template ready.”
The initial consultation—or the scoping phase—is the foundation of every IT project. It defines exactly what will be developed, what the edge cases are, what integrations are required, and what regulations apply. The actual scoping phase lasts 1–2 weeks and costs 5,000–15,00PLN 0 for an average project.
Some agencies market the initial consultation as “free” or “included.” It looks like a bonus for the client. In reality, it means they use a template from a previous project, change the names, add the client’s logo, and present it as “research output.” The edge cases in your industry haven’t been explored. The first few weeks after signing the contract = the client is paying for the agency to learn about their business.
Reframe: A generic initial interview is a red flag, not an advantage. A proper assessment phase yeses time and costs money. That cost pays for itself fivefold over the course of the project, because you avoid costly changes along the way.
What to ask: “Show me the flowchart for a previous project in our industry. What edge cases did you identify?” If the flowchart is a general description like “the user logs in, selects a product, and receives an offer,” that’s not a flowchart—it’s a description of any application.
Red Flag #5. “Once production starts, you’re in our hands”
Hosting on the agency’s account, repositories on their GitHub, API keys in their password manager, SSL certificates in their control panel. The client has a link to the production environment, and that’s it. Every change, every update, and every bug fix requires a request to the agency.
Polish legal context: A clause regarding the transfer of source code, documentation, and credentials (hosting, domains, certificates, API keys) must be explicitly included in the contract. Without it, the provider has the right to retain operational control even after payment has been made. Polish copyright law does not automatically transfer rights and does not compel the provider to hand over production environments without an explicit clause.
Reframe: Without the transfer of code and environments, you haven’t actually purchased the application. You’ve purchased a subscription to a software development company’s service, where the product is physically hosted by them. The agency can raise the maintenance fee by 50% in the second year, and you have no alternative without rewriting the code from scratch.
What to ask: “Will the repository be on our GitHub/GitLab account starting on the 1st? Where are the API keys and hosting passwords stored during the project? After paying the final invoice, will we receive a complete dump of the code, documentation, and credentials?”
Red Flag #6. “Senior-level pay in the job posting, junior-level work on the actual project”
The agency charges a rate of 250–30PLN 0 per hour, describing the team as “mid-senior.” In reality, a junior works with a senior consultant once a week (on an hourly basis, in a 1:1 meeting). The client sees slow delivery, low-quality code, and bugs, while the agency earns a 60% margin instead of the standard 30–40% (because it pays the junior 7PLN 0/h and charges 28PLN 0/hour).
This is a common practice. The contract usually doesn’t specify who will be working on the project or how many hours the senior and junior developers will each work. The agency lists role titles instead of individual names in the proposal. “Senior Backend Developer (200 hours)” looks professional. In reality, it means “someone from the team who will be assigned to the project, most likely a junior developer with a weekly code review by a senior developer.”
Reframe: Ask about the names, years of experience, daily availability, and assigned hours of the people listed in the offer. Not roles, not titles, not “senior backend.” Specific people with specific hours.
What to ask: “Who exactly is working on the project? First name, last name, years of experience with the tech stack, and how many hours per week will they dedicate to our project?” If the answer is “We’ll assign someone after the contract is signed; we have a pool of resources,” stop the negotiations and keep looking.
Red Flag #7. “IP Clause? Standard”
The worst contractual clause in the Polish IT industry goes something like this: “Copyright to the code remains with the contraCTOr until full payment is made.” It seems like standard practice. The client pays, the rights are transferred, and that’s the end of it.
Polish legal context: Under Polish law, copyrights are not automatically transferred. They require an explicit clause stating “transfer of economic copyrights to the client for all fields of exploitation,” along with a list of those fields (distribution, modification, sublicensing, commercial use). Without this complete provision, the client holds only a license, not ownership.
Consequences of Failure to Transfer Copyright
You paid 50,00PLN 0 for the app, but technically you only have a license to use it. The provider can sell the code to another client (if they generalize it), retain the rights to publish it as a case study, or use parts of it in other projects. Your competitor could buy a very similar app from the Same agency for 60% of what you paid, because they’re building on your work.
What to ask: “Does the contract include a clause transferring the economic copyrights to us, across all fields of exploitation, upon payment of the final invoice? Does the contract prohibit the use of code snippets in projects for other clients without our consent?” If there is no “transfer” clause, halt negotiations.
| Contract provision | ✗ Dangerous version (red flag) | ✓ Client-side version |
| Scope of work | "Development of a web application that meets the client's requirements" | SOW Appendix: List of screens, integrations, and acceptance criteria |
| Change Procedure | "Overtime will be billed at an hourly rate" | Written procedure: change request, estimate, client approval prior to execution |
| Copyright | "The IP remains with the contraCTOr until full payment is made" | “Transfer of economic copyrights to the client for all fields of exploitation upon payment of the final invoice” |
| Code and environment migration | "Once the project is complete, the client gains access to production" | Repositories in the client's account starting on the 1st, API keys in their password manager, and a documentation dump within 7 days of the last invoice |
| Band | "Mid-senior backend developer, 200 hours" | Specific names with years of experience, daily availability, and assigned hours |
| Dateation of the contract | “The parties may terminate the agreement by mutual consent” | The customer may terminate the contract with 30 days' notice; the provider will provide the code and documentation within 7 days; unpaid hours will be calculated based on the records |
| Liability | “The contraCTOr is not liable for damages” | Limited liability up to the contract amount, plus a 12-month quality guarantee clause |
Four signs that a project is already falling behind schedule
If the contract has been signed and these red flags are already present, don’t panic, but put the project on hold for 48 hours and consult with an IT lawyer. Each of these issues can be resolved within the first 90 days. After 90 days, the cost of fixing them doubles every month.
- Invoices for changes are issued before the first milestone. The agency should focus on the core scope of work during the first 4–6 weeks. If an invoice for “additional work” appears as early as the 2nd or 3rd week, it means the SOW was vague and a pattern of adding extra charges is emerging.
- The repositories are in the agency's account, not yours. If, two weeks after the project kickoff, you log in to GitHub and see the vendor’s organization instead of yours, it will be difficult to hand over the code after launch.
- No working prototype after 4 weeks. Every week you get an agenda slide, a progress slide, but there's no URL where you can go and see the product. Real projects have a working prototype (even an incomplete one) in the 3-4th week.
- The initial meeting output is a PowerPoint presentation, not a Figma file plus a document. A proper initial meeting produces three things: clickable Figma mockups, a binding scope document (feature list, acceptance criteria, edge cases), and a list of technical requirements (technology stack, integrations, infrastructure). A PowerPoint presentation with general information is no substitute for any of these.
Five questions you need to ask every agency BEFORE you sign
These questions do not require knowledge of the law. They require a specific, written response before signing the contract. If the agency refuses to respond in writing (“we will discuss it during”). this is the seventh red flag.
QUESTION 1
Who owns the copyright?
It should read: To you, upon payment of the last invoice, in all fields of use.
QUESTION 2
Where are the repositories hosted?
It should be: in your GitHub/GitLab account from day 1, the agency has permissions as a collaborator.
QUESTION 3
Who exactly is working?
It should include: first name, last name, years of experience, and hours assigned per week. Not job titles.
QUESTION 4
What exactly does the SOW cover?
It should include: a list of screens, integrations, acceptance criteria, plus a written procedure for scope changes.
QUESTION 5
What are the terms of termination?
It should be: 30 days' notice, transfer of code and documentation within 7 days, hourly billing based on time records.
What We DON'T Do at JSON Crew (and Why It's Good for You)
After four years in business, we’ve seen that generalist agencies that “do it all” are either lacking in every area, or expensive in every area, or both. We’ve chosen a different path: niche specialization in the digital transformation of B2B sales.
What we do
- Product configurators (Three.js, dedicated pricing rule engines)
- Customer dashboards and listing portals
- IoT Dashboards (energy, manufacturing, smart home)
- Sales automation (Customer Relationship Management, quoting, ERP integrations)
- We are expanding our services for existing customers JSON Hub (our SaaS product that combines Customer Relationship Management, quoting, project management, and a configurator into a single ecosystem)
What we DON'T do
- Social media platforms
- Games and gaming software
- General-purpose SaaS platforms without a clear use case
- Shopify or WooCommerce stores
- Blockchain and cryptocurrency projects
- AI startups without a defined business problem
Each of these areas requires specialized expertise that we do not possess in-house. We refer projects that we realistically cannot execute better than a specialized competitor.
What is typically included in our contracts
- SOW Appendix containing a list of features, integrations, and acceptance criteria
- Written procedure for scope changes (request, estimate, client approval)
- Transfer of economic copyrights to the client for all fields of exploitation upon payment of the final invoice
- Repositories in the customer's account as of the 1st
- Public stack (React, Next.js, Node.js, Postgres, Python with Django). No custom framework
- Specific team names in the offer with assigned hours
- 30-day notice period with transfer of code and documentation within 7 days
If any of these points pose a problem for you (e.g., you don’t want a GitHub account or prefer that we host it), we’ll negotiate an exception in writing. By default, these safeguards are designed with the customer in mind. If you’re building a B2B product configurator, a customer dashboard, an IoT dashboard, or sales automation, this is exactly what we specialize in. And if your idea falls outside this scope, we’d be happy to refer you to a trusted competitor.
What's next? Start by discussing the contract, not the price list.
The price list in your current offer is a guide, not a cost estimate. Your specific contract has its own scope, context, clauses, and pitfalls. To truly understand what you're signing, you'll need a 30-minute conversation about the current offer or the contract you're considering.
Good news: A contract doesn’t have to be a minefield. It can serve as a safeguard. The Same seven red flags that catch some customers off guard are, for others, simply a list of questions they asked during their second meeting with the supplier. The difference lies in whether you knew what to look for before signing.
The diagnostic consultation is free and doesn't involve any slides. You'll walk away with three things: list of red flags in your current offer (if you already have one), a list of questions for the supplier before signing (if you're still negotiating), and a checklist of what MUST be included in the contract so you don't end up with invoices for scope creep a year down the line.
If it turns out that we’re a good fit for you, we’ll explain how we work. Otherwise, you’ll receive a checklist and save yourself six months of lessons by working on your own project.
OPTION 1 · DIAGNOSTIC CONSULTATION
Let's talk about your contract, not our price list
30 minutesuteses. No slides, no sales pitch. You’ll walk out with a list of red flags and questions for the vendor.
OPTION 2 · CHOOSING A SUPPLIER
How to Choose a Software Development Company After a Bad Experience
7 Questions to Ask Before Signing a Contract, Plus 7 Red Flags: A Guide for Founders After Their First Failed Partnership.
Frequently Asked Questions About Contracts with Software Development CompaNos
Questions about scope and price
What does "red flag" mean in a contract with a software development company?
A red flag is a clause or pattern in a proposal or contract that appears to be an industry standard but actually works to your disadvantage. Examples include: a lack of a defined SOW, the vendor’s proprietary framework, no code transfer after the production launch, and an IP clause that does not transfer copyright. These aren’t traps in the illegal sense (they’re found in 80% of IT contracts), but they are traps in the economic sense—they cost the client 1.5–2 times more than the original quote.
Why is the "fixed" price in a contract usually not fixed?
Because the price is only fixed for a defined scope (SOW). Without an SOW, any change during the project is “out of scope” and is billed at an hourly rate. PMI 2025 reports that 62% of IT budget overruns are due to scope creep, and 50% of IT projects experience it during the project. A realistic “fixed-price” contract includes an SOW appendix with a list of features, integrations, acceptance criteria, and a written procedure for scope changes.
Questions about IP and source code
Does copyright to the code automatically transfer upon payment?
No. Under Polish law, economic copyrights are not automatically transferred. They require an explicit clause stating “transfer of economic copyrights to the client for all fields of exploitation,” along with a list of those fields (modification, distribution, sublicensing, commercial use, publication). Without this full provision, the client has only a license to use the work, not ownership. A Polish law compaNos specializing in IT (RPMS, BCLA) concompaNoss this in public analyses.
What is vendor lock-in, and how can you avoid it?
Vendor lock-in is a situation in which a client cannot switch providers without incurring excessive costs (typically 1.5–2 times the cost of the original project). It occurs when a provider builds on its own framework, keeps the code in its own repository, and hosts it on its own account. This avoid this: use a standard stack (React, Node.js, Postgres), keep repositories on the client’s account from day one, and include a clause requiring the transfer of all credentials (API keys, passwords, certificates) within 7 days of the final invoice.
Questions about the team and delivery
Why should the list include the names of the team members rather than the job titles?
Because the job title “mid-senior backend developer 200h” in the job posting doesn’t obligate the agency to assign a specific person. After signing the contract, the agency can assign a junior developer who consults with a senior developer once a week. The rate is that of a senior developer (250–30PLN 0/h), but in reality, a junior developer is doing the work (agency cost: 7PLN 0/h). A 60% margin instead of the standard 30%. The client sees slow delivery and low-quality code. Ask for names, years of experience with the tech stack, and the hours allocated weekly to your project.
How long should it yese to have a working prototype in the project?
Real projects have a working prototype (production or staging URL) within 3–4 weeks of the project kickoff, even if the prototype covers only a single user flow. The absence of a prototype after 4 weeks is a red flag. A weekly agenda slide without a working application is a second warning sign. If both are present, pause the project for 48 hours and consult with an IT lawyer before issuing the next invoice.
About the author. Jędrzej Siewierski. CEO and co-founder of JSON Crew. He evaluates product configurators, customer dashboards, IoT dashboards, and sales automation solutions for B2B compaNos in Poland, Germany, and the United Kingdom. Under a standard JSON Crew contract, the code, documentation, and hosting are transferred to the client upon payment of the final invoice; the repositories are in the client’s account from day 1, and the stack is public (React, Next.js, Node.js, Postgres). More about the author · LinkedIn
