The server side is where a company's real rules are written down: who can do what, what is incompatible with what, how a price is calculated, how much a customer gets back after a cancellation. Everything else, from the website to the mobile app, is just a way of displaying those rules. If the rules live in the interface, in spreadsheets and in employees' heads, the business loses money on inconsistencies and cannot scale.
This is the eighth stage of our app development strategy. We look at what back-end development includes, what you get, what it costs and why a mistake in the data model is more expensive than any other.
What happens at this stage
- Development in PHP (Yii2).
- Working with MySQL, query optimisation, caching (Memcached).
- Dependency management via Composer.
Behind these lines are concrete things: the database schema and migrations, APIs for interfaces and integrations, access rights, calculations, statuses and an event log. We speed up the standard part with our own Fractal generator: the data schema, a documented API and a basic admin panel are generated, while the code that sets your business apart from the next one is written by hand.
What you get at the end
- A database whose schema follows the model from the technical specification, plus migrations for changing it.
- A documented API used by the interfaces, the mobile app and external systems.
- An admin panel for managing data.
- Business rules, access rights and calculations checked on the server on every action.
- An event log: who did what in the system, and when.
How much back-end development costs
In the Ingello price list the server-side business logic stage costs from $0 to $4,700, and the price is fixed before work starts. The lower bound means that not every project needs a separate budget for this stage. Within the range the price is determined by:
- the number of entities and statuses and the links between them;
- how many business rules and calculations there are: prices, discounts, refunds, accruals;
- how many roles there are and how finely permissions are split;
- whether data must be migrated from an old system;
- what load is expected and where caching is needed.
Why a rule must live in one place
If the condition "discount no more than 30%" is written into the interface, the report and the import, sooner or later those three copies will drift apart. One rule, one place. The interface displays it, the server enforces it.
The same goes for access rights. Hiding a button is not enough: the action must be locked on the server, otherwise it can be called directly. More on this in our article on production security.
What this looks like on real projects
In the BusTicket admin system for a bus carrier, permissions are split by role down to individual actions: for each section separately "view", "edit" and "full access". A dispatcher cannot delete a route, a carrier cannot see other carriers' bookings, an agent cannot get into payroll. Everything that happens in the system is written to a timeline. When someone asks six months later who did something, the answer is a dated record, not a guess.
The same server calculates refunds. The refund percentage comes from a "Refund conditions" reference table and depends on how long before departure the trip was cancelled. A partner's route goes on sale only after an administrator has reviewed it.
The Lino floor coverings shop has different rules: six price types, including two floor prices below which nothing may be sold, and fractional quantities in the basket to two decimal places. Rules like these cannot be left to the interface: the manager edits prices for whole categories, and a buyer must never see a price below the floor price under any circumstances.
Settings without a programmer
Some rules change more often than new versions ship. The technical specification for the XenFit online training platform stated explicitly that rating coefficients and mailing frequency are changed from the admin panel without a programmer. It also set code requirements: names in the code match the language of the business domain, and the API is documented in Swagger. A new developer reads a server like that as a description of the business.
Data sets the ceiling for the product
The data schema laid down at the technical specification stage becomes code here. A mistake in the relationships is not fixed by an index or a cache. It is fixed by a migration, and a migration on live data always costs more than thinking it through at the start.
When Lino's data was moved from the old structure, every field was examined separately: the client kept manufacturer and brand in one table, and the purchase price had a different name from ours. Along the way we removed unnecessary NOT NULL constraints so the import would not fail on empty values.
When load grows, the techniques from our article on server optimisation will help. But optimisation cures a slow query, not a wrong model.
What breaks if you cut corners
- Rules get copied into the interface, reports and imports, and drift apart.
- Permissions are enforced only by hiding buttons, so any action can be called directly.
- There is no event log, and disputes are settled from employees' memory.
- Every change to prices or terms needs a programmer, even though it could have been a setting in the admin panel.
What we need from you
- The rules your company works by today: price lists, discount and refund terms, approval procedures.
- A list of roles and what each one is allowed to do.
- An export of your current data, if it has to be moved from an old system or spreadsheets.
Where next
Next comes deployment and infrastructure. The previous step: integrations. The map of all stages is in the app development strategy.
Discuss the architecture. If your company's rules currently live in spreadsheets and people's heads, book a free consultation with an architect: we will go through the data model, and afterwards you will receive a price and timeline estimate broken down by stage.
