AKILTA / PAID DISCOVERY

For complex projects, we clarify the problem, scope, dependencies and the right first release before development begins.

When custom software, SaaS, web, commerce, AI, migration or integration work is not clear enough for a fixed proposal, discovery becomes a separate engagement. The goal is not more documentation; it is to reduce uncertainty and produce an actionable decision and bounded next step.

Check discovery fit
UNCERTAINTY MAP01—06
01OUTCOMEBusiness outcome
02USERSRoles · needs
03WORKFLOWFlow · exceptions
04DATASource · ownership
05DEPENDENCYAPI · provider · access
06DECISIONScope · architecture · next step

This is not a build promise or a fixed budget/timeline guarantee; it shows the uncertainty that should be resolved before a reliable proposal.

01 / WHEN

When scope is unclear, we make the project decision-ready instead of manufacturing an estimate.

01

Multiple solution paths

The right boundary between platform, custom build, integration or process change is not yet clear.

02

Current system is unclear

Legacy structure, debt, data model, access or provider dependencies must be understood before change can be estimated responsibly.

03

A new product is still forming

Users, critical use cases and first-release acceptance criteria are not yet clear enough for a SaaS or MVP.

04

Risk or integration is high

Payments, personal data, AI, ERP/CRM, migration or critical third-party systems materially affect the scope decision.

02 / QUESTIONS

Discovery does not answer every possible question; it resolves the questions that change the build decision.

Depth varies with project risk. We avoid unnecessary enterprise planning and focus on uncertainty that can materially change cost, architecture or delivery.

  1. 01What outcome must exist?User and business result
  2. 02Who uses it and when?Role · permission · context
  3. 03What data is required?Source · quality · sensitivity
  4. 04What does it depend on?API · provider · access
  5. 05Where is error costly?Risk · approval · fallback
  6. 06How narrow can release one be?Scope · acceptance · learning

03 / OUTPUTS

The output should make it easier to decide whether to build and how the build should begin.

01

Problem & current-state map

A shared view of business goal, current workflow, actors and critical system surfaces.

02

Requirements & acceptance

Decision-grade functional requirements, critical edge cases and verifiable acceptance criteria.

03

Architecture options

Suitable platform/custom-build boundary, integration approach and material trade-offs.

04

Risk & dependency register

A visible list of access, provider, data, security/privacy, migration or operational dependencies.

05

Bounded implementation plan

The first-release boundary, sequencing logic and backlog areas to validate later.

06

Go / change / stop recommendation

Not every discovery should turn into a build. If another approach is better, that recommendation is a valid output too.

04 / BOUNDARY

Discovery is not the same thing as implementation.

Discovery creates enough decision clarity for a build. Code, full UI production, migration, production deployment, legal advice or a formal security audit are included only when separately scoped. The later build does not have to continue with Akilta; deliverable boundaries are stated in the engagement.

DISCOVERYDecision, scope, risk, plan
BUILDSeparate implementation scope
OPERATESeparate operations/care model

05 / PROCESS

Gather evidence → narrow options → produce a decision.

  1. 01IntakeGoal · current knowledge
  2. 02Access / evidenceSystems · data · documents
  3. 03AnalysisWorkflow · dependency · risk
  4. 04OptionsTrade-off · architecture
  5. 05DecisionScope · acceptance
  6. 06Next stepProposal · phased plan · stop

06 / FIT

Discovery is valuable when uncertainty can change real decisions.

Good fit

  • Multiple systems or teams are interdependent
  • A custom software/SaaS first release is unclear
  • Migration or integration risk can change the scope
  • Critical information is missing for a reliable proposal

Discovery may not be needed

  • The work is small with clear boundaries and acceptance criteria
  • There are no material technical dependencies or unknowns
  • An existing service route already fits the need directly
  • The goal is only to collect free ideas or speculative proposals

07 / COMMERCIAL RULE

Fee and scope are defined at proposal level around the depth of uncertainty that needs to be resolved.

Discovery is a paid professional engagement. Duration, meeting count, deliverables and fee are defined clearly in the proposal after the project inputs, systems to inspect and required analysis depth are understood.

08 / FAQ

Before starting discovery.

Why is discovery paid?

For complex projects, requirements analysis, system inspection, option evaluation and producing an actionable scope are professional work in their own right. The goal is a usable decision output, not merely a sales call.

Do I have to build with Akilta after discovery?

No. Usage boundaries for deliverables are stated in the engagement; where appropriate, the output can be designed to provide decision clarity for another implementation team too.

Does discovery guarantee a fixed budget and delivery date?

The goal is a more reliable scope and plan, but third-party dependencies or later discoveries may prevent absolute guarantees. Proposal assumptions and open risks are made visible.

Does every large project require discovery?

No. If requirements, data, architecture and acceptance are already clear enough, directly scoped delivery may be possible. Discovery is a tool for reducing uncertainty, not a ritual.

09 / START

If the project is hard to describe, the first job may be clarifying the right questions.

Tell us the current goal, systems you know about and the biggest unknown. We can determine whether discovery is genuinely needed or another service route is the better starting point.

Check discovery fit