Before You Brief a Software Vendor: The Questions We Ask in Discovery

Most owners contact a software house with a list of screens they want built: a login page, a dashboard, reports, notifications. That list is already an answer, and the vendor still has no idea what the question was.

At Arktik the first stage is called discovery. It runs one to two weeks and goes through the six questions below. Prepare those answers before you call anyone and the first conversation starts on the actual work, which also makes the written plan and fixed price at the end of it more accurate.

Why a feature list is the wrong thing to bring

A feature list comes from apps you have seen elsewhere. The items on it are often reasonable, but nobody in the room can judge whether feature number seven is worth paying for.

A vendor who takes the list at face value will quote for the whole list, and you have no grounds to cut it, because no question has been asked that would let you weigh one item against another.

The questions below start a step earlier, from the work that currently stalls. Build the feature list after that and it gets easier to write, and you can see which parts can wait for a later stage.

Which decision or process is actually hurting

Name one moment when the work stops. Maybe the quote goes out two days after the customer asked for it, or the Monday summary gets rebuilt by hand because nobody trusts the stock figure until someone walks the warehouse and counts.

Pick one moment, not five, because the scope of the first stage and its price both follow from it. The other moments still get recorded in discovery and placed in the order of later stages; they simply do not get opened in stage one.

If choosing is hard, use this measure: which process most often has you apologising to a customer, or most often forces a rushed decision on numbers you do not trust. What a badly specified build costs is a separate subject, covered in our post on the hidden cost of poor software choices.

Who touches it every day

Software survives when it fits the person doing the work, so list everyone who will open it daily, with their role next to their name.

The list is usually short: two admins entering orders, one warehouse person logging goods out, a shop lead who checks the afternoon summary. Beside each role, write what they open first in the morning and what they do straight after.

Note the hardware too. Your admin may be working from a mid-range Android phone, and the warehouse person opens it with their hands full, so both of them need a different screen from the one on your laptop. Record what they are actually using. At the end of every stage there is something you can open and use, which means daily users can test it from their own phones.

What it runs on now, and where the data really lives

Answer honestly, including the embarrassing parts. The current system is normally a mixture: one master spreadsheet, a WhatsApp group where orders arrive, a point-of-sale app, accounting software, and one person who remembers rules that are written down nowhere.

That last part is what briefs miss most often. The unwritten rules are usually about special prices approved in a chat, the order deliveries get prioritised in, and which customers are allowed to pay late. All of it sits in one person's head, and a vendor will not find it alone.

So write down who that person is and which decisions only they can make. If they take a week off and some piece of work stops moving, record what stops. That note is material we go through in discovery.

Whether something off the shelf already covers it

If your problem is solved by a tool sold on a monthly subscription, we will say so, and you spend nothing on a build. Custom software is expensive, so building it has to be the right call.

Check for yourself first. Open the reports menu in the apps you already pay for and see whether the number you need is sitting in there. Then ask whether the problem is really the software, or a sequence of work nobody has ever agreed on.

Put the same question to every vendor you meet: do you think an off-the-shelf tool already covers this? Watch who answers it and who redirects the conversation to the merits of their own system. The answer shows you how a vendor works before you have paid them anything.

Who owns the accounts, the domain and the data

Settle ownership before a line of code is written. The question is simple: who holds the domain account, the hosting account, the email accounts, and the third-party service accounts the system will use.

On our projects, the code, servers, domain and every account are in your name from day one, with nothing waiting for handover. If the engagement stops halfway, nothing depends on us continuing.

Prepare a list of the accounts you already hold, including the ones someone else set up for you years ago. In discovery we record the accounts whose passwords you do not have, then move those into your name before any new work starts.

What stage one has to deliver, and what it costs to stop there

Discovery runs one to two weeks and produces a written plan with a fixed price. That document is yours whether you go on to a build or not, and you can take it to another vendor for comparison.

After that, the scope and price of each stage are agreed in writing before that stage begins. You can stop after any stage without an argument, so what you risk in trying us is one stage.

Before you agree to anything, ask for two things in plain terms: what you can open and use at the end of the stage, and what you hold if you stop there. Ask as well whether you can put the reasoning behind each decision to the engineer who wrote the code. At Arktik you talk to the engineers doing the work. Nothing is subcontracted, and nobody is swapped out after signing.

A one-page prep checklist

Write the answers to those six questions on a single page. Format does not matter and it does not need to be tidy, as long as someone else can read it.

Then get four things ready to bring to the first conversation:

• A sample of the spreadsheet or notebook in use now, as it is, with nothing cleaned up.
• The list of daily users with their roles and the devices they work from.
• The accounts you already hold: domain, hosting, email, subscriptions.
• The budget ceiling you will not cross, including your estimate of the monthly cost after launch.

That last number often gets held back for fear a vendor will use it to raise the price. Because the scope and price of each stage are agreed in writing before the stage starts, the ceiling is used to choose what goes into stage one rather than to adjust what stage one costs. Without it, the plan you receive can be a good plan that you could never pay for, and finding that out in week one is better than finding it out later.

If this piece of work sits inside a larger plan to get off spreadsheets, the order of the stages is set out in our digital transformation roadmap for SMEs.

Bring your six answers to the first call

You do not need a technical requirements document or a view on which technology fits. Bring the one page, and we will work out which process deserves fixing first. The first call is free and there is no deck.

If an off-the-shelf tool already solves it, we will say so. If something does need building, discovery gives you a written plan and a fixed price within one to two weeks, and that document is yours whatever you decide afterwards. Use the contact form, which opens WhatsApp, or email hello@arktik.id.