What You Need Before You Start a Tech Business: A Checklist

Building the app is the easy part

I will not tell you that your idea will change the world. I will tell you what I see from the other side of the table.

In the AI era, anyone can build software. Frameworks, ready-made platforms, freelancers and AI coding tools have made "getting an app built" cheap and fast. That is exactly why the app is no longer your advantage. What decides whether your business lives is whether you can sell, bringing money from customers' pockets into yours, and whether you can operate: supply, support and cash flow, every single day.

So do not rush to spend money on an app. If your business cannot survive the first months after launch, the money you pay any developer, including us, creates no value. The company closes, the app sits in the store with no users, and you walk away demotivated, convinced tech is not for you. Usually the problem was never the tech.

The data agrees. CB Insights' 2026 analysis of 431 venture-backed companies that shut down since 2023 found that running out of capital was a factor in about 70% of the cases where a reason could be identified, and poor product-market fit in 43%. Bad timing and unsustainable unit economics followed. Almost none of it was about the technology itself.

This checklist covers what to sort out before and during your first build, whether you are in Dhaka, Lagos, Riyadh, Jakarta or Denver.

Reality check before you spend a dollar

Answer these honestly, on paper. If you cannot, stop here and work on the answers first.

1. Validate the problem

Start with the problem, not the product. You want evidence that a specific group has a painful, frequent problem and is already trying to solve it, badly.

• Talk to 20 to 30 potential customers about their current behaviour, not your idea. "How did you get to work last week? What went wrong?" beats "Would you use a ride app?"
• Look for existing spending. If people already pay for a call centre, a WhatsApp group or a middleman, you have a strong signal.
• Run a manual version. Gojek famously started as a call centre connecting customers with motorbike taxi riders before it had an app. Taking orders by phone for a few weeks teaches you more than any survey.
• Ask for commitment. A pre-order, a deposit or a letter of intent is worth more than a compliment.

Y Combinator's Michael Seibel describes an MVP as the first, simple thing you can give your very first users to see whether you can deliver any value at all. You can often learn that without writing code.

2. Market research

• Who are the customers? Define a specific first segment: a city, an industry, a type of user.
• How big is it? Estimate bottom-up: customers in your first city multiplied by how often they buy and what they pay. "1% of a billion-dollar market" is not useful.
• Who else is there? Direct competitors, indirect alternatives (including doing nothing) and global players who could enter.
• Why now? What has changed that makes this the right time?
• What rules apply? Transport, food safety, payments, data protection and employment rules vary by country and can shape your entire model.

3. Business model and unit economics

A business model answers "who pays, for what, and how much?" Unit economics answers "do we make money on each order or customer once it is running?"

If contribution margin is negative even in your optimistic case, change the model before you build: different pricing, segment or service. CB Insights lists unsustainable unit economics among the top failure reasons, so this is not an academic exercise.

4. Legal entity and compliance

• Choose a structure. The US Small Business Administration notes that your business structure affects everything from taxes to personal liability, and that registering a separate legal entity can protect your personal assets. Most countries have equivalents of LLCs and corporations.
• Decide where to incorporate. Some founders in emerging markets incorporate where their investors or payment providers are and operate locally. Get advice on tax, banking and local requirements.
• Get local licences, tax registration and sector permits for transport, food or financial services.
• Write the founder agreements: equity, vesting and roles, before there is anything valuable to argue about.
• Prepare your policies: terms, privacy, refunds, and agreements for drivers, merchants or providers.

Use a local lawyer and accountant. Cutting corners here creates expensive problems later.

5. Budget and runway

Runway is the number of months you can operate before money runs out. Since running out of capital is the most common factor in startup failure, treat runway as a product decision. The SBA recommends calculating your startup costs before you seek funding. For a tech business, include:

Two rules: do not spend most of your budget on the first build, because acquiring customers and iterating usually matters more; and plan for at least 12 months of runway, or know exactly when and how you will raise more.

6. Team: who builds it?

Whatever you choose, your company must own the source code, the developer accounts, the domain, the servers and the data.

Insider tips: building an MVP cheaply and safely

When freelancers from Fiverr or Upwork make sense. For a landing page, a clickable prototype, a design, a small admin tool or one well-defined feature, a good freelancer is often the cheapest sensible option. For a multi-app marketplace with real-time tracking, payments and a backend that must stay up, one freelancer is a single point of failure. Use freelancers for pieces, not for the whole platform, unless you have someone technical who can manage them.

