"Two-week discovery" sounds like a sales line until you have the pack on the table. Then it is the difference between another AI initiative that lives in slides and one with a ranked portfolio, an architecture your IT team can review, a cost model finance can stress-test and a fixed-price proposal for a dated first release.
This is what those ten working days produce — and what they deliberately do not.
Who is in the room
Discovery runs with a team of three: an engagement lead, a solution architect and a data engineer. They work on site and remote depending on what access and travel allow.
They need your side too: a sponsor with authority, business owners for the processes in scope, IT and architecture contacts, a security or compliance counterpart and data owners who can speak to sources and quality.
Without that, discovery becomes guesswork. We say no to engagements where the right people cannot make time.
The ten-day shape
Days 1–2: Frame. Confirm mandate, constraints, success criteria and systems landscape. Map stakeholders and workshop schedule. Agree what "production" means for this engagement.
Days 3–5: Deep dive. Workshops with business and IT. Process walkthroughs — happy path and exceptions. Data source review. Integration points. Security and residency requirements. Existing pilots and what failed.
Days 6–8: Synthesise. Rank use cases on value, feasibility and risk. Draft target architecture. Data readiness assessment. Governance baseline. Rough order of magnitude for build and run.
Days 9–10: Readout. Present the discovery pack to sponsors and technical leads. Q&A. Next steps if you proceed to build.
Nothing is hidden until day ten. Weekly touchpoints keep surprises off the readout slide.
The discovery pack — section by section
Use-case portfolio
Not a laundry list of ideas. A ranked set with explicit scoring: business value, technical feasibility, data readiness, regulatory risk, dependency on other programmes.
The top one or two become candidates for the first production release. The rest form a roadmap with honest notes on what must happen first — often data or API work.
Target architecture
Diagrams and narrative: where models run, where data lives, how retrieval works, which systems agents call, identity and network boundaries, environments from dev to prod.
Build versus buy decisions are documented. If a legacy system blocks APIs, that is flagged — with a modernisation path if it is in scope.
Data readiness assessment
For the chosen use case: sources, freshness, quality issues, access patterns, PII classification, lineage gaps, residency requirements.
This is where many pilots die quietly. Discovery says so explicitly rather than discovering it in sprint four.
Governance and security baseline
Intended use and non-use. Human oversight model. Logging and retention. Model provider choices and data handling. Red-team scope. Evaluation approach.
Compliance teams get something they can map to their frameworks — not a promise to "handle governance in phase two."
Cost model
Build cost for the first increment. Run cost drivers: inference, storage, monitoring, managed run if applicable. Assumptions stated so finance can challenge them.
Inference cost is a product decision. Discovery starts that conversation with numbers, not vibes.
Fixed-price build proposal
Scope for the first production release: what ships by week twelve, what is explicitly out of scope, milestones, dependencies on your team, acceptance criteria.
Fixed price. Fixed date. Change happens through increment revisions, not silent scope creep.
What discovery is not
It is not a proof of concept. No production users at the end of two weeks.
It is not a detailed implementation spec for every future use case. It is enough to build the first increment safely.
It is not free consulting to take to another vendor. The pack is yours; the methodology and proposals reflect our build and run model.
It is not a guarantee you must proceed. The discovery fee is credited against the build if you proceed within sixty days. If you do not, you still have the plan.
Why two weeks is enough
Discovery is time-boxed because open-ended assessment becomes another pilot.
The team is senior enough to pattern-match across integrations, data estates and governance regimes. Workshops surface what documents alone miss. Ten days forces prioritisation — which is the point.
Longer discovery is available for unusually complex estates, but the default is ten working days because that is what most enterprises need to make a decision.
How clients use the pack
Board and steering committee: Ranked portfolio and cost model support a go/no-go with numbers attached.
Architecture review: Target architecture goes into your standards process with clear open questions listed.
Vendor comparison: If you compare build partners, the pack defines scope consistently. Apples to apples.
Internal build: Some clients use discovery to decide build in-house. That is a valid outcome. You still avoid building the wrong thing.
How to prepare so discovery is not wasted
Block calendar for business and IT workshops before day one. Pre-read access to architecture diagrams, data catalogues and policy summaries saves days of chasing.
Name one decision-maker who can attend the day-ten readout and respond within two weeks on proceed/pause. Discovery without a decision timeline becomes shelfware.
Share failed pilots honestly — what broke, what was learned. We are not auditing your team; we are avoiding repeat failure.
After the readout — decision paths
Proceed to build: sign increment one statement of work within agreed window; discovery fee credits per commercial terms.
Pause: fund specific foundation or modernisation work identified in pack; revisit agent increment when readiness gates met.
Stop: keep pack; no obligation. Better explicit stop than perpetual pilot.
Build in-house: pack gives internal team scope and architecture; we can offer advisory if useful.
Clarity on these paths in the readout prevents drift.
Anti-patterns we flag in discovery
Scope soup: twelve use cases with equal priority. Discovery forces rank.
Missing data owner: "IT will figure out data." Named owners or explicit gap plan.
Governance later: phase two logging. Baseline in pack or dated debt accepted by sponsor.
Integration hand-wave: "APIs exist." Validation in workshops or modernisation line item.
Run cost ignored: no inference model. Cost section with assumptions finance can edit.
Calling these out is the job. Sponsors appreciate clarity even when it delays launch.
Starting discovery
You need a scoping call first — thirty minutes, use case, systems, timeline, region. We quote a fixed discovery fee. Typical start is two to four weeks after agreement, depending on workshop scheduling and access.
Write to hello@incubics.com. Bring the sponsor who can say yes to the next step.
Incubics is the brand of IQLEXA Technologies Private Limited. Discovery is the first movement — Perceive — in how we work. Engineer, Deliver and Run follow if you proceed. Production by week twelve of the build.
Discovery outputs clients reuse internally
Internal build teams use discovery pack as RFP baseline — scope consistency across vendors if competitive bid follows.
Architecture review boards get diagram and open questions list — faster approval when surprises are pre-declared.
Finance uses cost model assumptions for multi-year planning — update actuals post launch.
Risk registers link control gaps to increment plan — transparent debt acceptance.
HR and ops see workflow and adoption sections — plan staffing impacts early.
Discovery is short but dense — treat readout as working session, not presentation-only.
Follow-up workshop within two weeks captures questions while context fresh.
Discovery quality depends on client preparation as much as consultant skill — both sides invest.
Two weeks is enough when scope is bounded and people show up prepared.