Powstania Warszawskiego 15
31-539 Kraków
Hourly billing made sense when scoping software was genuinely hard to do upfront. It is not anymore. We scope the project with you, put one number in writing, and build to that number. If the scope does not change, neither does the price, and if the build runs long on our side, that is our cost to absorb.
30 minutes with the founders. No preparation needed.
Why the price does not move
Under an hourly contract, every unclear requirement, every slow week and every "can we also add" lands on your invoice. You find out the real cost of the project at the end, which is exactly when you can do least about it. The supplier carries none of the risk of a vague specification, because the meter simply runs longer.
A fixed price reverses that. If we scope badly, we absorb the difference. That is uncomfortable, and it is why most agencies avoid the model. It only works if the scoping happens properly before anything is signed, which is why our process starts with a written document rather than a number.
The trade is straightforward. You give up the freedom to change your mind constantly. We give up the ability to bill our way out of a mistake. For a defined product with a real deadline, that is a good trade for both sides. For open ended research work, it is not, and we say so on the call.
A scoping call turned into a written document: screens, flows, integrations, and the business rules that decide whether the thing works.
A single quote covering the whole scope, plus a timeline. Nothing added later without your signoff, and nothing folded in quietly.
If the build takes longer than we planned, that is our cost, not yours. That is the actual point of the model rather than a marketing line.
There is no incentive on our side to stretch hours. The incentive is to ship the agreed scope well, because that is what closes the contract.
Defect or change request
Plenty of suppliers say fixed price and then bill for anything inconvenient by calling it a change. The line has to be written down before the work starts, because arguing about it afterwards is what turns a project sour.
Every change request gets its own number and its own timeline impact, agreed in writing before anyone touches the code. You always know what a decision costs before you make it.
What the fixed price covers
The price covers a defined scope built to a defined standard. Anything outside it gets its own quote, agreed before we start, never folded into the number.
Screens, features, backend needs and integrations, documented before you sign anything.
Flutter or React Native, whichever fits the project.
NestJS or Supabase backends, authentication and business logic inside the scope.
Live demos every two weeks, so you see working software instead of a status email.
End to end testing on real devices before anything goes to a store.
App Store and Google Play submission, certificates and provisioning included.
Delivery closes with a signed document, so what counts as done is agreed rather than argued.
Code, credentials and infrastructure are yours, whether you continue with us or not.
Not included: features requested after signoff, third party costs such as store fees and paid APIs, and ongoing work after launch. Each of those is quoted separately.
What it costs
Every quote is specific to your scope, so treat these as the bands most projects fall into rather than a price list. The number moves on scope, integrations and how much of the operation the app has to carry.
A narrow first release built around one core flow, with the rare cases handled manually at first. Usually 8 to 12 weeks.
A complete cross platform product with a backend, accounts, payments or scheduling, and an admin view for your team.
Marketplaces, field service systems and products that integrate with what you already run. Longer scoping, longer build.
The full breakdown of what drives these numbers sits on our mobile app development cost page, and first version pricing by app type is in what an MVP actually costs.
When to walk away
This page exists to sell a way of working, so it is worth being clear about where it does not fit. If any of these describe your situation, an hourly arrangement will serve you better, and we will tell you that on the call rather than after the contract.
How it works
Five stages, and you know at every point what is happening and what it depends on.
You walk us through the operation or the product and the constraints around it. We ask what usually goes wrong in products like yours and tell you what is realistic. No pricing at this stage.
The conversation becomes a document: screens, flows, backend needs, integrations, and the business rules that decide whether people actually use the thing. You see exactly what you would be buying.
One number for the whole scope, with a timeline, the acceptance criteria, and the defect versus change request definition written into the contract rather than left to good faith.
We build against the document with a live demo every two weeks. Your own team uses the app on real work during this stage, which is when the requirements that could not have been written down show up.
Store submission, then a signed acceptance protocol closing delivery. Code, credentials and infrastructure transfer to you. On larger contracts the one year warranty starts here.
Your side of it
Delays on fixed price projects are rarely engineering delays. They come from the client side, and they are predictable enough to plan around, so we would rather name them before the contract than explain them afterwards.
Built this way
Every project below was scoped, quoted and delivered on a fixed price contract.
A technician app where the work timer had to keep counting with the screen locked and during a call placed from inside the app. That requirement only appeared once crews used it on real jobs.
MarketplaceA two sided marketplace built in Flutter and Supabase, with the matching logic, the payment flow and the App Store review questions that come with any marketplace product.
BookingA booking and training product where trainers ran real sessions with their own clients before public launch, which is the point where a schedule stops being a set of screens.
From the founder
"A business needs a predictable outcome. You want to know exactly what you are paying for and what you get on the other end of that spend. That is why we work fixed price, and why the scoping call happens before any number does."
Why the number holds
Saying fixed price is easy. These are the parts that decide whether the number survives contact with the project.
Thomas and Kamil run the scoping call. The people accountable for the number are the ones who set it.
The quote is a document with acceptance criteria, not a verbal estimate. What you sign is what you pay.
If the idea is too large for the budget, you hear it before you pay, together with what a smaller first version would look like.
Two week sprints with live demos, so you are watching the build rather than reading about it.
Written scope, acceptance protocol, warranty terms. The same shape of paperwork as buying a machine or a fit out.
Code, credentials and infrastructure transfer at handover, whichever way the relationship goes afterwards.
FAQ
The answers we give on the phone, written down so you can compare them with what other suppliers tell you.
Read before you buy
Written for people about to commission a build, not for developers.
Related services
Fixed price applies across everything we build. Here is the rest of it.
Cross platform apps for iOS and Android from a single codebase.
A React Native team built for US founders and scaling companies.
From idea to App Store in 8 to 12 weeks, fixed price.
Scheduling, job reporting and offline work for operational teams.
Two sided products, matching logic and payment flows.
Nearshore delivery for clients in the US and Western Europe.
Describe how the work runs today and what it costs you. You get a straight answer on what belongs in version one, what it would take, and a written scope with a fixed price before anything is built.
30 minutes with the founders. No preparation needed.