Process
Process
Seven stages. The same seven on every project, including the last one.
- 01Requirements
- 02System analysis
- 03Prototype design
- 04Development
- 05Quality control
- 06Deployment
- 07Support & maintenance
The last stage loops back to the first — support feeds the next build.
Requirements
What the software has to do, written down in both languages and agreed before anyone estimates.
System analysis
Architecture, data model and integrations. The stage where the expensive surprises are found instead of shipped.
Prototype design
Clickable screens you can put in front of a real user before the build starts.
Development
Built in Kathmandu, reviewed in your language, demonstrated on a schedule you set.
Quality control
A dedicated QA pass — functional, performance and accessibility — on real devices, not just a laptop.
Deployment
Release, redirects, monitoring and a rollback you have actually tested.
Support & maintenance
The stage most vendors treat as an afterthought. Named contact, response targets, patches applied.
What we commit to
How a project actually runs, written down. These are process commitments we hold on every engagement — not aspirations, and not a sales promise that quietly expires after kick-off.
Progress you can see
A written update every week, and a working demo at every milestone. One named project manager is your point of contact for the length of the build.
If a date is going to slip, you hear it in that week’s update — not at the deadline.
A quality bar we agreed
Acceptance criteria are written before development starts. Every release is tested against them: functional testing on real devices, a performance pass and an accessibility pass, by a QA lead who did not write the code.
A defect measured against those criteria is fixed as part of the project. It is not re-quoted to you as a change.
Scope changes in writing
Anything outside the agreed scope is assessed in writing first — what it costs, what it delays, what it affects — and is not built until you approve it.
The scope document is versioned. You can see what changed, when, and who asked for it.
Code you own
You get the full source, the build pipeline and the documentation to run it without us. Repository access is yours from the first commit, not handed over at the end.
Third-party licences and their terms are listed in the handover, so nothing you own depends on something you cannot keep. Transfer of ownership is set out in your agreement.
Support that was always the plan
Support is stage seven of the same process, with the same people who built it. Coverage hours and response targets are agreed before release, not negotiated after something breaks.
If you would rather your own team took it on, the handover documentation is written for that outcome too.
Commercial terms — price, payment schedule, liability, and the point at which ownership transfers — are set in your agreement, not on a marketing page. What is on this page is how we work regardless of what those terms say.
Discuss your project →Common questions
Frequently asked questions →What is the GStar Technologies development process?#
Seven stages, the same on every project: requirements, system analysis, prototype design, development, quality control, deployment, and support and maintenance. The seventh stage loops back to the first, because support is what feeds the next build rather than an afterthought.
How does GStar Technologies test what it builds?#
Acceptance criteria are written and agreed before development starts. Every release is tested against them by a QA lead who did not write the code: functional testing on real devices, a performance pass and an accessibility pass. A defect against those criteria is fixed inside the project, not re-quoted.
Who owns the source code GStar Technologies writes?#
The client receives the full source, the build pipeline and the documentation needed to run it without GStar Technologies. Repository access starts at the first commit, not at handover. Third-party licences are listed in the handover; transfer of ownership is set out in the agreement.
How are scope changes handled?#
Anything outside the agreed scope is assessed in writing first — what it costs, what it delays, what it affects — and is not built until the client approves it. The scope document is versioned, so it stays visible what changed, when, and who asked for it.
What support does GStar Technologies provide after launch?#
Support is stage seven of the same seven-stage process, handled by the same people who built the system. Coverage hours and response targets are agreed before release, not negotiated after something breaks. Handover documentation is written so an in-house team can take it on instead.
Last reviewed · 2026-09-19