Why Joldisoft Doesn't Build Apps for Everyone

A note from our CEO

Every week, someone contacts us with a version of the same message: "I want an app like Uber (or Foodpanda, or Urban Company). How much, and how fast?"

The easy answer is a price and a start date. Many software companies give exactly that answer, take the deposit, deliver the app, and move on. For a few months, that looks like good business.

We have decided not to work that way. Not because we are better people, but because we have seen what happens next, and it is bad for everyone, including us.

This article explains why Joldisoft does not build apps for everyone, what we look for before we start, and what we promise in return. If you read it and decide we are too demanding, that is a fair outcome. If you read it and recognise yourself in the checklist, we would like to talk.

What happens when we take a project that is not ready

Here is the pattern we want to avoid. It is not a story about one client. It is the shape of a mistake that is very common in our industry.

1. A founder saves money, borrows from family or raises a small round.
2. Most of it goes into the app, because the app feels like the business.
3. The app launches. A few friends download it. Some orders come in.
4. There is no budget left for marketing, driver incentives, restaurant onboarding or support staff.
5. Growth is slower than expected. Suppliers leave because there are not enough orders. Customers leave because there are not enough suppliers.
6. Within months, the business closes. The founder is out of money and, worse, out of confidence.

The data is consistent with this. CB Insights' 2026 analysis of 431 venture-backed startups that shut down found that 70% ran out of capital and 43% had poor product-market fit. Those are companies with investors behind them. A self-funded founder has even less room for error.

What it costs the founder

Money is the obvious loss. The less obvious loss is motivation. A founder who has spent their savings on an app that nobody uses often concludes "I am not good at business" or "this market does not work". Sometimes neither is true. They simply spent the money in the wrong order: building first, selling later.

What it costs us

We are a small company with a long-term model. Our real business is not one-off builds. It is ongoing relationships: maintenance, new features, new cities, new apps for the same founder as their business grows. When a client's business closes six months after launch, there is no relationship left. We have a finished project in our portfolio and a founder who will never recommend us.

So when we say no to a project that is not ready, we are protecting the founder's money and our own future. Both matter.

Our belief: long-term partners, not one-off projects

In the AI era, anyone can build software. Building has become cheaper and faster every year. What has not become easier is selling, recruiting supply, and running daily operations. Those are what decide who survives.

That changes what a good development partner should do. Our job is not just to write code. It is to make sure the code is worth writing, that it is the right size for where the business is today, and that it keeps working as the business grows.

We want clients whose businesses grow, because then we grow with them. That is the whole model.

Founder readiness checklist

These are the things we recommend a founder has in place before we start a build. They are guidelines, not a rigid test, and we are happy to discuss any of them. But the more of these you can tick, the better your chances, and the more useful we can be.

• Validated demand, with evidence. Not "everyone needs this", but proof: conversations with real customers, pre-orders or deposits, signed letters of intent from restaurants, drivers or service providers, or numbers from a manual pilot.
• A sales and marketing plan for the first 90 days, with a budget. Who are your first customers, which channels will reach them, and how much money is set aside to do it? We recommend that this budget exists separately from the development budget.
• An operations plan and runway after launch. Who onboards suppliers, who handles support and refunds, how payouts work, and how long you can keep going while the business grows. Launch day is the start of the costs, not the end.
• A named person accountable for running the business every day. Ideally the founder. If the founder has a full-time job elsewhere, someone else must own operations by name. Marketplaces do not run themselves.
• Realistic scope: MVP first. One city, one service, the features needed to take orders, dispatch, get paid and support customers. Everything else waits until the data asks for it.
• Willingness to iterate on data. You will be wrong about some things. That is normal. What matters is that you look at the numbers each week and change course without ego.

If you would like a deeper version of the demand part, our article Anyone Can Build an App Now. Can You Sell It? walks through how to test it before you spend on development.

Why each item matters

None of these is about technology. That is the point.

What we offer in return

If we are going to ask this much of founders, we owe them a lot back. Here is what you get from Joldisoft.

Honest advice, even when it costs us a sale

If we think you should validate first, we will say so. If we think a white-label platform will serve you better than a custom build, we will say so, even though the custom build is the bigger contract. If we think your plan has a gap, you will hear about it before you sign, not after you launch.

MVP-first scoping

We start small on purpose. A white-label platform with our configuration starts from $3,000 and can be live in two to three weeks. A custom MVP starts from $10,000 for ride-hailing, $12,000 for food delivery, $11,000 for home services and $14,000 for super apps. The aim is always the smallest version that lets you take real orders and learn from real data.

A stack chosen for the long run

For custom work, we build mobile apps in Flutter (with GetX) for Android and iOS from one codebase, web frontends and admin panels in React or Next.js, and backends in Node.js, or Go for ride-hailing where real-time dispatch needs high concurrency. Data lives in PostgreSQL, live updates run over WebSockets and push notifications go through Firebase Cloud Messaging. For maps we combine Google Maps with Mapbox, OpenStreetMap or HERE to keep costs under control as you grow. These are mainstream, well-supported technologies, so you are never locked into a niche tool only one company understands.

Long-term support

Every project includes support after launch: 30 days for white-label projects and 90 days for MVPs. After that, we offer ongoing maintenance, because apps need regular updates to keep up with Apple, Google, payment providers and security fixes. We would rather support one client for five years than build for five clients once.

Clarity on source code and licences

Before you sign, you will know exactly what you own and what you licence. For custom builds, that means where the source code lives and how you get access. For white-label platforms, that means which licence applies and what it allows. No surprises later.

What happens if you are not ready yet

Not being ready is not a rejection. It is a stage.

If you contact us and we think it is too early, we will tell you directly and explain why. Then we will suggest what to do next, usually some combination of:

• Running a manual pilot for a few weeks with a phone, WhatsApp and a spreadsheet.
• Collecting letters of intent from restaurants, drivers or service providers.
• Getting a small number of customers to pre-pay.
• Writing a simple 90-day launch budget that covers marketing and operations, not just the app.
• Narrowing the idea to one city, one service and one customer type.

This is not a lesser path. Paul Graham's well-known essay Do Things That Don't Scale argues that startups usually take off because founders push them by hand at first: recruiting early users one by one and doing manual work that software will automate later. A manual pilot is exactly that.

When you come back with that evidence, the conversation is completely different, and so are your chances. Many of the best founders we speak to are the ones who heard "not yet" and returned with numbers.

Why we put this in writing

We could keep these standards private and simply decline projects quietly. We publish them because founders deserve to know the rules before they spend time on a call, and because writing them down keeps us honest. If we ever take a project that clearly fails this checklist because the deposit looked attractive, this page is the standard you can hold us to.

It also saves everyone time. A founder who reads this and decides to validate first has not lost anything. They have gained a plan, and when they return, we can move quickly because the hard questions are already answered.

What this means if you work with us

If we start a project together, it is because we believe it has a real chance. That belief makes us more careful, more honest and more invested in your success. We will push back on scope. We will ask about your sales numbers. We will tell you uncomfortable things.

That is not us being difficult. That is us treating your money as if it were ours, because in a long-term partnership, in a way, it is.

Talk to us

If you have read this far and you can tick most of the checklist, we would like to hear from you. If you cannot yet, we would still like to hear from you, and we will tell you honestly what we think the next step is.

Either way, you will get a straight answer.