A Process You Can Justify to Your Stakeholders.
We don't start building before the scope is locked. We don't ship code before architecture is validated. We don't close a project before your system runs stable in your production environment.
This page explains concretely what happens at each stage — who does what, what we expect from you, and which documents you receive at the end of each phase. No abstract claims. No promises without parameters.
Project Stage Overview
Every project with Software Factory moves through four sequential stages. Each stage has a concrete output that must be approved before the next begins. This is not a stylistic preference — it is a risk-control mechanism that protects your budget and schedule.
| No. | Stage Name | Focus | Key Deliverable |
|---|---|---|---|
| 1 | Discovery Sprint (Paid) | Understanding the real problem before writing a single line of code | Problem Definition Doc + Scope Framework |
| 2 | Architecture & Validation | Designing the right technical solution before execution | Technical Blueprint + Locked Final Budget |
| 3 | Phased Implementation | Building the system in sprints with quality gates at every phase | Working System per Sprint + UAT Report |
| 4 | Launch & Managed Support | Controlled go-live and structured post-launch support | Live System + Written SLA + Priority Support Access |
Stage 1: Discovery Sprint
We uncover your real problem before proposing a solution.
Discovery Sprint is a structured working session — not a product presentation, not a demo — designed for one purpose: understanding your operational problem deeply enough that the solution we design addresses the root cause, not the symptom. This process produces a document you can use, regardless of whether the project proceeds.
| Concrete Activity | Sahaware's Role | Expectation from Client | Deliverables |
|---|---|---|---|
| Structured interviews with client's technical and operational stakeholders (2–4 sessions). | Account Manager leads the sessions. System Architect attends as an active listener and technical requirements recorder. All AI-assisted drafting is manually validated by senior staff before delivery. | Prepare key stakeholders authorized to answer operational questions (minimum 1 technical, 1 business). Time commitment: 2–4 hours total. | Structured session notes from all sessions, validated and approved by client. |
| Existing process mapping: current workflows, pain points, and constraints of existing systems. | Software Factory team drafts the process map based on interview findings. No assumptions — every point is confirmed with the client. | Provide access to existing system documentation (if available) or assign a PIC who can explain operational flows directly. | Existing Process Map document (as-is process map) in a format readable by non-technical stakeholders. |
| Problem Statement formulation and success metrics identification. | Account Manager drafts the Problem Statement. System Architect validates technical feasibility from an architecture perspective. Final output is jointly approved. | Provide final confirmation that the Problem Statement accurately reflects the client's internal priorities. | Approved Problem Statement document — ready to be brought to client's internal meetings. |
| Initial Scope Framework drafting: core features, agreed boundaries, and documented assumptions. | System Architect drafts the scope framework based on Discovery findings. AI assists with document structuring — all content decisions remain with senior staff. | Review the scope framework draft and provide sign-off or revision notes within the agreed timeline. | Scope Framework draft that becomes the foundation for Stage 2 (Architecture & Validation). |
Phase Activities
Account Manager leads the sessions. System Architect attends as an active listener and technical requirements recorder. All AI-assisted drafting is manually validated by senior staff before delivery.
Prepare key stakeholders authorized to answer operational questions (minimum 1 technical, 1 business). Time commitment: 2–4 hours total.
Structured session notes from all sessions, validated and approved by client.
Software Factory team drafts the process map based on interview findings. No assumptions — every point is confirmed with the client.
Provide access to existing system documentation (if available) or assign a PIC who can explain operational flows directly.
Existing Process Map document (as-is process map) in a format readable by non-technical stakeholders.
Account Manager drafts the Problem Statement. System Architect validates technical feasibility from an architecture perspective. Final output is jointly approved.
Provide final confirmation that the Problem Statement accurately reflects the client's internal priorities.
Approved Problem Statement document — ready to be brought to client's internal meetings.
System Architect drafts the scope framework based on Discovery findings. AI assists with document structuring — all content decisions remain with senior staff.
Review the scope framework draft and provide sign-off or revision notes within the agreed timeline.
Scope Framework draft that becomes the foundation for Stage 2 (Architecture & Validation).
All Stage 1 outputs are physical (digital) documents that you own. Even if the project does not continue to Stage 2, these documents remain entirely yours.
Stage 2: Architecture & Validation
The solution is fully designed before it's built. You are consulted, not burdened.
Based on the scope framework from Stage 1, Software Factory's technical team designs the system architecture internally — covering database design, integration flows, technology stack selection, and accurate effort estimation. The client is consulted periodically at key decision points. You do not need to be present daily — you only need to provide confirmation when the final architecture is ready for approval.
| Concrete Activity | Sahaware's Role | Expectation from Client | Deliverables |
|---|---|---|---|
| System architecture design: database structure, API endpoints, integration with client's existing systems, and user interface design (wireframe level). | System Architect leads the design process internally. AI is used to accelerate technical documentation drafting — all architectural decisions are manually validated by the Technical Director before documents are considered final. | Provide answers to specific technical questions if they arise during the design process (typically via email or brief meeting ≤ 60 minutes). No daily involvement required. | Technical Architecture document (wireframes, system diagrams, integration specifications) in a format presentable to the client's internal technical team. |
| Effort estimation and preparation of the locked final Budget Breakdown (RAB) based on the designed architecture. | Account Manager and System Architect prepare the RAB together. Specific figures are not displayed on the public page — the final RAB is only delivered to the client in a formal context (separate document). | Confirm whether there are internal budget constraints or procurement regulations that need to be accommodated in the contract structure. | Locked Final Budget (RAB): an approved budget document that becomes the contract reference. No cost changes after this stage without a formal Change Request. |
| Architecture confirmation session with client: design presentation and validation that the architecture addresses the problem statement from Stage 1. | Account Manager facilitates the confirmation session. System Architect attends to answer technical questions. This session typically runs 60–90 minutes. | Attend the confirmation session with stakeholders authorized to provide technical sign-off. Submit notes or revisions within the agreed timeframe after the session. | Signed Architecture Confirmation document — this is the official gate before Stage 3 begins. |
Phase Activities
System Architect leads the design process internally. AI is used to accelerate technical documentation drafting — all architectural decisions are manually validated by the Technical Director before documents are considered final.
Provide answers to specific technical questions if they arise during the design process (typically via email or brief meeting ≤ 60 minutes). No daily involvement required.
Technical Architecture document (wireframes, system diagrams, integration specifications) in a format presentable to the client's internal technical team.
Account Manager and System Architect prepare the RAB together. Specific figures are not displayed on the public page — the final RAB is only delivered to the client in a formal context (separate document).
Confirm whether there are internal budget constraints or procurement regulations that need to be accommodated in the contract structure.
Locked Final Budget (RAB): an approved budget document that becomes the contract reference. No cost changes after this stage without a formal Change Request.
Account Manager facilitates the confirmation session. System Architect attends to answer technical questions. This session typically runs 60–90 minutes.
Attend the confirmation session with stakeholders authorized to provide technical sign-off. Submit notes or revisions within the agreed timeframe after the session.
Signed Architecture Confirmation document — this is the official gate before Stage 3 begins.
Official gate: Stage 3 does not begin until the Architecture Confirmation Document and Final Budget are signed by an authorized client representative. This protects both parties from mid-project ambiguity.
Stage 3: Phased Implementation
Built sprint by sprint. Controlled at every checkpoint. No surprises at project end.
System development is carried out in measured, sequential sprints. Each sprint produces a testable module — not code hidden on our servers until the project ends. Software Factory's technical team uses AI to accelerate routine code production, while every deliverable passes manual peer code review by a senior developer before entering the testing phase. Any change outside the scope locked in Stage 2 must go through a formal Change Request mechanism.
| Concrete Activity | Sahaware's Role | Expectation from Client | Deliverables |
|---|---|---|---|
| System development execution per sprint (typically 2 weeks per sprint). Each sprint has a feature backlog agreed upon at the start. | Satellite team developers execute technical tasks. Lead System Architect performs manual peer code review for every deliverable before it enters the staging environment. AI is used for code assistance and automated vulnerability detection — all outputs pass a human quality gate. | Provide access to the required testing or staging environment. Assign an internal technical PIC who can respond to system integration questions within 1 business day. | A sprint demo accessible and testable by the client at the end of each sprint. Sprint summary report distributed on a regular schedule. |
| Internal testing (automated testing + manual exploratory testing) before each deliverable is handed over to the client for UAT. | QA is conducted in layers: automated testing scripts run first, followed by manual exploratory testing by the QA team to ensure a user experience that is not only bug-free but also intuitive. | Conduct User Acceptance Testing (UAT) on sprint deliverables against agreed acceptance criteria. Provide UAT sign-off or bug list within the agreed timeframe. | Signed UAT report per sprint. Each module that passes UAT is considered accepted and enters the verified system inventory. |
| Change Request management: every change outside the scope locked in Stage 2 is documented, its impact on time and cost estimated, and requires formal approval before implementation. | Account Manager documents the Change Request and coordinates impact estimation with the System Architect. No scope change is implemented without a signed Change Request document. | Submit Change Requests formally through the agreed channel (not via WhatsApp or verbally). Provide approval or rejection decision within 3 business days. | Documented and signed Change Request — protecting the client from undocumented scope creep. |
Phase Activities
Satellite team developers execute technical tasks. Lead System Architect performs manual peer code review for every deliverable before it enters the staging environment. AI is used for code assistance and automated vulnerability detection — all outputs pass a human quality gate.
Provide access to the required testing or staging environment. Assign an internal technical PIC who can respond to system integration questions within 1 business day.
A sprint demo accessible and testable by the client at the end of each sprint. Sprint summary report distributed on a regular schedule.
QA is conducted in layers: automated testing scripts run first, followed by manual exploratory testing by the QA team to ensure a user experience that is not only bug-free but also intuitive.
Conduct User Acceptance Testing (UAT) on sprint deliverables against agreed acceptance criteria. Provide UAT sign-off or bug list within the agreed timeframe.
Signed UAT report per sprint. Each module that passes UAT is considered accepted and enters the verified system inventory.
Account Manager documents the Change Request and coordinates impact estimation with the System Architect. No scope change is implemented without a signed Change Request document.
Submit Change Requests formally through the agreed channel (not via WhatsApp or verbally). Provide approval or rejection decision within 3 business days.
Documented and signed Change Request — protecting the client from undocumented scope creep.
Non-negotiable principle in Stage 3: We do not close a sprint without client UAT sign-off. We do not implement scope changes without a written Change Request. These two rules are most frequently violated by other vendors — and are the root cause of most IT project disputes that end up at the legal table.
Stage 4: Launch & Managed Support
Go-live is not the end of the project. It is the beginning of a structured operational partnership.
System launch is conducted in a controlled manner — not by pressing a button and handing everything over to the client. Software Factory accompanies the go-live process, ensures data migration runs accurately, and verifies system performance in the real production environment before declaring it live. After go-live, after-sales support operates under a written SLA — not verbal promises.
| Concrete Activity | Sahaware's Role | Expectation from Client | Deliverables |
|---|---|---|---|
| Pre-launch checklist and system verification in client's production environment: data security, load performance, and backup configuration. | System Architect conducts final security audit and performance testing in the production environment. AI is used to run automated vulnerability scanning — scan results are manually validated before the system is declared go-live ready. | Provide access to the production environment and assign an internal IT admin who can coordinate during the deployment process. | Documented Pre-Launch Verification report — written evidence that the system has passed security and performance standards before go-live. |
| Controlled go-live execution: deployment to production, data migration (if applicable), and intensive monitoring for the first 72 hours post-launch. | Account Manager coordinates the go-live schedule with the client. Technical team is on standby during the first 72 hours for rapid incident response. All remediation actions are documented in real time. | Inform internal users of the go-live schedule. Provide a reachable PIC for any operational issues on the client side during the first 72 hours. | System live and operating in the production environment. Signed system handover minutes by both parties. |
| Post-go-live Managed Support: critical bug handling, security updates, and operational support per the agreed package. | Software Factory's support team responds to incidents based on priority levels defined in the SLA. AI is used for automatic ticket categorization and FAQ filtering — critical incident handling and escalation decisions remain with senior human staff. | Report incidents through the agreed support channel (not personal numbers of technical staff). Provide sufficient context information when reporting issues to accelerate resolution time. | Written SLA covering: response time per incident category, availability commitment, and defined escalation path. Monthly system status and resolved ticket report. |
Phase Activities
System Architect conducts final security audit and performance testing in the production environment. AI is used to run automated vulnerability scanning — scan results are manually validated before the system is declared go-live ready.
Provide access to the production environment and assign an internal IT admin who can coordinate during the deployment process.
Documented Pre-Launch Verification report — written evidence that the system has passed security and performance standards before go-live.
Account Manager coordinates the go-live schedule with the client. Technical team is on standby during the first 72 hours for rapid incident response. All remediation actions are documented in real time.
Inform internal users of the go-live schedule. Provide a reachable PIC for any operational issues on the client side during the first 72 hours.
System live and operating in the production environment. Signed system handover minutes by both parties.
Software Factory's support team responds to incidents based on priority levels defined in the SLA. AI is used for automatic ticket categorization and FAQ filtering — critical incident handling and escalation decisions remain with senior human staff.
Report incidents through the agreed support channel (not personal numbers of technical staff). Provide sufficient context information when reporting issues to accelerate resolution time.
Written SLA covering: response time per incident category, availability commitment, and defined escalation path. Monthly system status and resolved ticket report.
What differentiates Software Factory's Managed Support: Our SLA is a contractual document, not a marketing promise. Response time, availability targets, and escalation procedures are written and binding. You do not need to contact anyone's personal number to get a response.
Why This Process? Fair Questions — and Honest Answers.
We understand that corporate buyers — especially in state-owned enterprise environments — have legitimate questions about this approach. Below are direct answers, without unverifiable claims.
You understand the process. The next step is one.
Discovery Sprint is the single entry point for all Softwarefactory projects. There are no shortcuts, because shortcuts are what create troubled projects. Fill in the submission form. Our team will contact you within 1 business day to schedule a brief orientation session (30 minutes) before Discovery Sprint begins.
No commitment beyond the current stage. Every stage begins with your written approval.