Type "app solutions" into a search bar and you get two prices for what looks like the same thing: $99 a month, and $150,000. The whole industry lives in that gap, and almost nobody selling to you wants to explain why it exists. The cheap end and the expensive end are not two grades of the same product. They are two different answers to a question the buyer hasn't been allowed to ask yet: am I buying a thing, or am I buying the people who will keep the thing alive after it stops resembling the brochure?
That is the read everyone gets wrong. The market is organized around the noun "solution" — as if your app were a problem with a known shape, sitting on a shelf, waiting to be matched to a SKU. It almost never is. After eleven years building software for other people, I can tell you the word "solution" is doing more lying than any other word in the pitch, and it's worth taking apart before you spend a dollar.
The word "solution" is the part that's lying
"Solution" is past tense. It tells you the hard part is over — that someone already figured out your business, packaged the answer, and all you have to do is sign. That framing is the entire sales strategy of the category, and it is backwards. Software is not a solution you acquire; it is a position you have to keep defending as your business, your users, your regulators, and your competitors all move. The day you ship is the day the maintenance starts, not the day the problem ends.
You can hear the lie most clearly in the verb tense. A vendor says "we have a solution for marketplaces." What's true is "we have a template that has worked for some marketplaces under conditions we won't enumerate." Those are very different promises, and the distance between them is exactly where projects die.
There are only two things actually being sold
Strip the brand language off every "app solution" on the market and you find one of two things underneath. The first is a template — a builder, a low-code platform, a vertical SaaS you configure. The second is a staffing arrangement: bodies who will write your app, sold to you with the word "solution" stapled on so it sounds like a product instead of an hourly contract. Neither is inherently wrong. The fraud is the marketing that refuses to tell you which one you're looking at.
The template is honest math when your problem genuinely matches the template. The staffing arrangement is honest math when your problem is genuinely yours. The trouble is that the word "solution" is specifically designed to stop you from working out which case you're in — because the moment you know, you can price it, and a priced thing is harder to oversell.
Where templated app solutions actually collapse
The forecast the whole low-code industry repeats is that the large majority of new applications inside organizations will be built on low-code or no-code platforms — a number that climbed from a minority of projects a few years ago to most of them. Treat that as real and it still doesn't say what vendors imply. It says most apps are CRUD forms over a database with some workflow — internal tools, intake forms, dashboards. For that, a template is not a compromise. It's the correct answer, and paying for custom code would be the mistake.
The template collapses at the 80/20 line, and it collapses in a specific, predictable way. The first 80% of your app is fast and cheap because it looks like everybody else's app. The last 20% — the part that is the actual reason your business exists — is precisely the part the template was built to prevent you from changing. That's not a bug in the platform. A template's value comes from constraining variation; the constraint is the product. So the closer you get to your differentiator, the harder the tool fights you, and the more your "$99 a month" turns into a contractor billing $120 an hour to bend a platform into shapes it was designed to refuse.
I've watched the inversion from the cleanup side more than once. We picked up a marketplace codebase that was about a year old and had to deliver a working platform against a 90-day go-live — the earlier work had gotten the generic 80% in place and then stalled at exactly the part that mattered. The lesson isn't "templates are bad." It's that a template buys you speed on the commodity and charges you interest on the differentiator, and the interest is where the whole budget goes.
"From scratch" is not the brave choice it's marketed as either
The other half of this needs saying, because the anti-template crowd oversells just as hard. "Custom-built, ground up, bespoke" is a fine way to set $200,000 on fire building login screens, password resets, and payment plumbing that Stripe already solved better than you will. The discipline that actually matters is not template-versus-custom. It's knowing, line by line, which parts of your app are commodity — buy those, every time — and which parts are the reason anyone would pay you. Custom belongs only on the second category.
We rebuilt a stalled food-delivery product by spending a week doing nothing but deconstructing scope, then re-estimating the build something like ten times, cutting thirty to fifty percent on each pass until what was left was the smallest thing that could actually ship. That is the real work that "app solutions" marketing hides from you: not choosing a platform, but having the nerve to delete most of the idea. A pre-packaged solution sells you the comfort of not having to make that call. The bill for skipping it arrives later, with interest.
The question that's never in the brochure: who's here in year three
Here's what the "solution" framing is engineered to hide. An app is not an artifact you take delivery of; it's a relationship you're starting with whoever maintains it. The honest question is not "what does this solution do" but "who picks up the phone in year three when iOS breaks something, a dependency is abandoned, and the one person who understood the payment flow has left." Almost no "app solution" is sold on that axis, because on that axis most of them lose.
This is where I'll plant a flag. The single most predictive thing about whether your app survives is not the stack, the platform, or the price — it's whether the same people who built it are still there to fix it. The industry runs engineer turnover north of 20% a year, which means the standard outsourced "solution" is a relay race where everyone who knew why a decision was made has handed the baton to someone who doesn't. We keep turnover under 5% a year on purpose — of fifty-plus engineers hired since 2015, fifteen have left voluntarily — not because it's a nice HR number, but because institutional memory is the entire product after launch. The studio has been the engineering team on one passenger-rights platform since 2016, roughly a decade; the platform we built has since processed over a million claims. You cannot buy that as a "solution." It only exists as continuity.
Continuity is also why "no body shopping" is a load-bearing phrase and not a slogan. When a vendor sells you a "solution" and quietly rotates whoever is cheapest onto your codebase, every quarter resets the knowledge to zero and your app accumulates the kind of damage nobody can point to until it's structural. Every pull request getting reviewed by another senior engineer before it merges isn't process theater; it's the mechanism that keeps the app understandable by more than one person, which is the only thing that makes year three survivable.
What you're actually choosing between
So drop the word "solution" and the decision gets clean. If your problem is commodity — an internal tool, a standard workflow, a thin app over a database — buy the template, configure it, and don't let anyone talk you into a six-figure custom build for a problem the market already solved. That's the honest cheap end, and it's genuinely good.
If your app is the business — if the 20% that's yours is the whole point — then you are not shopping for a solution at all. You are hiring a team, and you should price it like one and judge it like one. As a rough frame from the work we actually quote: a focused four-person team runs about $25,000 to $55,000 a month, and the project bands that come out of that land around $40–100K for an MVP, $60–150K for a real SaaS build, and more for a marketplace, with the range driven almost entirely by how much of your app is the irreducible custom 20% versus commodity you should be buying off the shelf. Anyone quoting you a single confident number before they understand that split is quoting the brochure, not your app.
The retention argument runs through everything we write about staffing; our full breakdown of when staff augmentation is worth it is the fullest version of it. For the practical side, see our staffing services.
The position, stated plainly
"App solutions" is a category that mostly doesn't exist. It's a word laid over two ordinary things — a template and a team — to keep you from asking which one you're buying and what it actually costs over the years you'll depend on it. The buyers who do well are the ones who refuse the noun: they figure out which parts of their app are commodity and buy those without ego, and they treat the rest as a long relationship with people who stay, not a product they take delivery of and forget. There is no shelf with your answer on it. There's commodity you should buy, differentiator you should build, and the question of who's still standing next to the code when it breaks. Decide on those three and you never have to wonder what an "app solution" is again.