You have an idea for a tool your business could use. A calculator for your sales team, an interactive page for customers or a small dashboard for colleagues. You can picture what it should do. But between the idea and the finished product lies the code… so the project stays on the back burner.
Vibe coding can help you take that first step. You describe what you want to an AI, it generates code, then you try the result and request changes. Your idea becomes something tangible. It helps, however, to understand what this approach can do and what remains your responsibility.
What does vibe coding actually mean?
In everyday use, the term describes building software through a conversation with an AI. You explain your needs in plain language, then work through trials and corrections. The term covers different practices, though: experimenting without looking at the code and developing with AI while having that code checked involve different levels of oversight. Google Cloud explains this distinction.
Imagine you want to prepare for a sales meeting. You ask for a page with three fields: the prospect’s industry, their needs and the meeting’s objective. Once completed, the page should organise the information into a clear briefing sheet.
You try a first version. Is the form too long? Ask to remove a field. Is the briefing hard to read? Request a three-part layout. The conversation now centres on a result you can see and use.
Your knowledge of the job gives you a starting point
You already know things that matter when designing this tool. You know which questions to ask a prospect, which information is useful and which details get in the way during a meeting.
That knowledge helps you frame your request. “Build me a sales application” leaves plenty of room for assumptions. “Help a salesperson prepare for their first meeting with the head of a small business” gives a clearer direction.
Take the time to describe a real situation. Who opens the tool? When? What information do they have? What should they have achieved when they close it? Those answers form your first brief.
Which project should you start with?
Choose a limited task with a result you can easily check. For example, a preparation questionnaire, a calculator based on a known formula or a page that turns entered information into a printable sheet.
For your first attempt, use fictional data and a standalone workflow. You can focus on the user journey without immediately connecting your email or customer database.
A useful exercise is to complete this sentence: “This tool helps [a person] to [complete a specific task].” If your sentence becomes a list of ten jobs, narrow the scope.
A first version helps you ask better questions
An idea often seems obvious while it is still in your head. As soon as someone tries the tool, the questions become more concrete: where do I click, what should I enter and how do I go back?
Ask a colleague to try your prototype without explaining every screen. Watch where they hesitate. Ask what they expected to get. Their answers will be more useful than “it looks nice” or “the design needs updating”.
Keep additional requests for a second version. Your first objective is to check that the chosen task is handled correctly.
Can you then use it in your business?
That depends on what you have built and the consequences of an error. A demonstration page and an application that manages orders need different checks.
Before putting your tool to work, arrange checks of its functionality, access controls and data handling that match the stakes of the project. Also decide who will fix it and maintain it.
Have an idea waiting in the wings? Start by describing the task, the user and the expected result. You will already have done part of the work needed to build a first prototype.
Ready to try it? Discuss your project with eloRezo.