// docs

The Consultation: Why It Matters

I don't start with a quote. I start with a conversation.

Sending a price before I understand your workflow is like writing a prescription before the examination. It might land on the right answer by accident, but you wouldn't bet your health on it.

The consultation exists because AI projects fail when they start from assumptions. Someone reads about what AI can do, pictures it in their business, and asks for a quote. The vendor, wanting to close the deal, sends a number. Both sides are guessing. Three months later the system doesn't match reality and everyone's frustrated.

We skip that whole failure mode by starting with Discovery.

There's one more reason I start here. AI isn't a universal solution. Some processes benefit enormously from it. Others don't at all. And a surprising number of processes that look like perfect candidates turn out to have complications that make AI impractical — at least until certain prerequisites are met.

The only way to know which category your process is in is to examine it properly. That's what Discovery is.

What happens during Discovery

Discovery is a structured process, not a loose chat. It has a defined format, defined goals, and a defined output.

Session 1: mapping your current situation (60 minutes)

This is where I build a real picture of how your business runs day to day. Not the org chart, not the mission statement — the actual work that actual people do with actual tools.

We cover five areas:

What you do manually each week — task by task, not "a lot of things."

I need specifics. "We handle client inquiries" isn't enough. "Maria spends 3 hours every Monday morning reading emails from the contact form, sorting them into sales leads, support tickets, and spam, then forwarding each one to the right person with a short summary" — that's what I need.

The reason for that level of detail is simple: AI is good at specific, repeatable tasks. It's bad at vague, undefined responsibilities. The more precisely you describe the task, the more accurately I can tell you whether AI can handle it.

Don't worry about organizing this perfectly before the session. I'll walk you through it. But the more concrete you come, the more useful my assessment will be. A list of tasks with rough time-per-task is gold. A vague sense that "things are inefficient" gives me very little to work with.

Where you lose time — specific minutes and hours, not "too much."

"We waste time on admin" tells me nothing. "Our sales team spends about 6 hours a week copying data from email conversations into the CRM, then another 2 hours writing follow-ups based on that data" tells me everything.

I'm looking for time sinks that have a pattern. If the same kind of work happens daily or weekly and has a similar shape each time, that's an AI candidate. If it's different every time and needs judgment that shifts with context, it might not be.

Here's a useful exercise before the session: pick one week and actually track your time on the process you want to improve. Write down every step, every decision, every handoff. You'll be surprised how much time goes into things you do on autopilot. That time log becomes the map.

What tools you use today.

I need to know your stack. Email provider, CRM, document storage, communication tools, spreadsheets, databases, project management — all of it. Not because I'll integrate with everything, but because integration complexity is one of the biggest cost drivers in AI projects. Knowing your tools upfront lets me estimate accurately.

A common surprise: many popular business tools only offer API access on their higher pricing plans. If you're on a basic plan and the integration needs API access, that's an extra cost on your side that we have to account for in the estimate. Better to know that during Discovery than during the build.

What you've tried before and why it didn't work.

This question saves more time than any other. If you've already tried a Zapier automation and it broke on edge cases in your data, I need to know that. If you hired a freelancer to build a chatbot and it couldn't handle questions outside its training data, I need to know that too.

Previous failures are data, not something to be ashamed of. They tell me exactly where the hard parts are, and they keep me from repeating the same mistakes.

What success looks like — in concrete, measurable terms.

"We want things to be more efficient" isn't a success criterion. "We want the time spent on email classification to drop from 6 hours a week to under 1 hour, with accuracy above 90%" — that's a success criterion.

Defining success in measurable terms protects both sides. You know exactly what to expect. I know exactly what to build toward. And when the project's done, there's no argument about whether it worked — we check it against the agreed criteria.

If you're not sure how to define success in measurable terms, that's fine. I'll help you during the session. But come thinking about it. "Better" isn't measurable. "From 6 hours a week to 1 hour" or "from 80% accuracy to 95%" is measurable.

Session 2 (optional): deep dive into a selected process

If Session 1 turns up a strong AI candidate, I sometimes schedule a second session devoted entirely to that process. Not every Discovery needs Session 2 — sometimes Session 1 gives me everything I need. But for complex processes with many edge cases, the real understanding happens in the second session.

Analysis of real examples. We look at actual documents — real emails, real reports, real data. Not polished samples, not hypothetical scenarios. The messy version. I want to see the email with the badly formatted attachment, the invoice missing half its fields, the client request that doesn't fit any of your existing templates.

