{"id":1258,"date":"2026-02-13T16:47:11","date_gmt":"2026-02-13T15:47:11","guid":{"rendered":"https:\/\/jsoncrew.com\/?p=1258"},"modified":"2026-09-08T18:53:20","modified_gmt":"2026-09-08T16:53:20","slug":"sposoby-rozliczenia-projektu-it","status":"publish","type":"post","link":"https:\/\/jsoncrew.com\/en\/2026\/02\/13\/sposoby-rozliczenia-projektu-it\/","title":{"rendered":"Project Billing Methods with a Software House: Fixed Price, T&M, Package, and Subscription \u2013 Which to Choose (and What About Code Ownership)"},"content":{"rendered":"

You sign a contract for the application. You pay. And then it turns out that you don't know if the code is yours.<\/strong> Or that you add more every month because \u201ea little more hours came out.\u201d Familiar? How to settle is not just a question of budget.<\/strong> It's a decision about who owns what and how you pay for the changes.<\/p>\n

In this text: fixed price, time and material, bundled billing<\/strong> (as an expansion of fixed after MVP) and subscription.<\/strong> Plus what provide in the agreement<\/strong>so that non-contract models include full copyright transfer<\/strong>, and with a subscription, know that you are buying licensed access<\/strong>, not ownership.<\/p>\n

\"\"<\/figure>\n

Fixed price, a fixed price for a defined scope<\/h2>\n

<\/p>\n

\n
NEWSLETTER<\/div>\n

One email with a concrete point each week.<\/h3>\n

AI, B2B sales, and implementations. No spam, unsubscribe with one click.<\/p>\n

Sign up<\/a>\n<\/div>\n

Fixed price<\/strong> means: you set the scope (specification, list of features), software house prices the whole thing and you pay a fixed amount<\/strong> for delivering this scope of work. The budget is known in advance. The risk of cost overruns falls on the contractor; if something goes wrong, they\u2019re the ones who end up paying the difference, not you.<\/p>\n

Example from life:<\/strong> A chain of three hair salons needed an online booking system. Instead of simply saying, \u201cWe want a booking app,\u201d they sat down with the developer and described: 6 screens<\/strong> (salon selection, date, time, service, customer data, confirmation), confirmation e-mail<\/strong>, simple panel<\/strong> With a list of reservations for today and tomorrow. Specifications for 4 pages. Pricing: PLN 45,000<\/strong>, delivery in 10 weeks<\/strong>. The customer knew how much he would spend and when he would get the product. No surprises in the bill.<\/p>\n

A reverse example:<\/strong> If the same client had come in saying, \u201cI want a booking app\u201d without providing any specifics, the developer would have either rejected the fixed-price quote (too high a risk) or quoted a high price \u201cjust to be safe.\u201d Or, after three months, it might turn out that the \u201cfranchise panel\u201d consists of 20 screens, not 2, and annex, surcharge.<\/strong> Therefore, fixed requires clarification at the start.<\/strong><\/p>\n

Minus:<\/strong> Changing scope during = usually an addendum and surcharge. That's why fixed price often goes hand in hand with MVP:<\/strong> First you make a minimal (fixed) version, then you expand.<\/p>\n

In the contract NECESSARY:<\/strong> full copyright transfer<\/strong> to the code and all creations of the project to you (or your company). Not an \u201eexclusive license,\u201d but an transfer<\/strong>, then the product becomes your property. I know of a case where the contract specified \u201ctransfer of rights upon full payment.\u201d The customer paid the final installment, and only then did they receive written confirmation that the code and documentation were being transferred to them. Without this provision, he could only \u201euse,\u201d not sell or transfer the project.<\/strong> This is no small thing.<\/p>\n

\"\"<\/figure>\n

Time and materials (T&M): you pay for the time<\/h2>\n

Time and materials<\/strong> is billing for actual hours (or days) worked. Flexible: you can reprioritize, add features, cut scope on the fly. Ideal<\/strong>, when requirements are fluid or you are just testing an idea and don't want to lock yourself into a rigid specification.<\/p>\n

Example from life:<\/strong> Startup with an idea for Marketplace connecting contractors with customers<\/strong> In a niche industry. It wasn't clear at the start: whether payments should be made right away, or just \u201einquiries\u201d to begin with; whether the panel for contractors should come first, or the landing for customers. They agreed with SH T&M with a cap of 120 hours for the first 2 months<\/strong> and weekly sync's. After 6 weeks, we found that customers were more likely to fill out an \u201einquire\u201d form than to register - have shifted priority<\/strong> for notifications and a simple CRM for inquiries. If it were fixed, they would have to add an addendum. With T&M, they simply changed the backlog. Bill for 2 months: about 110 hr.<\/strong>, within the scope of the CAP, the product in the hands of users.<\/p>\n

Minus: No rigid cost ceiling.<\/strong> Without good communication and oversight, bills can spiral out of control. Another customer, without a cap or a monthly review, found themselves with bills totaling 3\u00d7 more<\/strong>, than he assumed. It is worth determining, for example. monthly limit of hours<\/strong> or \u201ecap\u201d per phase and keep an eye on reports<\/strong> (what was done, how many hours).<\/p>\n

In the contract same as with fixed:<\/strong> full copyright transfer<\/strong> to the code and materials produced for the client. You pay for the work, and the end result is to be your property.<\/p>\n

\"\"<\/figure>\n

Fixed-price package pricing based on MVP, for a package of enhancements<\/h2>\n

Packaged<\/strong> in practice Developing fixed price after MVP.<\/strong> You already have a working product (e.g., an MVP). Instead of opening a big \u201ephase 2\u2033 with no end in sight, you establish a enhancement packages:<\/strong> For example, \u201ePackage A: admin panel + reports\u201d, \u201ePackage B: integration with payments\u201d. For each package -. fixed price<\/strong>, clear scope, predictable budget.<\/p>\n

Example from life:<\/strong> Owner booking apps for small practices<\/strong> (cosmetics, physiotherapy) had an MVP: booking form, calendar, confirmation email. It worked -. approx. 200 bookings per month<\/strong> In the first 3 months. Instead of \u201elet's do everything now,\u201d they agreed with SH packages:<\/strong><\/p>\n