Guide
How much the first version of a product costs, and what drives the price
You will not find price ranges here. Instead I describe what drives the cost of a first version, what lowers it without harming the product, and how billing protects you from running out of money with no product to show.
Why there are no price ranges here
The ranges you will find elsewhere are so wide they tell you nothing. All they do is put the money conversation before the product conversation.
I prefer the other way round. First we write down what the first version should do, then you get prices in writing, separately for each part. Then you see what you are paying for and can take something out before we start.
What drives the cost
The number of user roles. A product with one type of customer is cheaper than one with customers, suppliers and an administrator, each seeing something different.
A two-sided market. A platform that connects two sides needs screens for both, matching, and communication between them. That is usually two products in one.
Payments. A one-off payment is the simplest case. A subscription with trial periods, plan changes and refunds takes more work.
External data. A product that pulls data from registers, portals or devices has to fetch it, check it and refresh it. Each source is separate work and a separate thing that can break.
Browser or app stores. A product in the browser works everywhere at once. An app in the stores is a separate version for each platform and waiting for store approval.
Languages. Each language means translating screens, emails, documents and invoices.
Legal requirements. Financial and medical products, and any that store sensitive data, have extra requirements to meet. That is work you cannot see on screen, but without it you cannot sell.
What lowers the cost without harming the product
- One thing end to end. Products that build ten features to 60 percent lose a lot of money. One customer path built in full costs less and sells straight away.
- A ready-made payment provider. Stripe, Przelewy24 or Paynow handle cards, transfers and local methods. There is no reason to build that yourself.
- Browser instead of app stores. One version instead of three. The stores come when customers ask for them.
- One language at the start. The second is added when customers from another country really arrive.
- Ready-made parts where they are not the core. Email delivery, login, invoicing. I build from scratch only what the customer pays for.
How billing works
I split the product into modules, meaning self-contained parts: accounts, payments, the core, the admin panel. Each has its own price in writing and its own stage in the schedule. You pay for a stage after accepting it, usually at month end.
So you do not pay up front for something that does not exist yet. You see a working part, click through it, accept it, and then the invoice comes. If something does not work as we agreed, I fix it before acceptance.
I bill every system this way, not only products. More on what drives the cost of software built for a company is in the guide on custom software.
Costs after launch
The build is not the only expense. Before launch you know every recurring item:
- Server and domain. The amount depends on traffic and you know it before launch. The contract is in your name.
- Payment provider fees. A percentage of each transaction, according to the provider’s price list, which you see before choosing.
- Email delivery. With thousands of customers, the email sending service charges by the number of messages.
- Care for the product. From occasional changes to ongoing care. We agree that after launch, once it is clear how many changes are really needed.
What if the money runs out halfway
Because it happens: the investor pulls out, sales at the company slow down, priorities change. With billing per stage you keep what you have accepted: working accounts, payments and part of the core, with the code, documentation and credentials. It can be shown to the next investor and finished with anyone.
That is why I order the modules so the path from arriving to paying exists as early as possible. A product that can take money at the end of month two is worth more than one that has beautiful screens and no payments after four months.
How to build a first version and what belongs in it is on the main page of the guide and on the page what the first version must have. How to choose a developer and what to ask about billing is on the page how to choose a developer.
Describe in the form below what your product should do and what the customer pays for. I will get back to you, and after the call you will get the scope of the first version with prices in writing.
Questions and answers
Why no price ranges?
Because the first version of a report sold as a one-off and the first version of a two-sided platform with chat differ several times over in the amount of work, and both go by the same name. A range on the site would either scare off the smaller project or mislead the larger one. After the first call you get prices in writing.
Do I pay up front?
No. You pay for a stage after accepting it, usually monthly. Before the start we write down the scope and the price of the first version, so you know what you are agreeing to, but the money follows working results.
What costs come after the start of sales?
Server and domain, the payment provider's fee on each transaction, possibly email delivery fees with a large customer base, and care for the product if you want it. You know all of these before launch.
Contact
Describe your product and after the call you will get the scope of a first version with prices in writing
You do not need a specification. Describe how the work looks today and what should change. We will write the scope together.