How we build software: from discovery to long-term support

Our software development process runs through eight stages: discovery, scope and estimate, design, build in short iterations with demos, QA, launch, host and run, and long-term support. You see something concrete at every stage — a written brief, a fixed estimate, clickable designs, a working demo every iteration — rather than waiting months for a single reveal at the end. This is how we run that process for clients in Nepal and Australia; for cost ranges and how to choose a partner in the first place, see our custom software development guide.

Discovery: stage one of our software development process#

We start by talking through what you're trying to achieve, who will use the software, what it needs to connect to, and what isn't negotiable — a budget ceiling, a launch date, an existing system it has to work alongside. For a genuinely new product, this sometimes includes quick sketches or a clickable prototype of the riskiest idea, so we're testing the concept before committing real budget to it.

What you see at the end of discovery is a written summary: the problem as we understood it, the users, the constraints, and the open questions. You confirm we got it right, or correct us, before anything is scoped. If requirements are still vague at this point — a common and reasonable state for a new product — we say so, and treat resolving them as part of scoping rather than guessing and building the wrong thing.

We also use discovery to ask what already exists: current systems to integrate with, an existing brand or design language to follow, and any data that needs to move across from an old platform. Finding this out early avoids a redesign of the plan halfway through the build.

Scope and estimate: what you see before committing budget#

Discovery turns into a scope document: the screens, features, integrations and roles involved, broken down enough that both sides know what "done" means. Alongside it comes an estimate — a fixed price for a clearly defined scope, or a dedicated-team rate for ongoing or less-defined work. Our post on dedicated development team vs fixed-price project walks through how we help clients choose between those two models.

Nothing gets built until you've reviewed and signed off on scope and estimate. That sign-off is the point where an idea becomes a committed plan. Where something is genuinely uncertain — a third-party API whose behaviour we haven't tested yet, for instance — we say which assumption the estimate rests on, rather than quietly padding every line item to cover the unknown.

Design: what it looks and feels like, before a line of code#

Screens get designed and turned into a clickable prototype before development starts, so you can react to layout, navigation and content while changes are still just a redraw, not a rebuild. This is also where we flag anything in the scope that looks harder, or easier, than it did on paper. Our UI/UX design work sits here, feeding directly into the build that follows.

Design sign-off covers more than how a screen looks: it includes the states around the happy path — empty states, error messages, loading and permission levels for different user roles — because those are the screens that get skipped in a rush and then cause confusion once real users arrive.

Build in short iterations, with regular demos#

Development happens in short iterations, each ending in a demo of working software rather than a written status update. For a new product, the first iterations often aim at a minimum viable version — see our guide to MVP development for how we scope that specifically — so there's something real to react to as early as possible.

Regular demos matter because misunderstandings are far cheaper to fix in week two than in month four. If something doesn't match what you expected, you see it at the next demo, not at launch. Each demo is working software you can click through yourself, not a recording or a slide describing what was done — if a feature isn't in a state to be shown, it isn't done yet, whatever the task tracker says.

QA: testing before your users find the bugs#

Each build is tested against the agreed scope before it reaches a demo, and again, more thoroughly, before launch: core flows, edge cases, and behaviour across the browsers or devices that matter for your users. This happens on a staging environment that mirrors production, not on the live site, and includes checking that a fix for one thing hasn't quietly broken another. Bugs found here get fixed before release; bugs found after release go through the same reporting and fix process as any other support request.

Launch#

Launch is coordinated, not improvised: DNS and domain cutover, TLS certificates, monitoring switched on before real traffic arrives, and a rollback plan in case something needs reverting quickly. The standards we apply from this point on are the same ones described in how our DevOps team runs production for clients.

Host and run it afterwards#

After launch, we can host the application on our managed OVHcloud infrastructure or inside your own cloud account, and run it under one of our DevOps management levels — from basic hardening and backups through to a fully managed service with a named DevOps engineer. Building, hosting and running are separate services, so you can also take the finished code elsewhere if that suits you better.

Support and long-term maintenance#

Once live, software needs upkeep: bug fixes, dependency and security updates, and small enhancements. Larger new features go through their own short scope-and-estimate cycle rather than being squeezed into an existing budget. Our support and maintenance service covers this ongoing stage.

Handling change without losing the plan#

Requirements change on almost every real project, and that's normal, not a failure of planning. What matters is the process: a change gets written down, its effect on timeline and cost gets estimated, and you sign off before it's built. That keeps scope creep visible instead of quietly eating the budget, and protects the relationship as much as the schedule.

Not every change needs this full treatment — a genuine bug fix or a small clarification of something already in scope is just handled. The process exists for the middle ground: the "small" request that's actually a new feature, where skipping the conversation is how budgets and deadlines quietly slip.

Working across time zones with Australian clients#

Our team works Nepal hours, 09:00–18:00 NPT. Nepal Standard Time is a fixed UTC+05:45 offset year-round — Nepal doesn't observe daylight saving — while most of eastern Australia moves between AEST and AEDT. That gives a predictable, if slightly unusual-looking, overlap:

New South Wales, Victoria, Tasmania and the ACT move to AEDT during daylight saving, roughly October to April; Queensland stays on AEST year-round. Either way, a Nepal working day covers an Australian afternoon and evening, which is enough for a daily stand-up, a demo, or a same-day question and answer without either side working unusual hours.

In practice, that means messages sent from Australia in the morning are waiting when the Nepal team starts, and there's a live window through the Australian afternoon and evening for anything that needs a real-time conversation — a demo, a design review, or working through a blocker together — before Nepal's day ends. Anything raised later in the Australian evening gets picked up first thing the next Nepal morning rather than sitting for a full day. Our guide to offshore software development in Nepal covers working with a Nepal-based team in more depth.

Handover and IP: what you own at the end#

At handover, you get the source code, admin credentials, environment configuration and documentation needed to run the software independently: what each part of the system does, how to deploy a change, and where things like API keys and third-party accounts live. Custom software we build for you is yours; this should be, and is, explicit in the contract rather than left implied. If you'd like us to keep hosting and running it, that's a separate, ongoing arrangement, not a condition attached to ownership — and if you later choose to move it elsewhere, the same handover materials are what the next team would need.

What to do next#

You can see the kind of platforms this process has produced in our past work, or read more about what we build across our services. If you have a project in mind, get in touch and we'll start with discovery.