The opening claim
"50 millions for the app." I hear this number more than any other in Algiers, and I mean it the way we say it here: 50 million centimes, which is 500,000 DZD.
Here is what that usually buys. A native Android app, a separate native iOS app, a custom backend on a rented server, an admin panel, loyalty points, in app chat, push campaigns and an analytics dashboard. Eight months of development. And then, very often, a launch that never happens, because the money ran out before the last feature was finished, or because the market moved while the team was building.
The app did not die because it was badly built. It died because it was fully built before anyone checked whether customers wanted it.
The mechanism 🧠
Over engineering is the habit of solving problems you do not have yet. In a startup it is fatal for a simple reason: every week spent building for an imaginary future is a week not spent learning from the real present.
The numbers point in the same direction. In CB Insights' analysis of startup post mortems, running out of cash and having no market need are the two most cited reasons for failure, each mentioned in more than a third of cases. You will also see a famous Standish Group figure claiming that 45 percent of software features are never used. That number is old and debated, so do not quote it as precise. But anyone who has looked at real usage data knows the pattern it describes: most features in most products are barely touched.
Scalability is not a day one problem; market validation is. Build for 1,000 active users before you architect for a million.
The death of the bloated build
Here is how the money goes in a typical bloated project.
| Spending area | What the founder thinks it buys | What it actually buys before validation |
|---|---|---|
| Two native apps | Quality on both platforms | Twice the code, twice the bugs, twice the time |
| Custom server and backend | Control and scale | Months of plumbing a managed service already solves |
| Full admin panel | Professional operations | Screens for workflows nobody has run yet |
| Loyalty, chat, campaigns | Engagement | Features for users who do not exist yet |
| Analytics dashboard | Data driven decisions | Charts with no data in them |
None of these things is wrong forever. All of them are wrong first.
The modern lean stack
Today a small team can ship a production grade product with three tools.
- Flutter for mobile. One codebase builds both Android and iOS. You maintain one app, not two, and the user experience is consistent across platforms.
- Supabase for the backend. A managed Postgres database with authentication, file storage, real time updates and row level security built in. Permissions are enforced in the database, so a client app cannot read data it should not see.
- Next.js for the web. Storefronts, landing pages and client portals that are fast, search friendly and easy to deploy.
A lean stack is not a cheap stack; it is an architecture that removes every layer you would otherwise have to build and maintain before your first customer arrives.
What you skip at the start: your own servers, your own authentication system, a separate iOS team, and custom infrastructure monitoring. What you keep: a real database, real security rules, real payments and a real path to scale when usage demands it.
Real world proof
Two products I have built show the stack doing real work.
BULA is a bilingual English and Spanish staffing app for the construction trade in the United States, connecting workers, subcontractors and employers. It runs on Flutter with a Supabase backend and Firebase push notifications. Several distinct user roles, document based verification and a bilingual interface, all from one mobile codebase.
WovenDZ is a multivendor ecommerce platform for Algeria. Storefronts and the merchant dashboard run on Next.js with Supabase underneath. Cash on delivery, local courier integrations and Arabic right to left storefronts. The web platform went live first, and the mobile apps are being built after it, which is the lean order of operations: prove the business on the cheapest surface, then expand.
Neither product needed a custom server farm to launch. Both can grow on the same architecture well past their first thousand users. I describe what the production layer of a platform like this involves in the anatomy of a production platform.
The 5 millions scoping framework
5 millions in Algerian terms is 50,000 DZD. That is enough to test a business, if you scope it ruthlessly. I break down the full cost logic in the 50,000 DZD app formula. Here is the roadmap.
Phase 1: Prove someone pays (about 50,000 DZD).
- Three screens: what it is, what you sell, how to order.
- One Next.js web app or one Flutter app, not both.
- Supabase for data and auth.
- Cash on delivery as the only payment.
- Orders confirmed manually by phone.
Phase 2: Remove the manual work that hurts (after real orders).
- Automate order confirmation.
- Connect courier APIs such as Yalidine or ZR Express.
- Add a simple dashboard for the operations you actually run daily.
Phase 3: Expand to where users are (after repeat customers).
- Add the second platform, mobile or web.
- Add card payment through Edahabia or CIB if buyers ask for it.
- Add loyalty or campaigns only when you have customers to retain.
Phase 4: Scale what is proven.
- Optimise the queries that are actually slow.
- Add caching, monitoring and capacity where usage data shows the need.
Each phase is paid for by the evidence of the one before it.
The Algerian reality
Three local facts make lean architecture even more important here. Most buyers pay cash on delivery, so the payment integration that founders insist on is the feature they need least at launch. Android dominates, so launching on Android or the web first reaches most of the market. And capital is scarce: 500,000 DZD is often family savings, roughly a year of an average salary, and it should not be spent on a guess.
What to actually do 🛠️
- Write down the one action that proves value. Order, book, pay, sign up.
- Cut to three screens around that action.
- Choose one surface to launch on, web or mobile.
- Use Flutter, Supabase and Next.js instead of custom infrastructure.
- Spend the rest only after orders arrive.
TL;DR 🧾
Expensive apps usually die because they are fully built before anyone validates demand. Two native apps, a custom backend and a dozen features burn the budget before the first customer. A lean stack of Flutter, Supabase and Next.js gives you a production grade product for a fraction of the cost. Scope to three screens, launch on one surface, use cash on delivery, and let real orders pay for every next phase.
Build lean, launch this quarter
If you have a 50 millions quote on your desk, talk to me before you sign it. See the mobile app service, custom platforms and internal tools, or all services. Agency projects run through Brandz Tech.