The first call

The first call decides more about a project than any later meeting. In it we find out whether there is a feature worth building, what it would need, and whether we are the right people to build it. You do not need to prepare anything. But if you have read this list beforehand, the hour goes further.

None of these questions is a test. “We don’t know yet” is a perfectly good answer to most of them. Finding out is part of the first weeks of work.

Who should be in the call

The most useful calls have two kinds of people in them. One is the person who owns the problem: the head of support, the operations lead, the product manager whose users are asking for the feature. The other is someone who knows the systems the feature would touch, usually a developer or an IT lead. With both in the room, a question like “where do the contracts live, and who may read them?” gets a real answer instead of a promise to find out.

From our side it is the person who would design and build the feature. There is no separate sales call first, so nothing you say gets lost on its way to the people doing the work.

The goal

• What should be different for whom when this feature works? “Support answers faster” is a start. “New staff can answer holiday questions without asking HR” is better.
• How would you know it works? What would you count, before and after?
• What happens today without it? Who does this work now, how long does it take, and what goes wrong?
• Why now? Is there a deadline, a customer request, a competitor, or a cost that keeps growing?

We push on the goal more than anything else, because a feature with a vague goal cannot be tested, and a feature that cannot be tested cannot be improved.

The users

• Who will use it: your staff, your customers, or both?
• How many of them, and how often? A tool used by twenty people every day is a different build from one used by twenty thousand people once a year.
• Where will they use it: inside your product, in a chat tool they already use, by email?
• What do they know already, and what language do they write in?

The data

• Where does the information the feature needs live today: documents, a database, a ticket system, people’s heads?
• What format is it in, and how messy is it? Scanned PDFs, spreadsheets and old wiki pages are all fine, but each changes the work.
• How often does it change, and who changes it?
• Who is allowed to see what? If some users may not see some documents, the feature must respect that from the first version.
• Do you have examples of real questions or real cases we could build a first test set from?

The rules around it

• Does the data have to stay in the EU, or in your own cloud account?
• Are there contracts, regulations or internal policies about which AI providers you may use, and how?
• What must the feature never do or say? Every business has a few of these, and they become checks in the code.
• Who has to approve the project internally: security, legal, a works council?

What already exists

• What is your stack, and where does it run?
• Do you have developers who will work on this with us, or run it after us?
• Have you tried something already? A prototype that did not work out tells us a lot, so please bring it.

What failure looks like

We always ask what the worst realistic mistake would be. A wrong answer about the opening hours of a shop is an inconvenience. A wrong answer about a medication dose or a contract term is something else. The answer to this question decides how many checks the feature needs, where a person must approve, and how carefully we roll it out.

Whether AI is the right tool

Some problems are better solved without a language model: a better search box, a rule in the code, a clearer form, a missing page in the documentation. If that is the case, we say so in the call. It is cheaper for you to hear it then than after a project.

What we tell you in the call

The call is not only us asking. By the end of it you should know how we would approach the feature, what we think the hardest part is, which parts we would test first, and roughly what kind of project it is: a few weeks for a first version, or something larger that needs a discovery phase. If we think the idea has a serious problem, such as data that cannot legally be used or a goal that cannot be measured, you hear it in the call, not in the proposal.

You can also ask us anything: how we work with your developers, who owns what we build, which providers we would use and why. The answers to the common ones are on our questions page, but it is better to hear them for your case.

What you get after the call

Within a few working days of the call, we send a written proposal. It describes what we understood, what we would build first, how we would measure it, what we need from you, the timeline and the price. If something in it is wrong, we correct it before anything starts. The call itself costs nothing.

If you have a feature in mind, write a few lines about it. We reply within one working day, usually with a time for this call.