Technology Strategy and Discovery

A discovery sprint is a fixed-scope, fixed-price engagement that produces three deliverables in two weeks: a written technical roadmap (what to build, in what order, with what technology choices); a cost and timeline estimate for the recommended build; and a risk register that documents the technical, data, and organisational risks that could delay or derail the project, with mitigation recommendations. The discovery sprint exists because most technology engagements fail not in execution but in scoping — ambiguous requirements, underestimated complexity, and unidentified dependencies. A two-week sprint forces the clarity that prevents expensive mid-project course corrections. At the end of the sprint, you decide whether to proceed with the build — there is no obligation beyond the sprint fee. We have run discovery sprints for fintechs processing over 1 million transactions per 15 hours, global supply chain firms managing 100,000+ SKUs, and D2C brands rebuilding their digital operations.

The most reliable indicator of AI readiness is data accessibility — not data volume. Organisations that struggle with AI deployments almost always have the same root problem: the data the AI needs exists but can't be reliably retrieved. It's in a legacy system without an API, it's inconsistently formatted across sources, or it requires manual extraction. Before investing in model selection, prompt engineering, or AI platforms, the question to answer is: can we give an AI agent clean, structured, real-time access to the operational data it needs to act? If yes, you're ready to scope a use case. If no, data infrastructure comes first. We assess both dimensions during the discovery sprint: data readiness and use case fit. The output tells you specifically what's ready to automate now versus what requires a data infrastructure investment first.

An AI strategy for an Indian enterprise has three components that generalist AI strategy frameworks often miss. First, regulatory mapping: DPDP Act 2023 affects any AI system that processes personal data of Indian citizens; RBI guidelines affect AI in banking and payment systems; SEBI guidelines affect AI in capital markets. Any AI strategy that doesn't account for the regulatory layer will hit compliance blockers mid-build. Second, data infrastructure gap analysis: Indian enterprise data tends to be distributed across legacy systems (Tally, older SAP versions, proprietary industry software) that weren't designed for API access. The strategy has to include a data readiness roadmap alongside the AI use case roadmap. Third, use case prioritisation for the Indian cost structure: the ROI threshold for AI automation in India is different from the US because labour costs are lower. Use cases that are unambiguously worth automating at $150/hour blended rates may not be at Indian rates — the strategy should be explicit about this arithmetic.

A technology strategy is a set of decisions about what technology to use, how to organise technology investment, and what to build versus buy versus partner. It answers: what stack, what architecture, what capabilities in-house versus outsourced, what the 12–18 month build priority is. A digital transformation roadmap is broader: it includes the technology decisions but also the organisational changes, process redesigns, and change management required to make technology adoption stick. The roadmap typically covers 2–3 years and includes dependency sequencing — what has to happen before what else can happen. We produce technology strategy as the output of a discovery sprint. A digital transformation roadmap is produced for organisations with a more complex stakeholder environment or multi-business-unit scope — it takes longer and involves more workshops with different parts of the organisation.

We use a decision framework with three criteria. First, strategic differentiation: if the capability is a direct competitive differentiator (a proprietary risk model, a custom logistics platform, an AI feature that no competitor has), build — because owning the IP matters. If it's commodity infrastructure, buy or use a managed service. Second, total cost of ownership over 3 years, not just licence vs. development cost: custom-built solutions have ongoing maintenance costs; SaaS has escalating subscription costs and vendor lock-in risk. We build the 3-year TCO model for the material options. Third, data control: some AI use cases require keeping sensitive data in your own environment, which eliminates certain SaaS options regardless of cost. The discovery sprint produces a concrete build/buy/partner recommendation with the reasoning documented — not a generic 2×2 matrix.

Pricing follows the engagement model. Discovery sprints are fixed-price for a fixed timebox. Build engagements are scoped after discovery — fixed-scope, time-and-materials, or outcome-linked. Managed services are billed monthly with defined SLAs. Total cost depends on scope, integration complexity, QA depth, and post-launch support — we publish a transparent breakdown for buyers evaluating their options.

Every engagement starts with a fixed-scope, fixed-price discovery sprint — typically 2 weeks. You leave with a written roadmap, risk register, cost estimate, and timeline before committing to a build. We then offer four engagement models: fixed-scope builds, time-and-materials, outcome-linked retainers, and managed services post-launch. If discovery doesn't justify proceeding, you can stop there — no obligation.