Discover & define
We map users, technical constraints and business goals into a scoped roadmap. Output: a written scope with acceptance criteria, a technical approach, a timeline and a quote.
How we workClear terms.
Clear terms.
Before any code is written.
Most of the risk in hiring a software team has little to do with code. It is about scope, ownership, communication and what happens when something changes. This page answers those questions directly, so you know how a project with BBR runs before you contact us.
The processFour stages.
Four stages.
Each ends with something you can review.
The durations depend on the project. The order and the outputs do not.
Design & validate
User flows, interface designs and architecture, reviewed as a prototype before the full build is committed. This is the cheapest point at which to change direction.
Build & integrate
Working increments on a staging environment you can open at any time, documented decisions, and testing against the agreed acceptance criteria.
Launch & evolve
Production deployment, store submission where relevant, source-code handover and operational documentation. Ongoing support is scoped around what you need.
Communication
Remote, written, predictable.
BBR is based in Istanbul (UTC+3) and works remotely with clients in other countries, in English. Remote projects succeed or fail on communication habits, so ours are explicit:
- Written first. Decisions, scope changes and open questions are recorded in writing, so nothing depends on someone’s memory of a call.
- Agreed meeting windows. We fix regular call times that suit your time zone at the start of the project. See how the overlap works from the United States, the United Kingdom, Canada and Australia.
- Regular progress updates. What was done, what is next, what is blocked and what we need from you.
- Always-available staging. You can look at the actual product whenever you like, not only in scheduled demos.
- Direct access to the engineers. You talk to the people building the product.
Ownership
Your product is yours.
Code and IP
The contract assigns ownership of the work we create for you to you. We keep no licence fee, no revenue share and no hidden dependency on us.
Accounts and infrastructure
Hosting, domains, app store developer accounts, payment providers and third-party services are registered in your name, with access granted to us for the duration of the work. If we stopped working together tomorrow, nothing would need to be transferred.
Third-party components
Modern software is built on open-source libraries and paid services. We choose components with licences suitable for commercial use and document what your product depends on and what each costs to run.
Confidentiality
We sign NDAs on request and do not publish client work, names or details without written permission. That is why the case studies on this site are our own products.
Engineering principles
How we make technical decisions.
- Prefer boring technology. Widely used, well-documented tools mean lower risk and an easier time hiring later.
- Build the simplest thing that meets the requirement. Complexity is added when a real need appears, not in anticipation.
- Buy what is not your product. Authentication, payments and email delivery are solved problems. Your budget should go on what makes your product different.
- Make it handover-ready from day one. Version control, a README that works, environment configuration outside the code, and a documented deployment process.
- Security as routine. Encrypted connections, hashed credentials, least-privilege access, secrets kept out of repositories, dependencies kept current, and personal data collected only when needed. We hold no formal security certifications; projects that require one, or that handle regulated data, need that stated at scoping so it can be planned properly.
- Test what matters. Automated tests around business-critical logic, and manual testing on real devices and browsers before release.
Commercial terms
How engagements are structured.
| Model | Best for | How it works |
|---|---|---|
| Paid discovery | Ideas that are not yet specified | A short, fixed-fee engagement that produces the scope, designs or technical plan. Yours to keep and take anywhere. |
| Fixed scope | MVPs and well-defined projects | An agreed scope, price and timeline, with payments tied to milestones. |
| Monthly engagement | Ongoing product development and maintenance | An agreed monthly capacity with priorities set by you. See product engineering. |
| Code review / rescue | Existing or unfinished projects | A fixed-fee assessment first, then a plan. |
Cost depends on the scope, existing systems, integrations and release requirements. Send a short brief with your desired timeline and budget range and we will tell you what is realistic. If you want to estimate it yourself first, start with our guide to MVP development cost.
After you contact us
- We reply by email, usually with a few clarifying questions.
- If it looks like a fit on both sides, we arrange a call and, where needed, an NDA.
- You receive a written proposal: scope, approach, timeline and price.
- Nothing is billed until you have agreed to a proposal.
QuestionsPractical
Practical
questions.
Who owns the source code?
You do. Ownership of the code and other deliverables we create for you is assigned to you under the project contract. Open-source libraries and third-party services remain under their own licences; we list the ones your product depends on at handover.
Can you sign an NDA?
Yes. We are happy to sign a mutual NDA before you share anything sensitive, using your template or ours.
Can you work with an existing codebase or take over an unfinished project?
Yes. We start with a paid code review: we read the code, run it, and report on its state, the risks and what it would take to finish or stabilise it. Sometimes the honest answer is that parts should be rewritten, and we will say so with reasons.
Do you build both the back end and the front end?
Yes. A typical project covers the database, API, web or mobile front end, admin tools and deployment. One team being responsible for the whole system avoids the gaps that appear between separate vendors.
Where can you deploy?
To your own accounts: a cloud provider such as AWS, a VPS, or a managed platform, and to the App Store and Google Play under your developer accounts. Deploying to accounts you control means you are never locked out of your own product.
How are changes to the scope handled?
You can change your mind. When you do, we write down the change, estimate its effect on cost and timeline, and proceed once you approve. Small clarifications are absorbed; new features are priced.
What happens after launch?
You receive the repository, credentials and documentation. After that you can continue with us on an agreed maintenance or iteration plan, take the work in-house, or pause. Support is scoped separately, so you only pay for what you need.
What do you need from us during the project?
One person with the authority to make product decisions, timely feedback on designs and builds, and access to any systems we need to integrate with. Slow decisions delay projects more often than slow engineering does.
Your next moveHave the ambition?
Have the ambition?
Let’s build the software.
Tell us what you want to create, connect or improve. We’ll start with the scope, the constraints and a practical next step.
Discuss your project ↗