Your project online

Data migration decides the schedule

An application replacing an existing tool inherits its content: customers, orders, invoices, history. That migration is rarely a straight copy. Formats differ, fields that are mandatory on one side are empty on the other, duplicates have coexisted for years, and in-house codes mean nothing outside their context. The work consists of mapping the old database, deciding what carries over and what gets archived, then rehearsing the switch several times on copies before the real one. It is the item that derails schedules when estimated roughly, and the one that reassures when handled first.

Integrations depend on what the others allow

An application rarely lives alone: it exchanges with accounting, a carrier, a till, a payment tool. Each API integration depends on what the vendor on the other side authorises, documents and maintains. A well-documented interface connects in a few days. A missing one forces file exchanges, with their schedules, their silent errors and their manual catch-up. So the question comes before pricing, and it is addressed to your vendors: do they offer an interface, on what terms, and with what volume limits. The answer changes the budget more surely than the number of screens.

Permissions are decided before the first screen is written

As soon as several people use an application, the question of who sees what arises, and it arises badly after the fact. Should a salesperson see margins? Can a temporary worker cancel an order? Does a validated invoice stay editable, and by whom? Those answers are not technical, they describe your organisation, and they shape the code deeply. Adding a notion of roles to an application built without one costs several times what planning it would have. So we ask at the scoping stage, even when only one person is meant to use the tool at first.

A dashboard that works is a dashboard people open

The request comes naturally: a dashboard showing everything. The result is often a dense screen nobody opens after the first month. A useful screen answers a precise question, asked by a precise person, at a precise moment of the week. Three figures that trigger a decision beat twenty curves describing a situation. So we start from the decisions to be made, then work back to the data needed, rather than the other way round. What stays off screen is not lost: it exports when the need arises.

Acceptance testing is planned, not discovered at delivery

Before going live, the application runs on an acceptance environment, a full copy where your test data lives without consequence. That is where discrepancies show: a calculation correct on three orders and wrong on the fourth, an export losing accented characters, an access right set too wide. This phase is scheduled and you take part in it, because nobody knows your edge cases better than you. Acceptance rushed through in one afternoon simply defers the fixes until after go-live, when they cost the most.

A backup never restored is not a backup

Automatic backup has become a box ticked by default, and that is exactly the problem: nobody checks it works before needing it. A backup is defined by three things, its frequency, how long it is kept, and how long it takes to bring the service back up from it. The third is the only one that counts on the day, and the only one that can be tested. It is checked by restoring it once on an acceptance environment, with a written procedure, and that test is something to ask of the host. That applies to the database as much as to files uploaded by your users.

Managed or self-run hosting, the choice is made early

An application needs a maintained environment: system security updates, renewed certificates, resource monitoring, logging. Managed hosting delegates that upkeep to a provider, for a higher monthly cost and real peace of mind. That is what third-party application maintenance means: entrusting the upkeep of an application to an outside provider, always separating corrective from evolutive so that one budget does not eat the other. Self-run hosting costs less and assumes somebody handles it, which holds in an organisation with a person for that, and is illusory elsewhere. The choice is made before development, because it shapes the architecture: an application designed for a controlled environment does not move to another one for free.

Onboarding is prepared, not improvised on the day

A business tool is not discovered like a website: it replaces a habit, often a spreadsheet everyone handled their own way. The switch succeeds when the people concerned have seen the screen before go-live and could say what was missing. It fails when it arrives by email on a Monday morning. So we plan a session on your own data, not on a demo set, and short documentation written in your vocabulary rather than the software's. Time spent there avoids the weeks of workarounds that follow a poorly prepared go-live.