Almost every software project starts with a number nobody likes to say out loud: the budget. In most conversations it is the real limiting factor, and no idea is good enough to change that.
The uncomfortable part is something software companies rarely put in writing. Whoever sells you the software earns more from the expensive solution than from the efficient one. That is exactly why this point belongs at the top of the article instead of in the fine print. After it, we get to the two ways we actually finance projects, and to the questions you can use to check any quote you receive, including ours.
The short answer
As a rule, you get a written quote and pay a standard industry hourly rate for the work actually done. If your problem can be solved simply within your budget, then the simple solution is the right one, even when it earns us less. For startups with realistic prospects there is a second route: development is not tied to a fixed hourly rate paid up front, but to a later share of the platform’s revenue or profit. If the product fails, no large development debt is left behind.
The conflict of interest you should know about
Any provider who bills by effort earns more when the project grows. That is not an accusation against the industry, it is simply the arithmetic behind it.
It shows most clearly with clients who have a generous budget. The temptation is to offer the expensive solution rather than the most efficient one. Both would work, both could be justified convincingly, and a client without in-house development knowledge would barely notice the difference.
We are aware of that temptation and deliberately decide against it. Even when it works against our own short-term interest, the first question is what solves your problem most reliably, not what sells best. A quote should be fair to both sides, not just to one.
You do not have to take our word for it. At the end of this article you will find the questions that let you test that claim against a real quote.
Why we look at the whole picture first
Before we talk about features and technology, we want to know what actually gets stuck in your business, what that costs you today, and what you can spend on fixing it. Only those three pieces together produce a sensible scope.
Often it turns out that the problem can be solved within the budget you already have: with a deliberately narrow first version, with an addition to software you are already using, or by automating one single process instead of replacing an entire system. If that is enough, then that is the right solution. Our article on custom software solutions shows what these tightly scoped projects look like in practice.
Should you name your budget at all?
Yes, and early. Without that number you will either get a quote that is too large for you, or one so vague that it does not help you decide anything.
The worry behind the question is still legitimate. Name your budget, and you risk seeing exactly that amount on the invoice regardless of the actual effort. Here is how you can tell that is not what is happening: a good quote ranks the work by effect, makes visible which items can be dropped or postponed, and gives a comprehensible reason for every one of them. We broke down what drives those costs in the first place, using websites as the example, in How much does a website cost?
Route 1: a quote billed at a standard hourly rate
This is the normal case, and for most established businesses it is also the right one. You get a quote with scope and cost before work starts, and the work actually delivered is billed at a standard industry hourly rate.
The advantage for you is control. You know what you are paying for, the result belongs to you, and you are not tied to anyone. The price of that is carrying the development risk alone. If the scope grows during the project, the invoice grows with it. That is why every quote deserves one more question: what happens if something changes along the way?
Route 2: development against a later share of the platform
Startups get a second option, because the usual order of events does not work for them. There is little capital at the beginning, but without an app or a website there is also no revenue that could pay for building one.
So when the prospects of success are good, we can meet you halfway. Development costs are not tied to a fixed hourly rate, but to a later share of the platform’s revenue or profit. In practice that means:
- You do not pay for the development up front in full. Instead, we take a share of what the platform earns later on.
- We take on contractual responsibility for your software, website, or app and support it over the long term in day-to-day operation.
- If the startup works, we stay involved and keep looking after the software.
- If it fails, the obligation to perform ends. No large development debt is left behind.
For you that combines two things that rarely come together: affordable pre-financing during the phase when you are not earning anything yet, and the assurance that someone with a stake in the quality stays responsible for the software. Our article on having an app built describes how such an application comes about and what it asks of you.
For the arrangement to work for both sides, one condition has to hold, and we check it beforehand: realistic prospects of success. This model is the exception rather than the rule, and it always comes out of a case-by-case assessment. The specific terms, meaning how the share is measured and how large it is, how long it runs, and who is responsible for what, belong in writing before the first day of development. Both sides should have them reviewed independently.
What the model does not do matters just as much. It does not take the entrepreneurial risk off your shoulders. It takes the development cost out of the phase in which you are least able to carry it.
The two routes side by side
| Question | Billed by effort | Share of the platform |
|---|---|---|
| When does it fit? | The business has a budget and a clearly defined problem. | A startup has little capital but a product with realistic prospects. |
| What do you pay at the start? | The work actually delivered, at the agreed hourly rate. | Considerably less. The bulk is settled later out of what the platform earns. |
| Who carries the development risk? | You alone. | We carry part of it with you. |
| What happens if it fails? | The work delivered has been paid for. | The obligation to perform ends without leaving a large development debt. |
| What happens after launch? | Support and further development as agreed. | We are contractually responsible for the software long term. |
| How common is it? | The standard case. | The exception, assessed case by case. |
Why we take that risk
Because otherwise good products fail in the wrong place, at the initial financing rather than in the market. Liechtenstein and Switzerland keep producing ideas that would deserve a solid platform, started by founders who cannot pre-finance a full development in their first year.
This is not charity. When a product works, we earn from it over the long run, and that is precisely the incentive to build it well rather than merely fast. We consider that willingness to share the risk the more honest route, compared with handing a young company an invoice it cannot carry at that moment.
Questions worth asking any provider
This list is explicitly aimed at our own quotes too. If a provider cannot answer these clearly, that is the most useful piece of information you can get before signing anything.
- Which item in this quote solves which part of my problem?
- What would you leave out if my budget were a third smaller, and what would I lose along with it?
- Is there a simpler solution than the one you proposed, and why did you decide against it?
- What does running this cost after launch, and who is responsible then?
- What happens to the source code and our data if we stop working together?
- For a revenue share: what exactly is it measured on, how long does it run, and what applies if either side wants out?
The next step: a conversation with a real number in it
Tell us what needs solving and what you can spend on it. Those two things together are enough for an honest first assessment.
We will tell you whether your problem can be solved within that range, which of the two routes realistically fits, and, if neither of them does, that as well. A no at the right moment is worth more to your budget than a project that stalls halfway through.