The business knows it needs software. The implementation path is still unclear.
Custom application projects often become expensive before the team has answered the most important questions:
- What business problem must the application actually solve?
- Who will use it, and what does their workflow look like today?
- Which requirements are truly necessary for the first release?
- Which systems, APIs, and data sources need to connect?
- What should be built, bought, integrated, or left alone?
- What technical constraints will affect the design?
- What can wait until a later phase?
- What will implementation realistically require?
The sprint turns those questions into a practical plan before major development begins.
This engagement is a strong fit when…
- A business process has outgrown spreadsheets, email, shared drives, or disconnected SaaS tools.
- An aging internal application needs to be replaced or substantially reworked.
- A team has a backlog or requirements list but no clear technical owner or architecture.
- Off-the-shelf software does not fit the workflow well enough.
- Several existing systems need to work together behind a simpler application or interface.
- Leadership wants a custom application but does not want to hire a permanent product and engineering team first.
- A previous development effort stalled because scope, requirements, ownership, or architecture remained unclear.
- A business unit needs a credible implementation plan before requesting budget or selecting a development approach.
Likely buyers include CTOs, CIOs, VPs of Engineering, IT Directors, Heads of Applications, COOs, operations leaders, and business-unit executives responsible for the workflow or system.
Custom Application Discovery & Architecture Sprint
A focused 1-2 week engagement designed to answer four questions.
What exactly should we build?
What should we not build yet?
How should the application fit with existing systems and data?
What will a realistic implementation look like?
FADLtech works directly with the people who understand the business process, current tools, technical environment, and constraints, then translates that information into a buildable plan. The sprint focuses on one application or clearly bounded initiative.
Serious discovery, not generic requirements gathering
The exact scope depends on the application, but discovery typically covers:
- Business problem and desired outcome
- Users, stakeholders, and ownership
- Current workflow and pain points
- Existing applications and tools
- Requirements and priorities
- Integrations, APIs, and external services
- Data sources, systems of record, and ownership
- Authentication and authorization needs
- Security, privacy, and compliance constraints
- Expected usage and scale
- Hosting and cloud constraints
- Operational and support requirements
- Build-vs-buy considerations
- Major technical risks and dependencies
- MVP versus later-phase functionality
The goal is enough clarity to make implementation decisions — not exhaustive documentation for its own sake.
Concrete deliverables you can build from
Six deliverables. The two highlighted below are what turn discovery into a buildable plan and a realistic implementation path.
Problem & Workflow Definition
A concise description of the business problem, intended users, current process, pain points, desired outcome, and important constraints.
Prioritized Requirements
Requirements organized into must-have for the initial release, should-have where justified, later-phase functionality, and explicitly out of scope — keeping the first implementation focused.
Solution Architecture
A recommended technical direction covering the application's major components, boundaries, hosting/runtime approach, authentication, integrations, and other architecture choices needed to guide implementation.
Data & Integration Design
A practical view of major entities, data flows, systems of record, API and integration requirements, ownership boundaries, and areas where data or integration complexity may affect implementation.
MVP / Phased Delivery Plan
A recommended sequence for delivering useful software in manageable stages — for example core workflow/MVP, then additional integrations and automation, then reporting and advanced functionality. The actual phases depend on the application.
Implementation Estimate & Roadmap
A decision-oriented implementation plan covering major workstreams, sequence, dependencies, risks, approximate timeline, and estimated implementation investment.
Validate important assumptions without turning discovery into a development project.
Where useful, FADLtech may perform limited technical validation during the sprint, used to reduce uncertainty around an important technical assumption:
- Architecture spikes
- API experiments
- Small integration tests
- Lightweight wireframes
- Focused proof-of-concept code
A substantial interactive prototype, full UI design effort, or production implementation is not included in the base sprint unless explicitly scoped.
A focused 1-2 week process
Understand the problem
Kickoff, workflow review, stakeholder input, existing systems, constraints, and desired outcome.
Simplify the scope and design the solution
Prioritize requirements, remove unnecessary scope, evaluate integrations/data, surface risks, and define the architecture.
Create the implementation plan
Produce the phased roadmap, implementation estimate, dependencies, and recommended next step.
What is not included
The base Discovery & Architecture Sprint is not a production development project. Unless separately scoped, it does not include the following. The sprint is intended to make development clearer and more predictable — not to hide a development project inside a discovery fee.
- Full production implementation
- Complete UX/UI design
- A large interactive prototype
- Migration of production data
- Production-grade integrations
- Full DevOps/platform implementation
- Penetration testing
- Formal security or compliance certification
- Production support or SLAs
- Detailed specification of every future feature
- Unlimited stakeholder workshops
- Multiple unrelated applications or initiatives
A productive sprint typically requires
Perfect documentation is not required. Part of the engagement is turning incomplete information into a clearer plan.
- One accountable business or project owner
- Access to approximately 3-5 relevant business and technical stakeholders
- Existing requirements, notes, backlog items, or process documentation where available
- Access to the current application, tools, or workflow where practical
- Information about integrations, APIs, and systems of record
- Representative screenshots, examples, or data where useful
- Known security, privacy, or compliance constraints
- Existing technical documentation where available
A focused first step before a larger build
A typical moderately complex application may require a sprint in the roughly $7,500-$12,500 range.
Larger initiatives involving many integrations, business units, complex data or security requirements, or substantial prototyping may require a larger scope and investment. The final fixed fee is confirmed after an initial conversation about the application and available information.
No obligation to hire FADLtech for implementation
A useful discovery engagement improves the decision even when the answer is not “build everything.”
Want the concise version?
Download the Custom Application Discovery & Architecture Sprint overview for a one-page summary of the engagement, deliverables, timeline, and investment.
Questions buyers usually ask
Do we need finished requirements before starting?
No. The purpose of the sprint is to turn an incomplete business need, workflow, idea, or requirements list into a clearer and more buildable plan. Existing documentation helps, but finished requirements are not required.
Is this only for brand-new applications?
No. The sprint can also be used to define a replacement for an aging internal application, redesign a problematic workflow, or plan a substantial new phase of an existing system. If the primary problem is technical debt and modernization of an existing legacy system, the Legacy Application Modernization Assessment may be the better starting point.
Will we receive detailed UI designs?
Not as part of the standard engagement. Lightweight wireframes may be used where they help clarify a workflow or requirement, but full UX/UI design and a substantial interactive prototype require separate scope.
Will FADLtech build a prototype during the sprint?
Only when a small prototype, architecture spike, API test, or other technical experiment is useful for validating an important assumption. A production-ready prototype is not included by default.
Can FADLtech implement the application afterward?
Yes. If implementation makes sense and FADLtech is a good fit, the sprint can lead into a focused Phase 1 implementation and later phases as needed. The customer is not obligated to continue with FADLtech.
What if the application is large or involves many systems?
The sprint can still be useful, but scope and pricing may need to increase when the initiative involves many business units, substantial integration complexity, strict security requirements, or multiple major systems. The first conversation is used to determine whether the standard sprint is sufficient.
What if discovery shows that we should buy rather than build?
That is a valid outcome. The purpose is to determine the best path to the business outcome, not to justify custom development regardless of the evidence.
Is this a fixed-price engagement?
Yes, once the scope is confirmed. Typical engagements start around $7,500. The final fixed fee depends on the application's complexity, stakeholder scope, integrations, constraints, and the amount of technical validation required.
Have an application you need to define before you build?
You do not need a finished specification before getting in touch. If your organization needs purpose-built software but the requirements, architecture, scope, or implementation path are still unclear, let's discuss the situation.
We can determine whether a focused Discovery & Architecture Sprint is the right next step. No obligation to continue into implementation.