How a Fedri project actually runs, from first email to tenth year

Listening and discovery

The first stage is entirely about understanding. We talk to the people who will use the system every day, not only the person paying for it, because they are usually different and they usually want different things. We ask how the work happens now, what gets written on paper, which spreadsheet everyone secretly relies on, and what goes wrong in a busy week.

The most useful part of discovery is the exceptions. Any supplier can build the normal case. Real businesses are full of situations where a rule does not apply, where a manager overrides something, where a customer is treated differently for historical reasons. Those exceptions are what turn a tidy demonstration into software that survives contact with your staff, and we hunt for them deliberately.

Discovery also covers the boundaries. What other systems must this talk to? Who is allowed to see what? What happens when two people edit the same record? What must never be deleted for legal reasons? Answering those early is cheap. Answering them after the database is built is not.

The written specification

Everything learned in discovery becomes a written document that describes the software in plain language. It lists every screen, what each one shows, who can reach it, what the buttons do, which rules apply, which reports exist and what happens in the awkward cases. It is written to be read by the business owner, not by a programmer.

This document does several jobs at once. It gives you something concrete to approve before money is spent on development. It gives us a definition of finished, which protects both sides from scope quietly expanding. It gives your team a chance to say that a rule was described incorrectly while changing it costs nothing. And it becomes the basis for the estimate, which is why our numbers hold up better than estimates produced from a conversation.

Clients occasionally ask to skip this stage to save time. We have learned to decline politely. The week saved at the beginning has a habit of costing a month in the middle.

Interface design and data modelling together

Screens and database structure are designed side by side, because each one constrains the other. A report you want on one page determines how records must be stored. A permission rule determines how tables relate. Designing the interface without the data model produces beautiful screens that cannot be built efficiently, and designing the data model alone produces systems that are technically correct and miserable to use.

On the interface side we care about the ordinary daily task above everything. If a receptionist books forty appointments a day, that flow gets optimised until it is fast, even if it makes a rarely used administration screen slightly less elegant. We design for the eight hour user, not for the screenshot.

On the data side we plan for growth. Indexes are considered before there is data to index. Fields that will need history get history. Anything that might later need to belong to more than one parent is modelled that way from the start. Getting this right is the single biggest factor in how easily the system can be extended in year three.

Development in visible stages

Building happens in slices you can log into and use, not in one long silence followed by a reveal. Typically the first slice includes accounts, permissions and one complete workflow end to end, so the shape of the system becomes real early. Subsequent slices add the remaining areas, each one demonstrated as it lands.

This rhythm matters because feedback is only cheap while the surrounding code is still flexible. When a client sees a working screen in week three and says the sequence feels wrong, changing it is a small piece of work. When the same comment arrives in week fourteen after everything has been wired together, it is a rebuild. Visible progress converts expensive surprises into inexpensive corrections.

Throughout the build you receive short written updates covering what was completed, what is next and anything that needs a decision from you. We do not send status reports padded with technical detail to look busy.

Testing the ordinary and the awkward

Testing covers the path everyone expects and the paths people take when they are tired or in a hurry. We check what happens with an empty database, a very large one, a duplicate submission, a lost connection halfway through a save, a user who has been removed from a role, a file that is not the format anyone anticipated and a date entered in the wrong century.

We also test on real devices and real conditions, including older phones and slower mobile connections, because a meaningful proportion of users are not on new hardware with fast internet. Software that only performs on a developer machine is not finished software.

Where a client has staff available, we run a short period of supervised use before launch. The issues found by an actual user in one afternoon are usually more valuable than the ones found by a checklist in a week.

Deployment onto a properly built server

Deployment is not copying files onto whatever hosting was cheapest. We configure a Linux server with NGINX in front, Gunicorn running the application, MySQL tuned for the workload, Redis for caching, Celery workers for background jobs, a firewall, automatic certificate renewal, log rotation and scheduled offsite backups. Then we test that the backups actually restore, because an untested backup is only a hope.

Launches are scheduled for quiet hours in your region and rehearsed where the system is replacing something already in use. Where data is being migrated from an old system, the migration is run several times against copies until the result is clean, and there is always a documented way back if something unexpected appears.

Monitoring goes live at the same time as the application, so if the site stops responding or an error rate climbs, we find out before your customers tell you.

Training and handover

People decide whether software succeeds. We train your staff in ordinary language, using your own data rather than a demonstration dataset, and we leave written notes they can keep beside the keyboard. Sessions are usually short and repeated rather than one long day that nobody remembers by the following week.

Handover documentation covers how the system is deployed, where things live, how to add a user, how to run the common administrative tasks and what to do if something looks wrong. If you have your own technical staff, they receive a deeper version covering the codebase and the server configuration.

Care, tuning and the years that follow

After launch the system enters the phase where most of its life will be spent. We watch error logs, apply security updates to the operating system and the application dependencies, verify backups, and tune the queries that only reveal themselves as slow once real data volume arrives. None of this is visible to your users, which is exactly the point.

Alongside the technical care there is a business conversation. What has the system taught you? Which screens are used constantly and which were never touched? Where are staff still working around the software instead of through it? Those answers shape the next round of improvements, and they only exist because the system has been in real use.

Some clients take a formal monthly care plan. Others prefer to call when needed. Either is fine, though the ones on a plan have noticeably fewer emergencies, since the problems get handled while they are still routine maintenance.