The opening claim
An entrepreneur walks in convinced he needs 50 million centimes to launch. Somebody quoted him 500,000 DZD, and he has spent four months trying to raise it instead of trying to sell anything.
He does not need it. Not for the first version. What he needs is three screens and a backend he does not have to operate, and the reason that is enough is not that I am cutting corners. It is that everything past those three screens is a bet on a customer who has not paid him yet.
The 500,000 DZD quote is not dishonest. It is a quote for the product he described, which includes a loyalty programme, an in app chat, push campaigns and an analytics dashboard. He described that product because he has never seen the alternative. The alternative is that he spends 50,000 DZD, launches in weeks, and lets real orders tell him which of those features to build.
The mechanism 🧠
A first version has exactly one job: prove that a stranger will give you money for this. Every screen that does not serve that job is a screen you are paying to build, paying to test, paying to debug, and paying to maintain, in exchange for information you already have.
Three screens carry the whole loop.
Screen one, the value. What this is, who it is for, what it costs, and one action. This screen exists to convert a stranger who arrived from an Instagram bio into someone willing to look at the catalogue. It is mostly copy, one image, and a button.
Screen two, the catalogue. The products or services, with a price, a photo and enough detail to make a decision. This is where you discover what people actually tap, which is the first real data your business ever produces.
Screen three, checkout and confirmation. Name, phone, wilaya, commune, address, and a confirmation the buyer can trust. The confirmation half matters as much as the checkout half: in a cash on delivery market a buyer who is not sure his order registered will place it twice or not at all.
That is the loop. Arrive, choose, order. Everything else, and I mean everything, is optimisation of a loop you have not proven yet.
The cost collapse comes from two decisions.
One codebase for both platforms. Flutter compiles to iOS and Android from a single source. Two native applications means two teams or twice the calendar, for a product whose users cannot tell the difference. This is the single largest line item you can delete without the customer noticing.
A managed backend instead of infrastructure. Supabase gives you Postgres, authentication, storage, row level security and an API on top of the schema, on a free tier that comfortably carries a launch. What you are avoiding is not just server cost. It is the weeks of building auth, the ops burden, and the specific trap of paying for infrastructure to serve traffic you do not yet have.
Those two decisions are most of the difference between 50,000 DZD and 500,000 DZD. The rest is the feature list you deleted.
Comparative Breakdown
| Decision | The 500,000 DZD path | The 50,000 DZD path |
|---|---|---|
| Screens at launch | Fourteen | Three |
| Platforms | Two native codebases | One Flutter codebase, iOS and Android |
| Backend | Custom server, custom auth | Supabase: Postgres, auth, storage, RLS |
| Infrastructure cost month one | Paid servers for zero users | Free tier |
| Time to first real order | Four to six months | Three to five weeks |
| Admin panel | Full custom back office | Supabase table view, then a real one |
| Payments | Card gateway integration first | Cash on delivery first, card later |
| What you learn before spending | Nothing | Which products sell, what RTO is |
| Risk if the idea is wrong | 500,000 DZD gone | 50,000 DZD, and you know why |
| What happens if it works | You built the right thing by luck | You extend on evidence |
The second column is not a worse version of the first. It is the first column with the guessing removed.
The Algerian reality
Three local facts make this argument stronger here than it would be anywhere else.
Capital is expensive and slow. There is no meaningful seed funding culture for a first time founder with an idea. That 500,000 DZD is family money, or savings, or a loan from someone who will ask about it at every family gathering. Spending it before you have a single paying customer is not ambitious, it is the most common way Algerian founders end their first attempt. Against an average net salary in the low forty thousands of dinars a month, 500,000 DZD is roughly a year of income. Fifty thousand is a month.
Your customer cannot prepay anyway. Roughly nine in ten transactions are cash on delivery. This has a beautiful consequence for a first version: you do not need a payment gateway at launch. Card integration is genuinely the feature most first time founders insist on and least need. Capture the order, confirm the buyer, collect at the door. You can add Chargily later, when card paying customers are a number in your own dashboard rather than an assumption.
The device is a mid range Android on a connection that drops. This shapes the build more than any budget decision. It means the application has to be small, it has to work in Arabic right to left as a first class layout, and it has to survive a lost signal without losing the order. Flutter handles this well, and it costs you nothing extra if you decide it at the start instead of retrofitting it after.
There is a fourth reality that is commercial rather than technical. Your buyer does not trust an unknown store. A first version therefore needs one thing that has nothing to do with features: a way to look real. A phone number that answers, a confirmation that arrives, a delivery that shows up. Founders spend money on animations and skip the confirmation message, then wonder about the drop off rate.
What to actually do 🛠️
Write your three screens down and defend them. Home, catalogue, checkout and confirmation. Every additional screen must be argued for against the sentence "a stranger cannot give me money without this". Almost nothing survives that.
Cut this list on sight, for version one. In app chat. Loyalty points. Push notification campaigns. A ratings and review system. Social login. A dark mode toggle. An analytics dashboard. A referral programme. Every one of these is a real feature that a real business eventually needs, and not one of them helps a stranger place a first order.
Use Supabase properly, not as a database with an API in front of it. Turn on row level security from day one. Define the schema first. Put the operations that must not tear in half, stock decrement with order creation, into a Postgres function so two simultaneous buyers cannot oversell your last item.
Model the order as events even in the small version. Placed, confirmed, dispatched, delivered, collected. It costs nothing extra now and it saves the rewrite later, because the day you add a courier integration you will need that history and you will not be able to invent it retroactively.
Ship the confirmation, it is not optional. An SMS or a WhatsApp message with an order reference. This is the cheapest trust feature in the entire market and it directly reduces both duplicate orders and failed deliveries.
Use the Supabase table editor as your first admin panel. It is not pretty and it is fine. Build the real back office when the number of orders makes the ugliness expensive, which is a good problem and a later one.
Set a budget for learning, not for building. The 50,000 DZD is not buying an application. It is buying the answer to whether anyone wants this, and that answer is what makes the next 200,000 DZD a decision instead of a gamble.
TL;DR 🧾
Three screens, one codebase, a managed backend, cash on delivery. Home plus catalogue plus checkout equals a business you can test. Everything else is a feature you are buying before your customer has voted, and your customer votes with an order, not with an opinion.
LINKEDIN VERSION
An entrepreneur told me he needs 50 million centimes to launch his app. He has spent four months trying to raise it instead of trying to sell anything.
He does not need it. Not for version one.
The 500,000 DZD quote was not dishonest. It was a quote for the product he described: loyalty points, in app chat, push campaigns, an analytics dashboard. He described that because he has never been shown the alternative.
A first version has exactly one job: prove a stranger will pay you. Three screens carry that. A home screen that explains the value. A catalogue with prices and photos. A checkout with a confirmation the buyer trusts. Arrive, choose, order. Everything else optimises a loop you have not proven yet.
The cost collapse comes from two decisions. One Flutter codebase for iOS and Android instead of two native builds. A managed backend like Supabase instead of servers, custom auth and ops you are paying for before you have traffic.
In Algeria this argument gets stronger. That 500,000 DZD is family money, roughly a year of an average salary. And around nine in ten orders are cash on delivery, which means the payment gateway that founders insist on is the feature they least need at launch.
Spend 50,000 DZD to learn whether anyone wants it.
Then spend the rest knowing.