What to Prepare Before Your First Conversation With a Software Developer

A first conversation with a software developer works best when you walk in with the actual problem, not a polished pitch. Vendors who ask good questions can turn a rough, honest description of what hurts today into an accurate scope and a fair quote; vendors stuck guessing at an imagined feature list usually quote badly in either direction — too low, and the gaps show up later as change requests, or too high, padded to cover the uncertainty.

This is a practical pre-commissioning checklist: what to bring, who to involve, and what a developer actually needs from you to scope and price the work properly on the first conversation rather than the third. It assumes you have already decided a custom system is worth exploring; if you are still deciding whether to build at all, see signs your business has outgrown spreadsheets first. Once you are ready to commission, how long a custom system actually takes and who should build it cover the questions that come after this one.

Why "I want an app" or "I want a system" isn't enough to get an accurate quote

A developer cannot price what they cannot picture. "We want a system to manage orders" describes a category of software, not a project — it says nothing about how many orders, who enters them, what happens when one is cancelled, or whether the result has to talk to your existing accounting software. Two businesses saying the same sentence can need wildly different builds and prices.

The fix is not to learn technical vocabulary before the meeting. It is to arrive with the actual problem in enough detail that a stranger could follow it, which the rest of this guide is a checklist for.

Start with the pain, not the feature list

Before thinking about what the new system should do, name the specific thing that is going wrong today. Not "we need better inventory management" but "we re-enter the same stock count into three spreadsheets every Monday, and it is usually wrong by Wednesday." The second version tells a developer exactly what to fix and roughly how big the fix is; the first could mean almost anything.

• Name one task, not a department. "Sales needs a system" is too broad. "Sales reps text orders to the office, which gets typed into Excel by hand" is a brief.
• Say how often it happens and how long it takes. A problem that costs ten minutes once a week is a different project from one that costs two hours every day.
• Say what happens when it goes wrong. A missed order, a double payment, a customer who was never told their item was out of stock — the cost of the current mistake is often the real business case for the project.

Who will actually use it, and what each person does daily

A system is scoped around the people who will touch it every day, not the owner who commissioned it. Before the meeting, work out:

• Who, by role, not by name. Counter staff, warehouse staff, a single admin person, the owner checking a report once a week — each role usually needs a different view of the same system.
• How many people in each role, roughly. A tool used by two people tolerates more friction than one used by twenty.
• What each role actually does, step by step, with the current tools. Not what you wish they did — what they actually do, including the workaround nobody admits to out loud.
• Who decides if something looks wrong. The person who notices a mistake first is often not the person who can fix it, and a good system design accounts for that gap.

This matters because a system built for how the owner imagines the business running often gets quietly rejected by the staff who actually have to use it every day. Where it is practical, bring one person who will actually use the system daily to the first conversation, or at least have their answers ready secondhand; owners and daily users frequently describe the same process differently, and a developer benefits from hearing both versions before writing anything down.

Map today's process exactly as it runs now, not how it should run

Walk through the current process from start to finish, in order, including the parts that are awkward to admit to. A developer needs the real version, workarounds included, because the workaround is usually the exact thing the new system has to replace or absorb.

• Start to finish, in order. What is the very first thing that happens, and the very last?
• Every handoff. Each time the work moves from one person, tool or spreadsheet to another is a point where something can go missing or get re-typed with an error.
• Every workaround. A sticky note, a shared WhatsApp group, a spreadsheet nobody else knows exists — these are usually load-bearing, and a new system that ignores them tends to fail quietly on launch day.
• What "finished" or "correct" currently means. If nobody can say how you know an order was handled correctly today, that is useful information in itself.

It helps to literally write this down as a numbered list before the meeting, even roughly. A developer reading ten plain sentences in order learns more than one reading a polished paragraph.

What it has to talk to: existing tools, systems and data

Very few custom systems exist in isolation. List everything the new system needs to read from, write to, or at least coexist with:

