Building fast: code, no-code and ready-made tools

Building the MVP

Choosing tools that get a first version out in weeks, not months.

You know what an MVP is. Now, how do you build it? At this stage many founders spend far too long choosing technology: which language, which framework, which server. For a first version there is one main criterion: which path lets you learn fastest?

Speed beats elegance

How beautiful the code of your first version is does not matter to customers. They care whether the product solves their problem. Choose tools your team knows well, even if they are not the newest. Learning a new technology while building a product is twice as slow.

Options

No-code tools: form builders, spreadsheets, website builders, automation services. With them you can test a lot without a developer. The downside: once the logic gets complex, you hit their limits.
A Telegram bot. In Uzbekistan many people spend all day in Telegram. Building a bot is relatively simple, and the user does not have to download anything. A good choice for orders, reminders and sign-ups.
A simple web app. A plain site built with technology your team knows is enough in many cases. Make sure it works on phones, because most of your customers will come from one.
A mobile app. Only when it is really needed: for example, if the camera, location or constant notifications are the heart of the product. Building an app and getting it into the stores takes more time.

Payments

If your product needs to take money, you can integrate local payment systems such as Payme and Click. But do not rush this at the start. Taking payment by hand from your first ten customers, through a payment link or an invoice, works fine. Integrate once the number of payments becomes impossible to handle by hand. Find out the formal requirements for accepting payments, and the tax questions, from an accountant beforehand.

Use ready-made services

Sending SMS, sending email, hosting, analytics, a customer support chat: ready-made services exist for all of these. Do not rebuild them yourself. Spend your time only on the part that makes your product different from everyone else's.

Technical debt and security

Writing imperfect code at the start is normal. It is called technical debt, and you pay it back later. But some things should never be left as debt:

protecting users' passwords and personal data;
regular backups of your data;
controlling who can access which data.

There are rules on collecting and storing personal data. Check with a lawyer which ones apply to you, especially if you collect sensitive information about your customers.

Hire a developer or build it yourselves

The best case is when one of the co-founders can build the product. Then changes go in fast, and something you heard from a customer can be in the product the same day. If there is no such person, start with an independent specialist on a project basis, and make sure the contract says you fully own the code. Handing the whole product to an outside agency is risky: every change needs a place in their queue and more money, and the company ends up not understanding its own product.

A checklist for the first version

Before you give the product to customers, check that:

It works on a cheap Android phone and on slow mobile internet.
The text is in your customers' language and has been read by someone who speaks it natively.
Basic analytics are in place: you can see when the main job gets done.
The way to get help is visible, for example your Telegram account.
Data is backed up, and you have tried restoring from a backup at least once.
You can make a small change and get it to customers within a day.

Try this

List every tool your MVP will need: what you will build yourselves, what you will take from a ready-made service and what you will do by hand. Write down how many days each part will take. If the total runs past a month, look again at which parts could be done by hand.