Transparent MVP pricing: what £25k actually buys at Bluka

Most studios treat their pricing like a secret you have to earn through three sales calls. We think that is backwards. Transparent MVP pricing is one of the few things that actually helps a founder make a good decision, and hiding it mostly helps the studio. So this piece does something unusual: it opens up exactly what £25k buys when you build an MVP with us, where every part of that money goes, and how to tell an honest quote from a hopeful one. If you are comparing studios right now, this is the article I would want to read.

What “£25k” actually means in transparent MVP pricing

Let me start with the number itself, because it is the source of most confusion. When we say a project starts around £25k, we do not mean twenty-five thousand pounds of code. We mean a fixed-scope MVP: a real, working product, on real devices, that a real user can download and use to do one important thing well. Transparent MVP pricing means naming that scope out loud before anyone signs anything, so £25k buys a defined thing rather than a hopeful direction.

The reason the figure gets abused across the industry is that “MVP” has no legal definition. One studio’s £25k MVP is a genuine product; another’s is three screens and a promise to sort out the rest later. We wrote about that gap in detail in the £25k MVP myth, and this piece is the honest other half of it: not what the number leaves out, but what ours actually includes.

Where the money goes, line by line

Here is the part almost nobody shows you. A £25k MVP budget is not one big lump, it is a set of distinct jobs, each of which costs real time. When we quote transparently, this is roughly how a project of that size breaks down.

Those percentages move a bit from project to project, but the shape holds. Notice what it tells you. Nearly half the money is the build, which people expect. But a third of it is design, definition, and management, the parts that are invisible in a demo and decisive in a real product. A quote that is almost all “development” and almost no design or definition is not cheaper, it is just hiding where the risk lives.

Product and scope definition

Before anyone designs a screen, we work out the single thing your MVP has to prove and cut everything that does not serve it. This is the cheapest part of the budget and the one that saves the most money, because every feature we agree to leave out is money not spent building something you did not need yet. If you want to see how we do this, our checklist for scoping an app project walks through the exact questions.

Design

Design is not decoration here, it is how you avoid building the wrong thing twice. Twenty percent of the budget buys the flows, the screens, and enough of a considered interface that early users take the product seriously. Skipping it does not save money, it moves the cost to later, when changing a built product is far more expensive than changing a drawing.

Build

The largest single share, and rightly so. This is the working software: the app on the phone, the server behind it, the database, the logic that makes the thing do its job. When people picture “what they are paying for”, they picture this. It is a bit under half.

Testing, launch, and management

The last chunk is the difference between a demo and a product. Testing on real devices, fixing what breaks, getting through App Store and Google Play review, and someone managing all of it so the project ships. It is unglamorous and it is exactly where cut-price quotes quietly save money by leaving it out.

Why quotes vary so wildly for the “same” app

If you have collected quotes, you have probably seen the same brief come back at £8k from one place and £120k from another. That range is real and it is not random. Understanding it is the whole point of transparent MVP pricing.

The biggest driver is scope. Two studios quoting the “same” app are almost never scoping the same app. One assumes a login, a payment system, and admin tools; the other assumes none of them and will add each as a paid extra later. The cheap quote is often cheap because it is smaller, and you only find out mid-project.

The second driver is who does the work and where. A £150-a-day offshore contractor and a UK studio team are different products at different prices, and both can be the right call depending on what you are building and how much you can manage yourself. We wrote a full breakdown of what an MVP really costs in the UK in 2026 if you want the market-wide picture rather than just ours.

The third driver is honesty. Some quotes are low because the studio genuinely intends to make it up in change requests once you are committed. A £25k quote that becomes £60k by launch was never a £25k project. Transparent MVP pricing is partly a promise that the number you start with is the number that means something.

What £25k does not buy

An honest pricing article has to include this section or it is just marketing. A £25k MVP is a starting product, not a finished company. It does not buy you a fully featured platform with every integration you can imagine. It does not buy months of post-launch iteration, which is a separate and ongoing cost. And it does not buy certainty that your idea will work, because no amount of money buys that. What it buys is the fastest honest route to putting a real product in front of real users so you can find out.

If your idea genuinely needs more than an MVP on day one, we will tell you, and the number will be higher. What we will not do is quote you £25k for a £60k project and let you discover the gap later.

How to read any quote you are given

You do not have to build with us to use this. Whatever quotes you are holding, here is how to pressure-test them. Ask each studio to break the number into design, build, testing, launch, and management, roughly the table above. A studio doing transparent MVP pricing will answer without flinching. One that cannot, or will not, is telling you something.

Then ask the more uncomfortable question: what is not included that you will need before launch? Logins, payments, admin panels, and App Store submission are the usual quiet omissions. The answer separates a real fixed-scope quote from a low anchor designed to win the deal.

Finally, ask who actually does the work and where they are. Not to rule out any answer, but so you know what you are buying. A cheaper day rate you have to manage yourself is a different product from a UK team that manages itself, and both are valid. You just deserve to know which one the number represents.