• Accounting or invoicing software — does the new system need to create or read invoices, or just help someone enter data into the accounting tool faster?
• Point-of-sale, e-commerce or booking platforms already in use.
• Spreadsheets that are the current "system of record" for something, even informally.
• Communication tools the business runs on, such as WhatsApp Business, where orders or approvals currently happen.
• Accounts and logins involved, and who currently controls them.

You do not need to know whether a connection is technically possible — that is the developer's question to answer. You do need to know that the connection is needed, because a quote built without it is a quote that will need revising once the gap is discovered mid-project.

Bring real examples, not descriptions

A real document is worth more than a careful description of one. Whenever possible, bring the actual thing rather than explaining it from memory.

If a document contains real customer or financial details, blank out names and numbers before sharing it; the structure and fields matter far more than the specific values.

A rough budget range and target date

Say a range, not a precise figure, and say it early rather than waiting to be asked. A developer who knows you are thinking in the low thousands will suggest a different starting point than one who hears tens of thousands, and finding out the gap on the first call saves everyone a wasted proposal. Gotka's own App & System Development service lists indicative starting prices of RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations, and RM15,000 for mobile apps, each confirmed by a written quote once the scope is understood — useful as a rough sense of scale even before you have chosen a developer.

A target date matters for the same reason. "Before our busy season in three months" scopes a very different project from "whenever it's ready," and a developer needs to know which one you mean before suggesting what is realistic. Resist the instinct to lowball the figure in case it affects the price you are quoted; a budget stated honestly helps a developer propose a scope that fits it, while a figure stated low to test them usually just produces a proposal that has to be revised once the real scope becomes clear.

What a good developer should ask you, and what to ask them back

A first conversation works both ways. A developer who does not ask about your current process, your users or your budget range is either very experienced at reading between the lines or not asking enough questions; either way, you can prompt the conversation yourself with the material in this guide, rather than waiting to be asked for it.

Questions worth asking back, once they have heard your problem:

• "What would you need from me to give an accurate quote?" — a useful test of whether they are scoping carefully or guessing.
• "What's the riskiest or least certain part of this, from what I've told you?" — surfaces problems before they become change requests.
• "What pricing model would this be quoted under?" — see fixed price or hourly rate for what each answer means for your risk.

Once you have a written quote in hand, how to compare two custom software quotes side by side covers what to check before you sign, and freelancer, in-house developer or development company covers who should actually build it if that is still an open question.

Common mistakes

• Leading with a feature list instead of the problem. A list of features you imagine you need often misses the actual fix and adds ones nobody asked for.
• Describing the "ideal" process instead of the real one. The workaround you are embarrassed about is usually the most useful detail in the room.
• Leaving out who actually uses it daily. A system scoped around the owner's view often gets rejected by the staff who touch it every day.
• Forgetting a tool the new system has to connect to, discovered only mid-project.
• Hiding the budget range to "see what they say first." It wastes a round of quoting instead of protecting you.
• Showing up with no real example — only descriptions. A sample order or spreadsheet export says more in two minutes than ten minutes of explaining.
• Pretending to have an answer rather than saying "I don't know yet."

Where Gotka Technologies fits

Gotka's App & System Development service covers mobile apps, web apps and business systems, with indicative starting prices of RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations, and RM15,000 for mobile apps — each confirmed by a written quote once your process, users and connections are understood. Walking into that first conversation with the material this guide covers (the real pain point, the people who will use it, what it has to connect to, and a rough budget and date) is what turns a first meeting into an accurate quote rather than a guess.

Key terms used in this guide

• Scope: the written description of exactly what a system will do, which a quote is priced against.
• Discovery: an early stage, sometimes paid, where a developer studies your process in detail before quoting or building.
• System of record: whichever spreadsheet, tool or document currently holds the "real" version of information, even informally.
• Integration: a connection that lets a new system read from or write to an existing tool, such as accounting software.
• Change request: a feature or change raised after a scope is agreed, usually priced and scheduled separately.
• Workaround: an informal fix, such as a shared spreadsheet or a sticky note, that people use because the official process does not cover a real situation.