Eight businesses, one codebase

A fork is easy to justify once. A sector needs different terminology, a different default menu and a couple of fields the others do not use. Copying the codebase feels faster than making the product configurable, and for a week it is. Then the first bug has to be fixed twice, and the second sector makes it three times.

A fork is a promise to maintain two products

The cost of a fork is not the copy. It is every change after it: permissions, exports, billing, the booking page, the reports. The versions drift, and the smallest sector gets the least attention because it is the least profitable to touch. A product that serves eight sectors by forking is eight products with one team.

Terminology as configuration

Yanında POS asks for the business type at sign-up and uses it to change terminology, default services and menus without forking the codebase. The word on the screen changes; the appointment, the client record and the payment underneath do not. Configuration is not a cosmetic layer here — it is what keeps one data model honest across sectors.

Defaults are part of onboarding

An empty product is a bad first day. Sector defaults give a new business a starting point: the services it probably sells, the menu it probably needs, the vocabulary its staff already uses. The owner edits the defaults instead of building the product from zero, and the first booking can happen before the setup is finished.

The maths stays the same

Expenses, net profit and staff performance do not change because the business calls its customers “patients” instead of “clients”. The labels change; the arithmetic does not. Keeping the reports shared means a fix to a calculation reaches every sector at once, and a CSV export means the owner is never trapped in the product.

Roles and branches are boundaries

Multi-user roles and multiple branches are not features to bolt on later. They decide who can see which calendar, which client record and which report. Data export and permanent deletion belong to the same boundary: a product that holds a business's customer list has to be able to give it back and to remove it.

Say what is not built

Some features depend on outside providers: automated SMS and card deposits are the obvious ones. Yanında POS lists them as roadmap rather than showing them as if they already work. The sales page separates “working today” from “planned”, because a demo that pretends an integration exists is a support ticket with a delay.

One codebase is not a constraint. For a small team, it is the thing that lets an eight-sector product stay shippable.