What the App Store teaches that enterprise software forgets

We should start with the thing that is normally left out of a post like this. Docksoft has shipped two consumer products. We have not yet shipped a B2B product or a SaaS platform under our own name. If you are evaluating us for that kind of work, you are entitled to know that before you read our opinions about it.

What we would argue is that the school we came up in is harder than the one most enterprise software teams attend, and that the lessons run in one direction. A team that can survive the App Store can build an internal tool. The reverse is much less reliably true.

The feedback loop is brutal and public

When you publish a consumer app, the people who use it did not meet you. They did not sit in a procurement process, evaluate three vendors, or sign anything. They tapped a button, and they will stop using your product the moment it annoys them, with no exit interview.

Everything about that feedback is unforgiving. Reviews are public, permanent, and written by people at their most irritated. Crash rates are counted by a third party who does not care about your explanation. Refunds happen without a conversation. Retention is a number you cannot argue with, produced by strangers who owe you nothing.

Enterprise software mostly does not work this way. A tool bought by a director and used by forty people has a captive audience. Nobody uninstalls it. The dissatisfaction is real but it is expressed as grumbling, workarounds, and shadow spreadsheets, none of which appear in a metric anyone is watching. It is entirely possible to ship business software that everyone quietly hates and to receive no signal at all until the renewal conversation two years later.

This is why the consumer discipline transfers usefully. If you have been trained by an audience that leaves the instant you waste their time, you do not stop designing that way when the audience becomes captive. You just have to go and find the signal yourself, because it is no longer delivered to your inbox with one star attached.

You cannot ship a demo

The single largest difference is that a consumer release has no presentation layer between the work and the person judging it.

Enterprise software is frequently sold, and sometimes built, through demos. A demo is a curated path. It goes through the states that work, with data that was prepared, at a pace controlled by the presenter. It is possible for a product to demo beautifully for months while the second screen from the left has an empty state that says “undefined”, because nobody has ever clicked it in front of a customer.

An App Store release has no curated path. Every user starts at first run, on their own device, with no data, possibly offline, possibly with the text size turned all the way up, and they go wherever they want. The empty states are not optional polish. They are the first thing everybody sees. Onboarding is not a slide; it is the product for the first ninety seconds, which is the entire window you get.

Building under that constraint changes what “done” means. The last ten percent — first run, empty states, error copy, offline behaviour, accessibility, what happens when the network is slow rather than absent — stops being the part you get to if there is time. It is the part users experience first and remember longest.

App Review is a security review with worse hours

Every release goes to a reviewer who does not know you, is not on your schedule, and can reject the build for a reason you disagree with. There is no relationship to lean on and no meeting to escalate in.

Teams who have been through this repeatedly develop habits that turn out to be exactly what enterprise procurement wants. You learn to state precisely what data you collect and why, because you have had to fill in the disclosure. You learn to justify every permission the app requests, because a reviewer will ask. You learn that surprising a gatekeeper is always more expensive than telling them up front.

A security questionnaire from a mid-size company asks the same questions with different formatting. The team that has already answered them forty times, under a release deadline, finds it recognisable.

Pricing is a product decision

Consumer subscription pricing is a genuinely hard problem and it is solved with the product, not with a spreadsheet. Where the free tier ends determines what people believe the app is for. A paywall placed one screen too early makes the product look grasping; one screen too late and nobody ever sees the reason to pay.

The people who set that boundary are the people who designed the product, because it cannot be delegated to a pricing exercise conducted afterwards. That habit — treating commercial structure as part of the design rather than a wrapper around it — is directly what SaaS work requires. Plans, limits, seats, upgrade paths, and what happens when a card fails are product surfaces. They are the ones most often left to the end and they are the ones that decide whether the business works.

What does not transfer

Honesty requires the other column.

Consumer work does not teach you organisational complexity. It does not teach you what happens when the person who buys the software is not the person who uses it and neither is the person who owns the data. It does not teach you procurement, legacy integrations, an ERP that cannot be touched, or a workflow that exists because of a regulation from 1994.

It also does not teach patience with the sales cycle. A consumer team is used to shipping something on Tuesday and knowing by Friday. Enterprise timelines are different in kind, not just in degree, and a team that has never worked in them will underestimate that on the first project.

These are real gaps. We would rather name them than have a client discover them.

The argument, stated plainly

The claim is not that consumer experience makes a studio automatically qualified for business software. It is narrower than that, and we think it holds:

The parts of software that decide whether people trust it — the empty states, the failure copy, the speed of the common path, the honesty of the reporting, the restraint about what gets collected — are the parts the App Store forces you to get right and the parts enterprise delivery most often lets you skip. We were trained by the harsher of the two.

What we would ask of anyone considering us for B2B or SaaS work is to judge us on the products that exist. Install them. Look at the first run, the empty states, what happens when you deny a permission, what the blocking screen says when you are frustrated. That is the standard we would bring to your software, and it is verifiable today rather than described in a deck.