Our approach
How the work actually runs
Why it is structured this way
Predictability is the point
Software projects rarely fail because of a technical impossibility. They fail because scope was never written down, because a requirement changed without anyone assessing the cost, or because nobody discovered the problem until the week before launch.
The method below exists to remove those failure modes. Each stage produces something concrete — a document, a design, a working increment, a test result — that both sides can look at and agree on. Progress becomes something you can inspect rather than something you are told about.
The depth of each stage scales with the engagement. A focused internal tool does not need the same architecture phase as a multi-role platform. The sequence, however, stays the same, because skipping a stage tends to move its cost later rather than remove it.
Delivery method
Seven stages from first conversation to ongoing support
- 01
Discovery
We start by learning how the organisation works, not by describing what we can build.
- Structured conversations with the people who do the work and the people accountable for it
- Review of current systems, data quality, integrations and infrastructure
- Identification of the constraints that will genuinely shape the solution
- An honest early view of whether the request is the right thing to build
- 02
Requirements and planning
Findings become a written scope with boundaries both sides can point to later.
- Requirements expressed as outcomes rather than as feature lists
- Explicit statement of what is out of scope for this phase
- Effort estimates with the assumptions behind them written down
- A release sequence that puts useful capability in front of users early
- 03
Experience and architecture design
Interface and technical design happen together, because each constrains the other.
- User flows and interface designs reviewed before development starts
- Data model, API contracts and integration points defined
- Access control, data retention and privacy decisions made deliberately
- Architecture decisions recorded with their reasoning
- 04
Iterative development
Short cycles, visible progress, no long silences.
- Working software demonstrated at the end of each iteration
- Peer review on every change before it is merged
- Automated tests covering the paths that would hurt most if they broke
- Scope changes discussed openly, with their effect on time and cost stated
- 05
Quality assurance
Testing is part of building, not a stage bolted on at the end.
- Functional testing against the agreed acceptance criteria
- Cross-device and cross-browser verification, including lower-specification phones
- Accessibility checks against WCAG 2.1 AA principles
- Performance and security review before release
- 06
Deployment
Releases should be routine, reversible and observable.
- Automated deployment pipelines with checks before production
- Staging environment that reflects production configuration
- Monitoring, logging and alerting configured before go-live
- A documented rollback path agreed in advance
- 07
Support and continuous improvement
Launch is a milestone in the work, not the end of it.
- Agreed support arrangement with realistic response expectations
- Dependency and security updates on a defined schedule
- Review of real usage to inform the next set of priorities
- Handover documentation kept current as the system changes
Working practices
What runs through every stage
Communication
A named point of contact, a regular written update and a scheduled call. You should never have to ask what is happening, and we would rather report a delay early than explain it late.
Documentation
Architecture decisions, data models, API contracts and operational procedures are written as the work happens. Documentation produced weeks afterwards is rarely accurate.
Security
Access control, data minimisation, secret handling and dependency hygiene are design activities. Retrofitting them after launch is more expensive and less effective.
Testing
Automated tests cover the paths where a failure would cause real damage. Manual testing covers judgement, presentation and edge cases that automation handles poorly.
Change management
Requirements change; that is normal. Each change is assessed for its effect on scope, timeline and cost, and confirmed in writing before it is built.
Project visibility
You have access to the issue tracker, the repository and the staging environment throughout. Progress should be something you can check, not something you are told.
Post-launch improvement
After release we review what usage shows, address what is not working, and agree the next increment based on evidence rather than on the original wish list.
A two-way arrangement
What makes a project go well from your side
A named decision-maker
Someone empowered to answer questions and approve scope. Projects slow down most often while waiting for a decision nobody is authorised to make.
Access to the people doing the work
Time with the staff who perform the process daily. Their knowledge of the informal steps is usually the most valuable input to the design.
Honest constraints
Real budget, real deadline, real internal capacity. We can plan around a constraint we know about; we cannot plan around one we discover late.
Timely feedback on increments
Reviewing each increment while it is fresh keeps corrections small. Feedback held until the end turns adjustments into rework.
A view on priorities
When scope must be reduced — and it usually must — knowing what matters most lets us cut the right things rather than the convenient ones.
Willingness to hear a different answer
Occasionally the best recommendation is not the one you arrived with. We will explain our reasoning, and the decision stays yours.
Start with a discovery conversation
The first step is a conversation, not a contract. If a discovery phase makes sense afterwards, we will scope it clearly and you will own the output either way.
Direct contact
- ascendiatechnologiesnepal35@gmail.com
- +977 986-5240980
- Chandragiri–13, Kathmandu, Nepal