First we work out what we are solving, then we build.
An app is the most expensive item on the list and the easiest one to get wrong. So there is no fixed price here before the scope is known, and the first step is a paid discovery rather than a quote.
Who it is for
When an app makes sense.
Worth it if
- You have a process that eats hours every day and lives in spreadsheets, messages and somebody's head.
- You know what that process costs you per month, so the investment has something to be measured against.
- You are ready to pay for discovery and to accept an answer that says you do not need an app.
Not worth it if
- You want a fixed price before anyone knows what the app actually does.
- The idea is still in one person's head and changes every week. That needs to settle before anything gets built.
- An off the shelf tool already does it for a monthly fee. Taking that is almost always cheaper.
The problem
Three signs the work runs outside any system.
The spreadsheet became the system
It started as a list and now the whole operation sits on it. Nobody may touch it while someone else has it open, and nobody remembers why one column is red.
The same detail in three places
The order is in an inbox, the stock in a spreadsheet, the deadline in a chat. Change it in one and the other two stay wrong until somebody notices.
One person knows everything
When that person takes leave, the work slows down. That is not a problem with the person. It is a sign the process was never written down.
Honestly
Do you even need an app?
These are the three questions I ask in the first conversation. A large share of these enquiries end up solved by a site or a panel, and that is a better outcome than an app nobody opens afterwards.
Is it for you or for your visitors?
If you use the tool internally, and the work arrives through enquiries and orders from the site anyway, a panel over what you already have is usually enough.
Instead of thatAn admin panel on the existing site, for a fraction of the price.
Does a ready made tool already do it?
Bookings, invoices, stock and customer records all have off the shelf tools on a monthly fee. Custom pays off only when your process genuinely differs from what they do.
Instead of thatA ready made tool, then a connection to the site if needed.
How many people would use it every day?
If the answer is one or two, and the process happens a few times a week, the price of an app will not come back for years.
Instead of thatA tidied up process and one well built spreadsheet.
If discovery concludes that you do not need an app, you get that in writing, with the reasoning and with a suggestion of what to do instead. Discovery is paid in that case too, because the work was done, and you did not pay for an app nobody would use.
Phased approach
Four phases, and any of them can be the last.
You do not sign for a whole app at once. After each phase you hold something that is yours and you can stop without having thrown money away.
- 01
Discovery
So we know what gets built, how long it takes and what it costs.
BAM 750 to 1,500Paid separately and yours to keep, even if we go no further together.
- Scope and boundaries, what is in and what is out
- User flows and a list of screens
- A technical plan and an estimate per phase
- 02
Prototype
So it can be clicked through before development is paid for.
BAM 2,500 to 5,000Not a production version and it does not run on real data.
- A clickable path through the main screens
- A check with the people who will use it
- Corrections while it is still a drawing, not code
- 03
MVP
The first version that actually does the job.
The price depends on scope, and the three scopes are right below.
- Whatever discovery marked as essential
- Sign in, access rights and the data in one place
- Launch and handover, with access in your name
- 04
Iterations
So what actually gets used is what gets extended.
Agreed once the MVP is live, because only then is it clear what is needed.
- Measurement of what is used and what nobody opens
- An agreed order of priorities before each cycle
- Changes in cycles rather than on call
Each phase ends with a decision, not an automatic move to the next one. If you stop after discovery, the document is yours and you can take it to any contractor, and that is deliberate.
What I need from you is access to the people who actually do the work every day, not only a description from whoever runs it. The gap between those two is the most common reason a finished app goes unused.
Prices do not include VAT
MVP scope
An app is a range, not a price.
The same word covers a tool for two people and a system for a whole company. So the range is split in three, and which one you are in is known after discovery.
Simple app
BAM 8,000 to 15,000For whomOne process and one kind of user.
Entry, overview and a report over a single process. It replaces a spreadsheet that outgrew itself, and most often that is where to stop.
Micro SaaS
BAM 15,000 to 35,000For whomA product sold to other companies.
Several separate clients inside one system, with sign in, subscriptions and each of them seeing only their own data.
Business system
from BAM 20,000For whomSeveral departments and links to tools you already use.
More roles and permissions, integrations with what is already in place, and data that moves between systems without being retyped.
The upper limit of a business system is not written down, because integrations set it. Every connection to somebody else's software is a job of its own and gets estimated in discovery, not in advance.
What I have built
What actually sits behind this.
I am not going to make the biography bigger than it is. Here is what was built and what follows from it for you.
Admin panels on three systems
Three sites in production have their own panel. On one screen the owner sees revenue, earnings, clicks and where the visits came from.
Data that gets used, not collected
The panels were built around decisions the owner actually makes. So there are no screens nobody opens, and there are screens opened every day.
No public example
The figures in those panels are my clients' revenue and earnings, so they do not appear on this site, neither as a screenshot nor with a company name. That is why there are no images here.
A panel is not an app in the full sense and I will not present it as one. It is proof that I work with real data, access rights and screens somebody uses every day, and that is the same foundation every app stands on. For an app itself I have no public example, and that is exactly why I sell discovery rather than a promise.
The price
What moves the range.
There is no fixed price before discovery, and that is not dodging the question. A figure I gave you today would be either too high for you or too low for me, and neither is a good start.
Lowers the price
- A clear process somebody already does by hand, always in the same order
- A first version without exceptions and special cases
- Willingness to leave part of the work manual until automation proves itself
Raises the price
- More roles and different access rights
- Links to software you already use
- Payments, subscriptions and invoices inside the system
- Migrating data out of an existing system
Not included
What is billed separately.
With apps this is where assumptions go wrong most often, so it is stated up front.
- Running and maintaining the app after launch, which is a separate arrangement
- Licences and fees for outside services the app relies on
- Mobile apps in the stores. I build web that works on a phone
- Training every employee. Handover and training of the people running the system is included
Questions
What I get asked most.
- Why is discovery paid?
- Because it is work, not a sales meeting. It produces a document with scope, flows and an estimate that is usable with another contractor too. Free discovery would mean the clients who go ahead pay for it, through a higher development price.
- Can you give me a rough price now anyway?
- I can say which scope it sounds like, and those are written on this page. I cannot give a fixed figure, because the gap between the smallest and largest version of the same description is often fourfold. Anyone quoting a fixed price before scope is either too high or preparing to ask for more later.
- Do you have a finished app I can look at?
- I have no public app example and I will not pretend otherwise. I have admin panels on three sites in production, but their figures are client business data and do not go public. That is why the first step is discovery, where you see my work on your own problem.
- What if we realise mid way that it should be different?
- That is what the phases are for. The prototype exists so this gets discovered before it becomes code, which is the cheapest moment to change your mind. Changing scope after the MVP is new work and is treated as such.
- Who owns the code?
- You do. Code, data and access go into your name at handover. I do not hold an app as collateral and I do not build it so that only I can maintain it.
- Do you build mobile apps?
- Not for the app stores. I build web that behaves like an app on a phone and can be added to the home screen. For most business tools that is cheaper and faster, and the user does not feel the difference.
Next step
We start from a question, not from a quote.
Send what you are trying to solve and how you handle it today. If it turns out a site or a panel is the answer, I will say so before anyone pays for anything.