The most honest answer to a fair question
“What will it cost?” is the first question in almost every introductory call, and it's a fair one. Anyone planning a software project needs a budget, and anyone approving a budget wants to know what it's for.
But at the start, the honest answer is: nobody knows yet. A two-page project idea can be implemented in very different ways, with very different effort. A quote at this stage is either padded with generous reserves or turns out to be wrong later. Either way, you pay for the uncertainty.
That's why every project with us starts with a Discovery Sprint: a paid, clearly scoped phase of one to three weeks in which we work out together what should be built. Without discovery, every estimate is speculation.
format_quoteThese questions don't slow you down. They make sure the speed that follows actually counts.
Stefan Hess
What we clarify in those weeks
We don't start with technical questions. We start with business ones. What problem are we actually solving? For whom? And how will we know it's solved?
Then we look at how work gets done today: which processes exist, where the exceptions are, which lists are kept outside the existing systems. We check which systems and data are already in place and which ones the new software has to work with. And we figure out which parts are better covered by off-the-shelf software.
What we leave out matters just as much. Most requirement lists are too long. Part of discovery is deciding together what belongs in the first version and what can wait.
What you have in hand at the end
At the end of the sprint, you get three things: a requirements document describing what the software should do; an architecture sketch showing how it's structured and how it fits with your existing systems; and a reliable estimate of effort and time for the main phase.
These results are yours. If you decide not to continue with us — or not to continue at all — you still keep them. They're valuable either way: as the basis for a quote from another provider, for an internal decision, or for the realization that the project isn't worth it in this form. That's a good outcome too, if it comes after three weeks instead of a year.
A filter for both sides
The Discovery Sprint is also a test of working together. During those weeks, you see how we work, how we ask questions and whether our style fits your organization. We find out whether we're the right partner for your project. Afterward, both sides decide based on actual work together rather than a sales pitch.
That's why we don't take on projects without a Discovery Sprint first. Not on principle, but because we've seen what happens when this step is skipped: you build fast, and part of it goes in the wrong direction. Building the wrong thing fast isn't fast.




