Have a business idea? Here is what to build before you hire developers

Why prepare anything before hiring developers?

Because developers build exactly what you describe, and most first descriptions are vague. 'An app like Uber but for mama mbogas' is a vibe, not a brief. Give a developer a vibe and you get a quote that is either wildly high (they priced in the unknowns) or suspiciously low (they did not).

Every question answered on paper is cheaper than the same question answered in code. Changing a sketch takes five minutes. Changing a finished screen, its database and the three other screens that depend on it takes days, and days are billed.

1. Write the problem in one sentence

Not the solution. The problem. 'Salon owners lose bookings because clients DM on three platforms and nobody tracks them' is a problem. 'A booking app' is a solution, and possibly the wrong one.

If you cannot say the problem in one sentence, the product will try to solve five problems at once, and it will solve none of them well. Write it down. Stick it on the wall. Every feature later has to serve that sentence or leave.

2. Describe exactly who will use it

'Everyone' is not a user. Name the actual people: the salon owner, the stylist, the client booking from her phone at lunch. For each one, write what they are trying to get done and what device they will use.

This changes the build more than you would think. An owner checking reports on a laptop needs something different from a client with a budget Android phone and 200 bob of data. If staff will use it, ask them how they work today. They know where the pain is.

3. Map the one journey that matters most

Pick the single most important thing a user does and write every step: opens the link, picks a service, picks a time, pays the deposit via M-Pesa, gets a confirmation. That is your core flow. If this journey works beautifully, you have a product. If it does not, nothing else matters.

Keep it to one journey for now. Admin panels, referral programmes and loyalty points can wait their turn.

4. List the features, then cut the list in half

Write down every feature you dream of. Get it all out. Then split the list into two columns:

Be ruthless. A feature belongs in the left column only if the core journey breaks without it. We go deeper on this in why your first product does not need every feature.

5. Sketch the key screens

Pen and paper is fine. Boxes for buttons, lines for text. Draw the three to six screens your core journey needs. You are not designing, you are thinking out loud with shapes.

Sketches expose gaps fast. You will draw the booking screen and realise you never decided what happens when a slot is taken. Better to find that now than in week four. When you are ready for real design, that is what UI/UX and digital experience design is for.

6. Decide your budget range before you ask for quotes

Developers are not trying to be mysterious when they ask your budget. The same idea can be built as a small first version or a sprawling platform, and the budget decides which one makes sense.

Give a range and say what is fixed: the launch date, the must-have list, the amount. At CEKAL CREATIVES a first version of a business system costs KSh 20,000 to 35,000, and the full breakdown is in business software costs in Kenya. Hosting and third-party fees, such as SMS or payment charges, are extra wherever you build.

What should you not build before hiring developers?

• A 40-page requirements document nobody will read.
• A logo, a company registration and a pitch deck before you know anyone wants the thing.
• A 'perfect' design of every screen, including settings pages for features that do not exist yet.
• A no-code prototype so complex it becomes the product you are stuck maintaining.

Prepare enough to explain the idea clearly. Then let the people who build for a living help you shape it. If you want to pressure-test the idea first, read before you build it, question it.

What does a good handover to developers look like?

One or two pages, covering the problem sentence, the users, the core journey, the feature list in two columns, your sketches (photos are fine) and the budget range. That is it. A developer who receives that can give you a real quote, ask sharp questions, and suggest what to cut.

Send it to two or three teams and compare how they respond, not just the price. The team that pushes back on your feature list is often the one worth hiring. When you are ready, start a project inquiry and attach what you prepared.