How we work
A clear process, agreed in writing
Software projects go wrong in predictable ways: unclear goals, hidden assumptions, late feedback and no plan for after launch. Our process is designed to deal with each of those early.
The process
Six stages, from first call to long-term support
Small projects move through these quickly; larger ones spend more time in each. The order does not change.
- 01
Understand
A conversation about the goal, the users, constraints and what success looks like. We ask a lot of questions here.
We look at what already exists (systems, data, contracts, brand), who will use the product, and which outcomes matter most. If the problem is unclear, we suggest a short discovery stage before any build estimate.
- 02
Propose
A written proposal: scope, approach, risks, stages, assumptions, and what we need from you.
The proposal separates must-haves from nice-to-haves, names the main risks and how we plan to reduce them, and states assumptions openly so they can be checked rather than discovered later.
- 03
Design
User flows, interface design and technical architecture, agreed before significant code is written.
Depending on the project this covers wireframes, visual design, data model, integrations, hosting and security design. You review and approve before build starts.
- 04
Build in stages
Short iterations, each ending with a demo of working software you can try.
Code lives in a repository you can access. Each stage ends with a demo and a short written update: what was done, what is next, and any decision we need from you.
- 05
Test and launch
Functional, security, performance and accessibility checks, then a planned release with a rollback path.
We test on the devices and browsers your users actually use, run through a launch checklist, and plan the release so it can be reversed if something unexpected happens.
- 06
Support and improve
Monitoring, updates, fixes and improvements after launch, on terms that suit you.
Software needs care after launch: security patches, dependency and platform updates, backups, and small changes as you learn from real users. We agree the support arrangement up front.
Engagement options
Three ways to work together
The right model depends on how well the work can be defined up front. We will recommend one in the proposal and explain why.
Fixed-scope project
For work that can be clearly defined up front. Scope, stages and price are agreed before work starts; changes go through a simple written change process.
Suits: Well-understood requirements, a defined launch date, a fixed budget.
Time and materials
For work where requirements will evolve as you learn. You pay for the time spent, see progress at every stage, and can re-prioritise as you go.
Suits: New products, research-heavy work, changing priorities.
Ongoing support
A continuing arrangement to keep a system secure, up to date and improving, covering maintenance, monitoring and an agreed amount of change work.
Suits: Live websites, apps and platforms that your business depends on.
What you get
Visibility at every stage
- A written proposal with scope, stages, assumptions and risks before any commitment
- Access to the code repository and project board from day one
- A demo and a short written update at the end of every stage
- Decisions and changes recorded in writing
- Source code, designs, credentials and documentation handed over at the end
- A launch checklist and a plan to roll back if a release goes wrong
What we need from you
Four things that keep a project on track
One decision-maker
A named person who can answer questions and approve stages, so work does not stall waiting for sign-off.
Access and accounts
Access to existing systems, data and third-party services the product depends on. New accounts are created in your name.
Domain knowledge
Time with the people who understand the business process today. They know the exceptions no document mentions.
Timely feedback
Reviews of each stage's demo within the agreed window, so feedback shapes the next stage rather than the one after.
Principles
The commitments behind the process
Plain language, decisions in writing
We explain options and trade-offs without jargon, and confirm every decision in writing so nothing depends on memory.
You own what you pay for
Source code, designs, cloud accounts, domains and documentation are set up in your name or handed over to you. No hostage situations.
Security from the first commit
Access control, secrets handling, dependency checks and backups are part of the build, not an add-on at the end.
Honest scoping
If a ready-made tool would do the job, or a feature is not worth its cost, we will say so before you spend money on it.
Small steps, visible progress
Work is split into short stages that end in something you can see and try, so feedback arrives early and surprises stay small.
Built to be maintained
Readable code, automated tests where they matter, and documentation that lets any competent team, including yours, take over.
Working remotely, across time zones
Most of our collaboration happens through shared tools: a code repository, a project board, video calls and written updates. For clients outside India we agree a regular overlap window for calls at the start, and rely on written updates for everything else, so progress does not depend on everyone being online at the same time.
Ownership and confidentiality
The proposal and contract state who owns what. Our default is simple: what you pay for is yours, including source code and designs created for you. We are happy to sign a non-disclosure agreement before you share sensitive details, and we only use the access you give us for the work agreed.
When we are not the right fit
Sometimes the best answer is an existing product, a no-code tool or a specialist in a narrow field. If we think that is the case, we will say so and, where we can, point you in the right direction.
Have something you want to build or fix?
Tell us what you are trying to achieve. We will reply with questions, options and an honest view of what it would take, whether or not we are the right fit.