Why we do it this way

We price transparently for a slightly selfish reason: it attracts the founders we work best with. People who want the cheapest possible number regardless of scope are not a good fit for us, and transparent pricing lets both sides find that out on day one instead of month three. It also keeps us honest, because once the breakdown is public, we have to stand behind it.

The deeper reason is that a founder spending £25k of real money, often their own, deserves to know exactly what it buys. That is not a favour, it is the baseline. If a studio will not show you where your money goes before you commit, that is the most useful thing they will ever tell you about working with them.

A worked example: what a real £25k scope looks like

Abstract percentages only get you so far, so here is a concrete shape. Imagine a founder comes to us with a booking app for a niche service: users find a provider, book a slot, and pay a deposit. That is a real, fundable idea, and it fits a £25k MVP if we scope it honestly.

What goes in: a clean sign-up and login, a browse-and-search screen, a provider profile, a booking flow, a deposit payment through a payment provider, and confirmation and reminders. On the backend, the accounts, the bookings, the payments, and a basic admin view so the founder can see what is happening. On both stores, live and approved. That is a product a real user can complete a real booking with.

What stays out for now: in-app chat, a loyalty scheme, reviews and ratings, multiple languages, and an analytics dashboard beyond the basics. None of those are bad ideas. They are just not what the MVP needs to prove, which is that people will find a provider and pay a deposit. Each one we leave out is money kept in reserve for after you have evidence. That is the discipline behind the number, and it is the difference between a £25k product that ships and a £25k down payment on a project that does not.

What happens after launch, and what it costs

Here is something most pricing pages never mention, because it is easier to sell a one-off number. Launch is not the end of spending, it is the start of a different kind. An MVP that works generates users, and users generate feedback, bugs, and new needs. Budgeting for the build but not for what comes after is one of the most common founder mistakes we see.

After launch you are paying for three things. Hosting and services, which are usually modest at MVP scale but real and recurring. Maintenance, because iOS and Android keep changing and an app that is not updated slowly stops working. And iteration, which is the actual point: improving the product based on what real users do. We are transparent that these are separate from the build budget, because pretending £25k covers a year of iteration too is exactly the kind of quiet dishonesty this whole piece is arguing against.

The good news is that these costs are optional in their pace. You can iterate fast or slow depending on traction and money. What you cannot do is skip them entirely and expect the product to stay alive, and any studio that lets you believe otherwise is setting you up for a nasty surprise in month four.

How we keep a fixed price actually fixed

A fair question at this point: if scope drives price, what stops a fixed £25k quote from creeping to £50k the moment you change your mind? This is where a lot of studios make their real margin, and where an open approach to pricing has to prove it means something.

We handle it with a simple agreement. The scope we define together at the start is the fixed scope, and the fixed price covers exactly that. If you want to change something within that scope, swapping one feature for another of similar size, that is normal and it is free. If you want to add something genuinely new that was not in the agreed scope, we price it separately and you decide, before any work happens, whether it is worth it. Nothing gets added silently and billed later.

That structure protects both sides. It protects you from a quote that balloons through vague “small additions” that were never small. And it protects us from building forever on a fixed price because the goalposts kept moving. The number stays honest because the scope stays honest, and both are written down before anyone starts.

The deeper habit underneath it is that we would rather have the uncomfortable scope conversation on day one than the uncomfortable invoice conversation in month three. Founders remember how a project ended far more than how the quote looked at the start.

What openness about price signals about a studio

Step back from the numbers for a moment, because how a studio talks about money tells you a lot about how it will behave once you have signed. A studio that shows you the breakdown before you commit is one that expects to be judged on it. A studio that guards the number until you are emotionally invested is one that has learned the number does better work when you cannot examine it.

You can use this as a filter even if you never work with us. The willingness to itemise, to name what is excluded, and to say out loud when your project needs more or less than you asked for, all of that is a preview of the working relationship. Openness about price is not a marketing gimmick, it is the same honesty you will need when something goes wrong mid-build, which on a real project it eventually will. The studios worth trusting with your money are usually the ones least nervous about discussing it, and the reverse is just as reliable a signal.

None of this means the cheapest itemised quote wins. It means the quote you understand wins, because you can only make a good decision about a number whose parts you can see. A clear £30k is a better buy than a mysterious £22k almost every time.

What to do next

If you are weighing up an MVP and want a number you can actually trust, the most useful thing you can do is come with your idea and let us scope it honestly, including telling you if £25k is the wrong number in either direction. We would rather quote you accurately and lose the ones we are wrong for than win a project by hiding the maths.

Tell us what you are trying to build and we will give you a transparent breakdown, not a sales anchor. Start a project brief and we will come back with real numbers. And if you are still deciding whether a studio is even the right model for you versus other options, our comparison of a fractional CTO versus a product studio is the honest place to start.