How to vet a freelancer or agency:

• Portfolio you can touch. Live apps in the stores or running websites, not screenshots. Ask what exactly they built.
• A small paid test task. One or two days of real work on your project tells you more than any interview.
• Milestone payments held in escrow. Platforms such as Upwork let you fund a milestone and release the money only when you approve the work. Outside a platform, tie payments to delivered, demonstrable milestones.
• Code ownership in writing. The contract says the code and intellectual property transfer to your company on payment.
• Repository access from day one. The code lives in a Git repository your company owns, and the developer pushes to it as they work. If you only see the code at the end, you may never see it.
• CI/CD. Ask that builds run through an automated pipeline, so the app can be rebuilt and released by anyone, not only on one laptop.

Choose a mainstream stack. The safest choices are the ones with the most developers available to hire: Flutter for mobile apps, React or Next.js for the web, Laravel or Node.js for the backend, and PostgreSQL or MySQL for the database. An exotic language, a niche framework or a developer's home-made platform may look clever, but when that developer leaves you will struggle to find anyone who can maintain it, and you will pay to rewrite it.

Keep infrastructure boring. A reliable VPS is usually enough for an early MVP. You do not need a multi-region cloud architecture before you have a hundred customers.

7. MVP scope

Your MVP should test your riskiest assumption with the least possible work. Y Combinator's advice is to build something in weeks, not months, launch quickly, talk to users and iterate.

1. List every feature you want.
2. Mark each as must have to deliver the core value, nice to have or later.
3. Cut everything that is not a must-have. Then cut again.

For a ride-hailing MVP the must-haves are booking, matching, live tracking, fare calculation, payment and an admin panel. Loyalty programmes, multiple vehicle tiers and in-app chat can usually wait.

8. Go-to-market

Paul Graham's essay "Do Things That Don't Scale" makes a point every founder should take seriously: early on, you recruit users manually, one by one. Products rarely take off on their own.

• Where are your first 100 customers? One neighbourhood, one campus, one industry.
• How will you reach them? Direct sales, partnerships, community groups, referral incentives.
• For marketplaces, which side first? Usually supply. Customers who find no drivers or restaurants rarely come back.

9. Metrics

Set up analytics from day one: activation (sign-ups who complete a first order), retention by week and month, order frequency, contribution margin per order, CAC and payback, marketplace health (fulfilment rate, wait times, cancellations) and cash (monthly burn and months of runway left). Retention is usually the most honest signal of product-market fit. If people do not come back, more marketing will not fix it.

The founder's pre-launch checklist

• I have spoken to at least 20 potential customers about the problem, not my idea.
• I have sold something, even manually, or have firm commitments to pay.
• I have a specific first customer segment and city.
• My unit economics show a positive contribution margin in a realistic case.
• My company is registered, with founder agreements, policies and licences.
• I have at least 12 months of runway after launch, or a dated funding plan.
• A named person is accountable for daily operations.
• My company owns the code, repository, accounts, domain and data from day one.
• The build uses a mainstream stack and runs through CI/CD.
• My MVP scope tests the riskiest assumption and can launch in weeks.
• I have a plan for my first 100 customers and, for a marketplace, my first supply partners.
• I have a maintenance budget for after launch.

When Joldisoft is, and is not, the right partner

Joldisoft builds ride-hailing, food delivery, home services, super app and e-commerce products for founders, mainly in emerging markets. We are a US LLC registered in Montana, with our engineering office in Dhaka, Bangladesh. White-label launches start from $3,000 and typically take two to three weeks. Custom MVPs start from $10,000 to $14,000 depending on the product, include 90 days of support and come with the source code handed over to you. Our custom work uses a mainstream stack: Flutter for mobile, React or Next.js for web and admin panels, Node.js (and Go for ride-hailing dispatch) on the backend, and PostgreSQL.

We are useful at steps 6 and 7, once the earlier steps are done. We do not build for everyone. We work with founders who come with validated demand, a sales and marketing plan, an operations budget and runway, and someone accountable for running the business. That is because we want long-term partners whose businesses grow, not one-off projects that close in month four.

If you are still at step 1, do not hire us yet. Talk to customers and sell something by hand. If you have done the work and are ready to build, see our MVP development service, our page for startups, or get in touch.