Why? Because that's what the AI will hit in production. If I build the system on your best examples, it'll work perfectly on your best examples and fall over on everything else.

Identifying edge cases. Every process has a "normal path" and a collection of exceptions that make the normal path complicated. The client who replies in another language. The invoice formatted differently from all the rest. The request that doesn't fit any existing category. The email that's technically a complaint but reads like a compliment.

Those edge cases are where simple solutions break and where good ones prove their worth. I ask: "What's the weirdest thing you've had to handle in this process?" and "What makes your team say 'oh, this one's going to be tricky'?"

The edge cases identified in Session 2 directly shape the spec. They determine how much the project will cost and how long it will take.

Preliminary assessment. At the end of Session 2, I give you one of three answers:

AI makes sense — this process is a good candidate and we can estimate scope, timeline, and cost.
AI doesn't make sense — this process has characteristics that make AI a poor fit right now. I explain why.
AI makes sense, but not yet — the process needs preparation first. Maybe the data has to be structured, or the workflow standardized. I tell you exactly what to fix and when to come back.

What I do NOT do during Discovery

I don't pitch. I won't show you an AI demo with the line "imagine this in your business." Demos are built to impress, and impressive demos lead to unrealistic expectations.

I don't oversimplify. If the answer is "it depends," I explain what it depends on instead of giving you a confident-sounding wrong answer.

I don't commit to a solution during the session. Discovery is about understanding the problem. The solution comes in the specification phase, once I've had time to think through the architecture properly. Snap decisions made on a call are how bad systems get built.

I don't record the session without your permission. If I do record it (for my own notes), the recording is never shared outside the project and is deleted once the assessment is written.

What you get from the consultation

After Discovery you get a written document. Not a slide deck, not a verbal summary — a written assessment you can share with your team, come back to later, and use as a basis for decisions.

The assessment includes:

Which processes are suitable for AI and which aren't (and why). For each process we discussed, you get a clear verdict. Not "everything can be improved with AI" — that's a sales line. Some processes are great candidates. Others are poor fits. And for each one I explain the reasoning, so you can judge the logic yourself.

A prioritized roadmap. Where to start, what to skip for now, and what to revisit later. I recommend starting with the process that offers the best combination of impact and feasibility — not the one that sounds most impressive. A process that saves 2 hours a week but is straightforward to automate is a better first project than one that saves 10 hours but has dozens of edge cases that would take months to handle.

A preliminary estimate. Scope, timeline, and a cost range for the recommended first project. That's a range, not a fixed quote — the exact number comes after the Specification phase. But the range is honest. I don't lowball to get you started and surprise you later. If the preliminary estimate says 1,500-2,500 PLN (the typical range for a single install), the final quote in the spec will be in that area. If something in the spec raises the price, I explain why before you commit.

A clear answer. One of three:

"Yes, this makes sense. Here's what I recommend as a first project."
"No, not now. Here's why and here's what would need to change."
"Yes, but start with Y first. Here's the preparation you need to do before AI will work for you."

The assessment is yours. You can take it to another vendor, share it with your team, or put it in a drawer and come back to it in six months. No expiration date, no strings, no sales pressure.

What the assessment does NOT contain

No generic advice. "You should explore AI in your business" is something you can read on any blog. My assessment contains specific processes, specific estimates, and specific recommendations.

No technology recommendations for their own sake. I don't suggest tools because they're trendy. I suggest them because they solve the problem you described.

No inflated estimates of time or money saved. I estimate conservatively. If an email classification process saves "probably 4-6 hours a week," I write "4 hours" in the assessment, not "6+." Underdelivering on expectations destroys trust faster than anything else.

Why the consultation is free

This is the question I get most often, and the answer is simple.

If I find that AI isn't the answer, I'll tell you. I don't charge for honesty. I don't make money on consultations. I make money on good projects. And good projects only happen when both sides understand the problem before building the solution.

A bad consultation leads to a bad spec, which leads to a bad build, which leads to a failed project, which leads to a wrecked reputation.

Think of it as risk reduction for both sides. You invest 60 minutes of your time. I invest 60-120 minutes of mine. In exchange, both sides know whether the project makes sense before anyone commits money or significant time.

Mapping your workflow in detail often reveals inefficiencies you can fix with no technology at all. If Discovery reveals your process isn't ready for AI, you've lost an hour. Without Discovery you could lose weeks and thousands of zloty on a project that never had a chance.

