The list of modules
I go down it as a list to cross things off. Against every line sits the question of whether the first version runs without it. Budgets get settled on those deletions.
Maciej Nuzia · Estimate
Get a preliminary application estimate and see what drives it
Describe the idea in your own words. The tool breaks it into modules and stages, then shows estimated effort and a list of risks. This is a starting point for a budget conversation, not a final quote. The estimate may change after reviewing the data and systems the application has to work with.
Free, and it lives at a separate address: estymacje.softwarelabs.pl. The tool needs an account, and the report comes down as a PDF.
The first number
An early number without a defined scope stays around for too long
Somebody in the room asks for a rough number, and the answer has to come at once. So out comes a figure from the last project, or from a quote somebody saw once. Every conversation from then on circles that figure, though nobody can say what sits underneath it. By the time the scope finally settles, it looks like a budget overrun, and it is the first meeting with a real bill.
- the budget forms around whichever number came first
- there is no way to tell which part of the project to cut to bring the number down
- risks surface mid-build, once the money is already split across quarters
- the board asks for a cost breakdown and gets back “it depends”
Who it is for
You can describe the project, but still need a scope and stage breakdown
What counts is the moment: the idea can already be told in sentences, and nobody has broken it into parts yet. That moment turns up for a single panel and for a system covering a whole department. It catches people in different roles:
- Founders before the first money conversation
- Boards putting a yearly budget together
- Product managers with a list of ideas
- Companies about to choose a vendor
- IT departments costing their own project
- Teams that have been asked what it will cost
The result
What I check in an estimate report
The order of the stages
I read the first stage as a proposed starting scope. I check one thing against it: whether what is left in there closes a whole user route. What a well-trimmed scope looks like is on the page about a web app MVP.
Effort on every line
The figure at the foot of the page catches the eye first, and I compare the proportions between the lines. When one module weighs as much as all the rest together, it runs the project, and the conversation about dates starts there.
The list of risks
I treat each one as a question somebody on your side can answer. Put next to each other, they turn into a list of things to check before anything starts.
The ballpark
The number in the report is an order of magnitude, and it spreads across those same modules. A firm figure needs a closed scope and a conversation about it.
The PDF report
It usually gets opened by somebody who was not there for the typing: a partner, the board, someone from finance. Worth reading once through their eyes before it travels any further.
Who does what
How the report is created and what you can do with it
The tool works from your description and knows nothing about your process, or about the programs your team works in today. Whatever you leave out of the description stays out of the bill.
01
You describe the project in your own words
The questions are about the goal of the app, the main features and who is meant to use it. No technical jargon.
02
The tool takes the description apart
Back comes a list of modules with effort against them, a split into stages, the risks and a report to download.
03
You decide what happens next
You do not have to come back to me with the report, and I will not send a reminder.
04
We go through the report if you want to
I say what the tool could not have known and where these numbers will move most. After that we either settle what goes into the first version, or part ways with the report in your hands.
What moves the bill
What has the greatest effect on the estimate
They come back every time, though never in the same order. Two of them come out too low most often: integrations with systems nobody has looked inside for years, and security. In the systems I have run for years, security is a piece of work of its own in every release, and I cost it the same way in other projects.
- Number of modules
- Integrations
- AI/LLM features
- Roles and permissions
- Security
- Scale and performance
- UX/UI design
- Data migration
- Maintenance and growth
The edges
What a preliminary estimate cannot take into account
The programs already running in your company
The tool never saw them. An app that has to trade data with a system built years ago is not the same job as that app on clear ground. This is the line I correct most often after discovery.
A scope that is still settling
A description typed today is today's version. Every time it gets sharper the numbers move, because only then is there something to count. How close a preliminary breakdown lands to the final bill I cannot tell you, and nobody honest will.
When clicking through it is a waste of your time
Already holding a vendor quote and a closed scope? The breakdown adds nothing to it. When the puzzle is the process itself, start with discovery and leave the form for later.
FAQ
Questions about cost and scope
How much does a web app cost?
It depends on how many separate things have to be built in it, and how many of those have to work in the first version. The tool gives a ballpark for that and spreads it across modules and stages, with the work each one takes. A list like that shows what the money buys and which line can still be crossed out.
What drives the cost of a web app?
Mostly the number of modules and the integrations with systems you already run. The full list of factors sits further up this page. Two of them slip almost everybody's mind in a first conversation: moving the data out of the old system, and keeping the thing alive after launch.
Do I have to pay for the estimate?
No, the tool is free. You do have to set up an account in it: without one there is no way to describe the project or download the report.
Is a report like this enough to order the build?
At this stage it is there to set up a conversation about scope. It is built on your description, with nobody looking at the data or at the systems the app would have to work with, so ordering a build takes more than this. When the puzzle is a process inside the company, discovery on site comes before the build; when it is the first version of a product, the road runs through an MVP.
Can I take this report to another vendor?
You can, and it will not hurt my feelings. The report is not my offer and it ties you to nothing. If you are collecting proposals, so much the better: every vendor gets the same scope to price.
After the report
Already have a report? Let us check what could change the estimate
Send one sentence by email: which line surprised you, and why. That is where I start reading somebody else's report, because that line usually holds the part of the project the description left out.