How we work
What happens at each stage, what we need from you, what you receive, and where you decide. The same steps apply whether we build a product for you or work as part of your team.
Stages
Six stages, each with a decision.
First conversation
- You provide
- A few sentences about the product, the people it is for and what exists today.
- You receive
- A reply with the questions that matter for your scope, and a call if it helps.
- Decision
- Whether it is worth going further, on both sides.
Discovery and proposal
- You provide
- Goals, priorities, existing designs, code or documents, and access to anyone who knows the product.
- You receive
- A written scope with the first release defined, the technology we recommend and why, the team, and the commercial terms.
- Decision
- What goes into the first release, and which engagement model fits: fixed project or dedicated team.
Design
- You provide
- Feedback on flows and screens, and decisions on open questions.
- You receive
- User flows, screens and, where useful, a clickable prototype.
- Decision
- Sign-off on what will be built.
Build in short cycles
- You provide
- Answers to questions and feedback on each working version.
- You receive
- Progress you can review at agreed points — usually a working build — and a shared task list.
- Decision
- Priorities for the next cycle, as you learn from what is built.
Testing and release
- You provide
- Acceptance testing, and the store, hosting or company accounts the release goes to.
- You receive
- Tested release builds, store or server deployment, and release notes.
- Decision
- Go-live.
Support and growth
- You provide
- Feedback from your users and your plans for the product.
- You receive
- Fixes, OS and library updates, monitoring and new features, as agreed.
- Decision
- What to improve next.
Communication
Who you talk to.
New inquiries are read by Ghanshyam Gadhiya, partner and CEO. Once work starts, Dushyant Tank looks after day-to-day communication and commercial matters, and Meera Oza coordinates delivery and takes up any concern you raise. Where agreed for the engagement, you can also talk directly to the developers and designers working on your product.
Existing products
Taking over code another team wrote.
Many projects start with an app or website that already exists. The order of work matters more than the speed.
Collect access
Code repositories, build and signing setup, store accounts, servers and third-party services, so nothing depends on the previous team.
Review the code
How it is built, what is fragile, and what blocks the next release. We explain what we found in plain language.
Stabilise first
Make the app build, release and run reliably before adding features: crashes, outdated SDKs, broken pipelines.
Then improve
Fix, refactor or rebuild parts, chosen by cost and risk rather than preference.
Ownership and handover
Agreed in writing before work starts.
- Code access, ownership and licensing are set out in the project agreement before work starts.
- We recommend keeping the source code in a repository your company owns; where we host it, transfer follows the agreement.
- We recommend that App Store, Google Play, hosting and third-party accounts are held in your company's name.
- Third-party components, such as open-source libraries, fonts or stock assets, stay under their own licences.
- Handover of design files and the notes another developer needs to continue the work is part of the agreed scope.
Questions
Before you get in touch
How do projects start?
With a short message about what you want to build or fix. We reply with questions, agree the scope of a first phase in writing, and start once both sides have agreed it.
How often will we see progress?
At agreed review points. Work is planned in short cycles; at the end of each one you see what was done — usually as a build you can try — and the plan for the next.
How do you take over an existing codebase?
We collect access to the code and accounts, review the code and explain what we found, stabilise builds and releases, and only then add features.
What do we get at handover?
What the contract sets out: typically the source code, access to the store, hosting and service accounts, and the notes another developer needs to continue the work.
Ready to talk about your project?
Tell us where you are starting from: an idea, an existing product or a team that needs more people.