What you should prepare

The quality of the consultation depends directly on the quality of the information you bring.

Real examples of the process you want to improve. Actual documents, actual emails, actual data. Messy is fine — actually preferred. I need to see the real thing, not a cleaned-up version. If your emails have typos, attachments in random formats, and replies in broken English — show me that. Because that's what the AI will face.

Bring 5-10 examples. Not the best ones and not the worst — a representative sample.

A list of the tools you currently use. Write it down before the session. Email provider, CRM, document storage, project management, spreadsheets — everything tied to the process you want to improve. Include the specific product names and, if you know them, the pricing plans.

60 minutes of focused time. No multitasking. No checking email during the call. We cover a lot in 60 minutes and every interruption costs us a context switch.

A rough idea of your budget. You don't need to know exactly how much you want to spend, but a ballpark helps. If you're tight on budget, I'll point you to a single install or a skill. If you have more room, we can look at the hybrid package. Knowing your range upfront means we won't waste time speccing a project that doesn't fit your budget.

Openness to an honest assessment. I might say "this isn't ready for AI yet" or "this process needs to be standardized before automation makes sense" — and sometimes "you'll get a better return on a part-time assistant than on an AI system."

If you're looking for someone to validate a decision you've already made, I'm not a good fit. If you're looking for someone to give you an honest assessment, even when the honest answer isn't what you wanted to hear — that's what I do.

A note on confidentiality

Everything you share during Discovery — your processes, your data, your problems, your numbers — is confidential.

I don't discuss one client's business with another. I don't use your examples in marketing without explicit written permission. I don't mention you as a client without your consent. And I don't keep your data after the assessment is written and delivered.

If you want a formal NDA before the session, just ask. I'll sign it before Discovery begins. Details on the legal page.

After the consultation: next steps

Discovery ends with one of three paths. There's no pressure to decide on the spot — take the assessment, review it, talk it over with your team. I'll send one short follow-up email, and after that the move is yours.

Path 1: "Yes, this makes sense."

I write a functional spec. That takes 3-5 working days and covers every detail of the project: what I'll build, how it'll work, what it won't do, how you'll test it, and what it'll cost.

You review the spec. We resolve any questions or disagreements in writing. Nothing moves to build until both sides agree on the spec. If you want to share the spec with your technical advisor, your business partner, or your in-house developer — go ahead. The more people who agree on what we're building, the fewer surprises during the build.

The timeline from Discovery to a live system depends on the install you choose: a single openclaw or hermes install is 5-10 working days once the build starts; the hybrid package is 2-4 weeks. I give you the exact estimate as part of the spec. More on that in the process documentation.

Path 2: "Not yet."

I tell you exactly what needs to change before AI becomes a real solution. Maybe your data needs to be structured differently. Maybe your process has too many exceptions that need standardizing first. Maybe you handle 10 inquiries a week and a simple email template would solve 80% of the problem at a fraction of the cost of an AI system.

I write that down with concrete action items and a suggested timeline for revisiting it. Not vague advice — specific steps. "Standardize your report template to include these 7 fields. Use it consistently for 3 months. Once you have 50+ reports in the new format, come back and we'll automate the generation."

You're welcome to come back when the prerequisites are in place. A good assessment has no expiration date.

Path 3: "No."

Honest, direct. Some problems aren't AI problems. Some processes are too unstructured, too unpredictable, or too dependent on human judgment to benefit from AI automation right now. Maybe ever.

When the answer is no, I explain why. Not "it's complicated" — the actual technical or practical reasons. "Your process requires reading social cues from phone calls and making judgment calls that rest on 15 years of industry experience. AI won't replicate that. What it can do is transcribe the calls and organize the notes — but the actual decision-making stays with your team."

You walk away understanding your own process better, even if AI isn't the answer. Zero upselling. Zero "but maybe if we tried a different approach..." pressure. I'd rather send you away informed than keep you in a project that won't deliver value.

How to book

Email dawid@kuliberda.ai or use the booking link on the contact page.

First response within 24 hours. I'll confirm a session time and send a short pre-session questionnaire so we can make the most of our 60 minutes together.

No sales funnels, no "schedule a call with our team." You email or leave a short form — I respond and we set a time.

What to write in the email: a short description of what you do and which process you want to improve. Two or three sentences is enough. I don't need a formal brief — we'll cover everything in the session. The email just helps me prepare so we can hit the ground running.