Business software · Integrations · Modernisation

Custom software development
built around how your business runs.

Turn complex workflows into software people actually want to use. We build business software around your operations and the systems you already depend on, and we can start from an existing codebase as readily as from a blank page.

Discuss your project ↗

What custom software means here

Software that fits the business,
not the other way round.

Custom software is built for one organisation’s way of working: its rules, its data, its existing tools. The starting point is an operation that already runs, often on spreadsheets, email and a system nobody dares touch. The job is to improve it without breaking it.

Workflow and operations systems

Order handling, scheduling, quoting, approvals, inventory, case management. Your business rules translated into a practical data model and an interface that staff can use without a manual.

Integrations with existing systems

Connecting the new software to the accounting, CRM, e-commerce, payment or warehouse tools you already depend on, so that data is entered once and stays consistent.

Legacy modernisation

An architecture review of the current system, then replacement of one part at a time while the business keeps running. Data migration is planned and rehearsed, not improvised.

Takeover and continuation

Joining or taking over an existing codebase: review, stabilise, document, then continue development. Suitable for projects a previous developer or agency left unfinished.

Who this is for

Businesses that have outgrown their tools.

The companies that benefit most from custom software usually recognise themselves in one of these descriptions:

The spreadsheet has become a system. Several people edit it, it has macros nobody fully understands, and a mistake in it costs money.
Staff re-type data between tools. Orders from the shop into accounting, leads from forms into the CRM, timesheets into invoices.
The off-the-shelf product almost fits. You pay for a platform and then work around the 20% it does not do, which happens to be the part that makes your business different.
A legacy system is holding things back. It works, but it cannot be extended, the person who built it has moved on, or it runs on technology that is no longer supported.
A software project has stalled. A freelancer disappeared or an agency relationship ended, and you hold a half-finished codebase.

How this differs from our other services

If you are building a product to sell to many customers by subscription, that is SaaS development. If you need a specific browser-based application such as a customer portal or dashboard and the requirements are already clear, see web application development. This page is for work where the business process, the existing systems and the existing code are the hard part. For smaller companies taking a first step, our small business and internal tools pages describe typical starting points.

Buy or build

Custom software is often the wrong answer. Check first.

A studio that builds software has an obvious incentive to recommend building. So here is the decision rule we would apply to our own business:

Situation	Better choice	Reason
Generic function: accounting, payroll, email, basic CRM, help desk	Buy	Mature products exist, and someone else carries the maintenance and compliance burden
A product fits about 90% and the gap is an inconvenience	Buy, adapt the process	Changing a habit is cheaper than owning software
Good products exist but do not talk to each other	Buy, then build the connections	A small integration layer removes the re-typing without replacing anything
The process is specific to you and central to how you operate or compete	Build	No vendor’s roadmap will prioritise your particular edge
Per-seat licence costs grow faster than the value received	Compare over three to five years	Building has a high first-year cost and a lower running cost; include maintenance honestly
The process itself is still changing month to month	Wait, or use a no-code tool	Software fixes a process in place. Settle it first

Owning software is a commitment. Custom systems need hosting, security updates and someone to call when something breaks. Count that in the comparison. If the numbers favour buying, we will say so during discovery.

The process

Understand first.
Then build in stages.

Ranges are planning figures. Business software varies more than product work because the existing environment varies, so discovery carries more weight here.

How we work in detail ↗

Discovery or code review · 1–3 weeks

We map the current process with the people who do the work, list the systems and data involved, and, where code exists, review it. Output: a written assessment, a staged roadmap with acceptance criteria, and a fixed quote for the first stage.

Design and data model · 1–3 weeks

Screens for the main workflows and a data model agreed with the people who know the exceptions. A clickable prototype is reviewed by actual users, not only by management.

Staged build · 6–16 weeks per stage

Each stage delivers something staff can use. Work runs in short iterations on a staging environment, with integrations tested against sandbox or copied data before touching live systems.

Migration and rollout · 1–3 weeks

Rehearsed data migration, a period of running old and new side by side where practical, short training sessions, and a defined way back if something goes wrong.

Support · ongoing, scoped separately

Monitoring, updates, fixes and small improvements under a monthly arrangement, or a documented handover to your internal team.

Technology approach

Mainstream tools, chosen so you are never locked in.

Business software lives for many years and outlasts the team that wrote it. We therefore favour technology that is common, documented and easy to hire for.

Concern	Typical approach	Why
Application	React / Next.js front end, Node.js backend, TypeScript throughout	One language, large talent pool, straightforward handover
Data	PostgreSQL	Relational integrity suits business records; strong reporting; no licence fees
Integrations	REST APIs and webhooks where available; scheduled file import and export where not	Meets each existing system where it is
Reliability of integrations	Queues, retries, idempotent operations, an error log a person can read	The other system will be down at some point; data must not be lost or duplicated
Access control	Role-based permissions and an audit trail of who changed what	Expected by auditors, useful for support
Mobile or field use	Responsive web first; a mobile app where offline work or device features require it	Avoids paying for an app that a browser could replace
Deployment	Docker on your own cloud or VPS account, automated backups, staging environment	You hold the keys; environments are reproducible
Existing codebases	Continue in the current stack when it is sound and within our skills	A rewrite needs a better reason than preference

Our working languages are JavaScript and TypeScript. If your existing system is written in something we do not work in, the review will say so, and the options become an integration layer around it, a staged replacement, or a recommendation to find a specialist in that stack.

Pricing factors

What moves the cost of business software.

