Requirements documentation, feasibility validation, competitive and market analysis, resource estimation, and business process optimization review of existing products. During a build they also cover change control, acceptance criteria, stakeholder alignment, and UAT support. For AI products, add data readiness assessment, evaluation criteria, and governance documentation. Each is a standalone output you keep, whether or not you continue with us for development. 

No, and treating it that way is where most of the value goes missing. Discovery produces the initial scope, but requirements keep changing as the team builds and as users react to what ships. A BA who stays with the project runs change control, keeps acceptance criteria accurate, settles conflicting stakeholder input, and catches the slow drift between what was specified and what is being built.

Classic requirements work still applies, and it covers maybe half the problem. AI products need decisions conventional software doesn’t: whether your data can support the use case at all, how output quality gets measured and what threshold is good enough to release, where a person stays in the loop, how the system behaves when it’s uncertain or wrong, and what documentation the applicable regulation requires. Those decisions usually determine whether an AI pilot reaches production. 

Yes. It handles discovery research, consistency and gap checks across large requirement sets, first-draft documentation from workshop transcripts, and traceability analysis when a late change ripples through specs and test cases. It shortens the mechanical parts of the job. Every requirement that reaches a development team is still reviewed and owned by the analyst responsible for it. 

Yes. A data readiness assessment covers what data you hold, its coverage and quality, how it’s labeled and structured, the gaps that would block training or retrieval, and the retention and consent constraints on using it. It’s the cheapest way to learn that an AI roadmap isn’t buildable yet, and it usually produces a short list of things to fix first.

There are two ways to price it, and which one applies depends on whether you already know what you’re building.

If development is already the plan, budget 5–10% of the expected build cost for analysis. On a $60,000 MVP that’s $3,000 to $6,000. On a $200,000 platform, $10,000 to $20,000. That ratio is also the best sanity check you have when you’re comparing proposals. A vendor quoting $5,000 of analysis against a build they expect to bill at $250,000 is planning to skip most of the work and recover the difference through change requests later. A vendor quoting $40,000 against a $70,000 build isn’t automatically wrong, but they should be able to tell you what they expect to find that justifies it.

When there’s no build cost to anchor to, analysis gets priced on effort instead. That’s the case when you’re validating an idea, replacing a legacy system, or putting an RFP together before anyone has picked a vendor. At Eastern European rates, roughly $35 to $60 an hour for a senior BA, a focused two-week engagement lands around $3,000 to $5,000. Add a prototype and an architecture concept and you’re looking at $8,000 to $15,000.

We quote analysis fixed-price. What gets scoped in this phase is the process itself: the sessions, the artifacts, the deliverables list. None of that changes depending on what we conclude. So you get a fixed price, a fixed end date, and findings nobody has a financial reason to steer.

The clearest triggers: a new initiative you’re about to fund, a product idea you need to validate before building, an existing product that’s underperforming, a discovery phase you want run properly, a prior project that went over budget on unclear requirements, a delivery team losing days to unclear tickets, or an AI initiative where nobody has defined what success looks like. Bringing in business analyst services at any of these points costs less than fixing the gap later.

Hiring a BA means adding a person, employee or contractor, to your team on an ongoing basis. Our business analysis consulting services work either way: a scoped engagement with defined deliverables and an end point, or a BA embedded with your team for the length of a delivery cycle. You get defined deliverables in both cases.

Two to six weeks covers most projects. Roughly:

• One to two weeks for internal tools, single-role products, and domains everyone in the room already knows cold
• Two to four weeks once you’ve got multiple user roles, several integrations, and real risk to assess
• Four to six weeks for enterprise systems and migrations, or anything needing sign-off from more than a couple of stakeholders
• Eight to 12 weeks in regulated environments, meaning patient data, financial services, safety certification. Compressing this band is a false economy, and it tends to surface during an audit rather than during the project, when it’s considerably more expensive to fix

The assumption worth dropping is that the timeline scales with project size. It mostly doesn’t. Two other things move it.

The first is your team’s availability. Realistically, we need someone on your side who can commit 2 to 5 hours a week to meetings for the length of the phase, plus a contact person who can review and validate documents, requirements, and tasks as we produce them. Both need to come from the people who run the process day to day, not just the sponsor. If sessions take three weeks to schedule, or documents sit unreviewed, a two-week analysis quietly becomes a five-week one. Of everything on this page, that’s the variable you control completely.

The second is integrations. Every system we must talk to needs its API checked against what it supports, not what the documentation claims it supports. Optimism about integrations is the most common reason projects overrun later, so we’d rather spend the time here. Four integrations is a different phase than one.

If your deadline is fixed, tell us in the first conversation. We’d rather narrow the analysis and cover the first release properly than stretch it across the whole roadmap, compress the sessions, and hand you a document that looks finished but hasn’t been tested against anything.