Preparing for a custom software project: the first meeting

Preparing for a custom software project does not start with a specification. All you need for the first meeting is a description of the problem the system should solve and of who will use it. It also helps to know what data the system will work with and which programs it has to connect to. Add the constraints: the deadline, a rough budget and who will maintain the application after launch.

With material like this, the conversation ends with specific questions, and after it we prepare a quote. The checklist works with us or with any other supplier. It covers only the first step; our article on the custom software development process covers the rest.

The first meeting shapes the quote

A software quote is, in practice, a quote for assumptions. If the assumptions are unclear, the supplier has two options: add a margin for the unknowns, or quote the simplest version and add the rest later. Either way, you lose. You overpay, or you get a project whose cost grows as it goes.

At Conetso, our design team and developers look at your problem together. We analyse the business problem, recommend a solution and only then prepare a quote. The initial consultation and requirements analysis are free of charge. We usually send a quote within 2 business days, and within 5 at the latest. This is how work on a custom web application begins.

Conetso Software is the software development team of Conetso Group, based in Lublin, Poland. The group also employs system and network administrators, so we ask about infrastructure at this stage too: where the application will run and who will maintain it. Our article on how much a custom web application costs explains what drives the price.

How do you describe the problem rather than a ready-made solution?

Start by describing what does not work today. The most common mistake is to arrive with a list of screens (“we need a panel with a table and an export button”). Answers to three questions help:

• What do you do today, and how long does it take? For example: “orders arrive by email, someone retypes them into a spreadsheet and then phones the staff”.
• Where do errors happen? Lost orders, double bookings, mismatches between the spreadsheet and the invoices.
• What should change after launch? One or two sentences about the outcome, for example “clients raise orders themselves, and the manager sees who is available”.

Here is a typical example. A service company came with requirements for a system to handle orders and manage staff. Our team suggested adding online payments and automatic invoicing. A suggestion like that is only possible when we understand the whole process. We describe a similar system in the Service Quotes case study.

Checklist before the meeting

You do not need answers to everything. Mark what you do not know; that is information too.

Area	What to prepare	Why we need it
Problem	3–5 sentences on what does not work today and what should change	We agree the project goal and how success will be measured
Users and roles	Who will use the system: staff, clients, partners, an administrator. Who may see and change what	The number of roles and permissions is one of the main price factors
Process	The steps from request to closing the case, with exceptions (“what if the client cancels?”)	Handling exceptions often takes more work than the main path
Data	Sample spreadsheets, forms and documents (with personal data removed)	We see what data the system has to store and whether it needs migrating
Integrations	What the system must connect to: accounting, CRM, payments, email, SMS, a line-of-business system	Each integration is separate work and depends on the other system’s documentation
Visual material	Screenshots of programs you like or dislike, existing wireframes if you have them	We agree expectations for the interface faster
Constraints	Deadline, rough budget, legal requirements (for example patient data), where the application will run	Without these, it is impossible to propose a sensible scope for the first version
Decisions	Who on your side approves the scope and signs off each stage	A project without a decision-maker stalls

Split features into “must have” and “nice to have”

Divide the features into two lists before the meeting. “Must have” is everything without which the system cannot replace the way you work today. “Nice to have” covers improvements that can wait for a later stage.

This split lets us propose a first version that goes live sooner. We quote the rest as further development. If you are wondering whether to build your own system at all or buy an off-the-shelf product, start with our article on custom vs off-the-shelf software, which explains when a system of your own makes sense.

What will we ask at the first meeting?

These are the questions we usually ask:

1. How many people will use the system, and will they include people outside your company (clients, partners)?
2. Will the system store personal data? If so, what kind (for example health data)?
3. What devices will users work on: an office computer, a phone in the field, a tablet?
4. Will the system take payments or issue sales documents?
5. Where should the application run: in the cloud, on your server, or do you have no preference?
6. Who will maintain the system after launch, and do you need technical support?
7. Is there a deadline that cannot move (a season, the opening of a new branch, the end of the contract for your current program)?

Questions 5 and 6 often come as a surprise. At deployment, we install the application on the target server, connect the domain and set up an encrypted connection. After that, we can train your team, provide technical support and set up database backup procedures. That is why we prefer to know these needs from the start, long before sign-off.

What to send before the meeting

Before the meeting, you can send:

• a short description of the problem (the body of an email is fine)
• sample files you work with today, without personal data; a few rows with made-up names are enough
• screenshots of your current program, or links to applications you like
• a list of systems the new one must connect to, with the vendor’s name and whether you have API access to them (an application programming interface that lets other programs exchange data with them)

There is no need to write a long specification. A document written without talking to the supplier often describes a solution instead of a need, and then has to be rewritten.

What you do not need to know before the meeting

You do not need to choose the technology, the database or the cloud provider. You also do not need to know how many screens the application will have. That is our job: based on your description, we propose the architecture and the scope. Our main stack is Next.js, React, TypeScript, .NET Core and PostgreSQL, but we match the technology to the project.

You do not need a final budget either. It helps, though, if you tell us roughly what budget is realistic for you. We can then propose an option that fits it straight away, without spending time quoting a version you would never order.

Send us a short description of the problem. We reply with questions first, and the quote follows.