How well the process is understood. A documented process with known exceptions is quick to specify. One that lives in three people’s heads takes longer to uncover than to code.
Number and quality of integrations. A modern, documented API may take days. An old system with no API can take weeks, and some of that effort is spent simply finding out what is possible.
Data migration. Volume matters less than cleanliness. Duplicates, free-text fields and inconsistent history all need rules.
Roles, approvals and audit requirements. Every approval step and permission rule multiplies the states the system can be in.
Condition of existing code. Tests, documentation and a working deployment make a takeover cheap. Their absence makes the first weeks about stabilising, not adding features.
Rollout constraints. Switching over at a quiet weekend is simple. Running two systems in parallel across several sites is not.
Reporting. Management reports, document generation and exports are consistently underestimated.

We quote stages at a fixed price against a written scope, with milestone payments, and we price changes before doing them. When comparing quotes from several vendors, compare the scopes line by line. The article on how outsourced development works in practice covers contracts, milestones and IP terms.

Common mistakes

Where business software projects go wrong.

Automating a broken process

Software makes a process faster, not better. If the current workflow has steps nobody can justify, remove them before writing code that enforces them for the next ten years.

The big-bang replacement

Replacing an entire legacy system in one release concentrates all the risk on one date. Staged replacement delivers value earlier and lets you correct course after each stage.

Specifying without the people who do the work

Managers describe the process as designed. Staff describe the process as it happens, including the exceptions that take up half their day. The software has to handle the second version.

Ignoring the exceptions

Refunds, partial deliveries, a customer with two accounts, an order changed after approval. If the system cannot handle them, staff go back to the spreadsheet and you now maintain both.

Rewriting inherited code on instinct

Every developer prefers their own code. Inherited code that is ugly but working and in production often deserves stabilising and tests before anyone talks about a rewrite. Ask for the reasoning in writing.

No owner on the business side

A project needs one person with the authority to answer questions and make trade-offs within a day or two. Without that, the schedule is set by the slowest meeting.

Fit

When BBR is the right team,
and when it is not.

We are a small independent studio working remotely from Istanbul. That suits focused business systems and is the wrong shape for enterprise programmes.

Good fit

We are likely a strong match if

The problem is a specific operational process, not a company-wide transformation
You want one team to cover analysis, design, build, integration and deployment
You have a stalled or inherited JavaScript or TypeScript codebase and need someone to take responsibility for it
You prefer staged, fixed-price work with clear acceptance criteria
You want to own the code and run it in your own accounts
Remote collaboration in English, with written updates and scheduled calls, works for your team

Not a fit

We will probably point you elsewhere if

You need an ERP implementation or customisation of SAP, Oracle, Dynamics or Salesforce
Your procurement requires a vendor with SOC 2, ISO 27001 or similar certification
The system must be written in .NET, Java or another stack we do not work in
You need on-site analysts and developers for an extended period
An off-the-shelf product would do the job; we would rather tell you than build it

Why outsource custom software

Your business is not software. The project still needs a full team.

Most companies that need a custom system do not need a permanent software department. The build requires analysis, design, engineering and operations skills for some months; afterwards the need drops to maintenance and periodic improvements. Hiring for the peak leaves you overstaffed. Hiring one generalist leaves that person alone with every decision and makes the system depend on them.

Outsourcing the build to a studio gives you the full set of skills for the period you need them, with documentation and handover as contractual deliverables, not favours. The risks are real too: dependence on a vendor, misunderstood requirements, distance. They are manageable with a written scope, staged delivery, code in your own repository from the first day, and the right questions before signing. We set those out in questions to ask a software development agency, and weigh the alternatives in in-house vs outsourced development and agency vs freelancer.

If the system will need continuous development after the first release, our product engineering service describes how an ongoing arrangement works without hiring in-house.

Questions

Frequently asked
questions.

When is custom software worth it compared with an off-the-shelf product?

When the process is central to how you compete or operate, existing products fit it badly, and the cost of the workarounds is significant and recurring. For generic functions such as accounting, payroll, email or CRM, buying is almost always better. A common good outcome is a mix: standard products for standard jobs, with a small custom system for the part that is specific to you, connected through their APIs.

Can you take over a project another developer left unfinished?

Yes. We begin with a paid code and infrastructure review so that both sides know what exists: what works, what is missing, the state of the tests and deployments, and any security concerns. You receive a written assessment with options, usually continue as is, stabilise then continue, or rebuild part of it. You can take that document to any vendor.

Can you work with our existing systems and data?

In most cases. If a system has an API, a database we can read, file exports or webhooks, it can be integrated. Where a legacy system offers none of these, we look at scheduled file exchange or a staged replacement. Integration work is described in more detail on our API integration page.

Do we have to replace our old system all at once?

No, and we usually advise against it. Replacing one module at a time while the old system keeps running carries less risk than a single switch-over. Each stage delivers something usable, and you can stop or change direction between stages.

How do you price custom software?

Discovery and code reviews are small fixed-price engagements. Builds are quoted as a fixed price against a written scope with milestone payments. Open-ended work, such as ongoing improvements to a live system, is better handled as a monthly arrangement, which we scope separately.

Who owns the software?

You do. Ownership of the code and deliverables transfers to you under the project contract, the repository is handed over with documentation, and the system runs in accounts registered to your company. Open-source components remain under their own licences, which we list. The details are on our how we work page.

What happens if we want to move the work in-house or to another vendor later?

That should always be possible, and we build with it in mind: mainstream technology, a documented setup, and no proprietary framework of ours in the middle. Handover to an internal team is a normal end to a project.

Your next move

Not sure whether to buy or build?
Start with a conversation.

Describe the process that is causing trouble, the tools you use today and what you have already tried. We will tell you honestly whether custom software is the right answer.