Powstania Warszawskiego 15
31-539 Kraków
Most founders arrive with a feature list rather than a budget. The list is what sets the budget, the release date and how much you actually learn from the first version. This is a feature by feature read on the items that appear on almost every startup list, and a plain answer on which ones version one needs.
An MVP app needs three things: accounts, but only when someone returns to stored data; the single workflow the product exists to test; and a small admin panel. Push notifications, in app chat, public profiles, payments and offline creation each need a specific reason to be in the first release rather than a default place on the list.
Apps Value applies one test to every item on a feature list. Does this feature change what you learn from the first version? Everything below is that test applied feature by feature.
A first version exists to produce evidence. Every feature either changes what you learn from the first release or it does not. That is the whole filter, and it sorts a twelve item list faster than any workshop.
It works because it separates two things founders tend to merge. There is the product you intend to run in two years, and there is the smallest thing that tells you whether that product is worth running. The second one is what gets built first.
The sections below apply that filter to the features that show up again and again. If you want the process view instead of the feature view, the MVP app development scope page covers how the line between version one and version two gets drawn and written into a contract.
Founders write login as one line. Inside it are sign up, sign in, password reset, session handling and account deletion, plus a decision on whether social sign in is part of the first release. Each of those has its own screens, its own error states and its own edge cases.
The useful question is not how login should work. It is whether the product needs to know who someone is before you have proof anyone wants it. A booking tool for a single provider can take a phone number at the point of booking. A two sided marketplace cannot, because the whole product is people finding each other again.
Include it when the product stores something a returning person comes back to. Email and password with a reset flow is enough. Social sign in adds provider setup and store rules, and it can wait.
Profiles usually mean two unrelated things. One is the settings screen where someone changes their own details, which is small and predictable. The other is the public profile that other users see and judge, which is a different piece of work entirely.
A public profile pulls in image uploads, cropping, a moderation path, a reporting path and a second set of privacy decisions. On a marketplace that is not decoration, because the profile is how one side decides whether to trust the other. On a tool used inside one company it is usually pointless.
Settings screen yes, always. Public profiles only when the product depends on strangers evaluating each other, which is the case in most marketplace products and almost nowhere else.
Wiring push into a Flutter or React Native app is a small piece of work. Making push useful is the part that takes time: choosing which events deserve a message, writing the copy, handling the case where permission is refused, opening the right screen when the message is tapped, and deciding when the app stays quiet.
The failure mode is asking for permission on first launch with no context. Permission is refused once and it is very hard to win back, so the channel is closed before the product ever uses it.
Include the plumbing when the product only works if people come back. Ship two or three message types that carry real information, not ten, and ask for permission at the moment the value is obvious.
Chat looks like a text field and a list of messages. What it requires is real time delivery, unread state, notification fan out, a moderation and reporting path, and an answer to what happens when one side stops replying or leaves the platform.
On most early marketplaces the conversation can move to a phone number or email and the hypothesis still gets tested. You lose the ability to see the conversation, which matters later for trust and for taking a cut, and matters much less in the first release.
Cut it unless the conversation is the product. If matching two sides is the hypothesis, test the matching first and add messaging once people are matching.
Payments belong in version one when money changing hands is the thing being tested. If the hypothesis is that people will pay, then take the payment, because an intent to pay and a completed payment are not the same evidence.
If the hypothesis is that people will use the tool at all, payments can be handled outside the app for a while, manually and invisibly to the user. That removes a checkout flow, refunds, failed payment states and a longer store review from the first build.
Marketplace and subscription products get a predictable extra step here, because the store checks whether the payment should be going through its own system. That is resolved by explaining the model, and it is worth planning for rather than discovering in the last week.
Include when revenue is the hypothesis. Otherwise instrument the intent, charge outside the app, and add checkout once you know what people are paying for.
This is the feature almost every list leaves out, and the one Apps Value most often adds back. Somebody has to approve a listing, refund an order, correct a wrong record, unblock a user or check why a job never arrived. In week three of real use, that need is certain.
Without a panel, every one of those tasks becomes a request to the development team and a manual change to the database. That is slower, more expensive and more risky than the small back office would have been, and it puts a developer between the founder and their own data.
Add it to the list. It does not need to be beautiful. A list of records, a search box, and the three or four actions that will actually be needed is enough.
Offline is three different requirements wearing one word. Seeing data that was already downloaded is one. Creating work with no signal and having it arrive later is another. Treating the network as optional across the whole product is a third, and each costs a different amount.
For most startup products, reading cached content covers the real complaint. Creating work offline is a genuine engineering build with versioning, sync and a manual correction path, and it belongs in offline first app development rather than in a first release.
Cached reading, yes, when people use the product away from a desk. Creating work offline only when the product exists specifically for people without signal, which is the norm in field service and rare in consumer products.
A second surface is not a feature, it is a second product with its own screens, its own states and its own testing. Founders reach for it when the person using the app and the person paying for it are different people.
When that is true, the dashboard is often the more important half and the mobile app is the input device. When it is not true, the dashboard is a version two decision and the admin panel already covers the operational need.
Include only when the buyer and the user are different people. Otherwise ship one surface and a small back office.
A twelve item list and a six item list are two different products, not two prices for the same one.
The same filter produces different answers depending on what the product is. Four shapes cover most of what founders bring to Apps Value.
If you want to see what these choices do to the budget, the weeks each feature decision adds, with two budgets for the same idea side by side, are broken down in what an MVP app costs. Current price bands are on our pricing page.
The strongest argument for a short first list is not the budget. It is that the real requirements are not knowable in advance, and a smaller first version reaches the moment where they appear sooner.
On TimeFix, the work timer had to keep counting when a technician locked the screen or took a call from inside the app. That was not in the assumptions. It came out of technicians using the thing on real jobs, and it would not have surfaced in any specification meeting.
The same project produced a second lesson. Before the app handled a particular case, technicians started writing that information in the notes app on their phones, which quietly put the truth in two places. A feature request like that is worth more than a year of planning, and you only get it by shipping.
On a river navigation product, the first real confidence came from taking the app onto the water. Everything worked in the simulator. In real use there were dropped connections and wrong positions on the map, and fixing those was the actual work.
Clients also put their own people on the product during or after the build, and that is reliably when requirements appear that no one could have specified. A short version one gets you to that point faster and with fewer things to unbuild.
The features cut from version one are not deleted. They sit on a list that gets reordered by evidence, which is a much better position than an ordered list built from assumptions.
Two things cause more slipped dates than scope. The first is accounts and access: developer accounts for the stores and credentials for third party services, which take longer to arrange than anyone expects and are needed early. The second is decisions, which means having one person who can settle a question the same week it is asked.
Both are on the client side, and both are free to fix. If you want the whole sequence, working with an app development agency sets out what each stage asks of you, and a discovery workshop is where the feature list becomes a scope with a number attached.
The features that change what you learn from the first release, and no others. In practice that is usually accounts, the one workflow the product exists for, and a small admin panel. Push, chat, public profiles, payments and offline creation each need a specific reason to be in the first build.
Only when the product stores something a returning person comes back to, or when users need to find each other. If a single visit produces the value, skip accounts and collect an identifier at the point where you need one. When login is included, email and password with a reset flow is enough for version one.
They are worth it when the product only works if people return, and wasted when they are added as a default. The wiring is small, the decisions are not. Ship two or three message types, and ask for permission at a moment when the reason is obvious rather than on first launch.
Include payments when people paying is the hypothesis you are testing, because intent and a completed transaction are different evidence. If the question is whether people will use the product at all, charging outside the app for the first months tests the same thing and keeps checkout, refunds and failed payment states out of the first build.
In almost every case, yes, and it is the feature most often missing from the list handed to a development partner. Approving, refunding, correcting and unblocking are needed within weeks of launch. Without a panel each of those becomes a developer task and a manual database change, which costs more than the panel would have.
There is no clean number. The useful signal is a list where you cannot say what each item teaches you, and if three or four items fail that test, the release date is being spent on things that will not inform the next decision. Apps Value sorts this on a call, and the outcome is a fixed price scope rather than an open ended estimate.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Thirty minutes on a call is usually enough to sort a feature list into version one and version two, and to say what each half means for the release date.
Book an intro call30 minutes, no preparation needed.