ENGINEERING
Engineering Practice
This page explains how we keep systems running. It deliberately avoids piling up technical terms: what you need to judge is the problem each practice solves, not which tools were used.
INTEGRATION
Integration: making data move between old and new systems
For most companies the problem is not the absence of systems but systems that do not talk to each other. A newly built system has to connect to what is already there; otherwise it is simply one more screen someone has to retype data into.
- What we can connect to
- Payment, logistics, government filing platforms, an existing ERP and third-party SaaS. As long as the other side offers an API or can export data, we can connect to it.
- Legacy systems that are completely closed
- Even without an API there is a way through. File exchange or scheduled data transfers can handle it, so there is no need to rebuild an entire system for a single new feature.
- Data sent back from equipment
- Production machines, sensors and measuring instruments can report their status to the system in real time, supporting remote monitoring and automatic alerts in place of manual meter readings and scheduled inspection rounds.
- One set of data, several entry points
- The website, the back office, the app and LINE share the same member and order records. Whichever entry point a customer comes through, they map to the same record, with nothing maintained twice.
Related service
Custom Software DevelopmentSECURITY
Security: defining exactly who can see what
The risk in an internal system usually lies not in an outside break-in but in unclear permission boundaries. The first step in security is defining permissions, not buying equipment.
- Permissions by department and role
- We define who can see which data and take which actions at the design stage. Sensitive information such as salaries, costs and customer lists does not become visible to everyone simply because the system is shared.
- Protection at the network layer
- Firewall rules, outbound connection management and the office network are planned together. This keeps the system stable and also stops protection being bypassed from inside the internal network.
- Least necessary access, with a record
- When we maintain a system we access data only as far as necessary, and we keep a query log. The same principle applies to AI applications: the data that can be reached is restricted, and queries can be audited.
- Preventing abuse of forms and accounts
- Public forms are protected by submission rate limits and hidden fields to block automated programs, rather than captchas that require recognising images. Blocking automated programs should not come at the cost of making real people work harder.
BACKUP & RECOVERY
Backup and restore: what matters is whether recovery actually works
Having a backup does not mean you can recover. Plenty of companies discover only at the moment they need a restore that the backup files were corrupted long ago, or that nobody knows the restore procedure.
- Scheduled backups, with restore drills actually performed
- Alongside the scheduled backups, we run the restore procedure once for real, to confirm that the data comes back intact and that someone is familiar with the steps.
- What decides the architecture
- Four questions decide the architecture: how far back you must be able to recover if data is lost, how many people use the system at once at peak, whether regulation dictates where the data may sit, and how large the data will grow over the next three years. Once all four are answered, usually only one architecture still makes sense.
- Backup frequency and number of copies kept
- Backup frequency and the number of copies retained are planned around how much data changes and how far back you can afford to recover. Whether backups are held off-site is assessed against how critical the data is and what regulations require, and both are recorded in the delivery documentation.
- Recovery targets after a failure
- The target restore time and the acceptable amount of data loss are set during planning, based on what downtime actually costs you, and restore drills verify that they can be met.
Related service
Corporate Network PlanningMAINTAINABILITY
Maintainability: keeping the system changeable over the long run
The real cost of a system is not the day it is finished but every adjustment afterwards. A system that cannot be adjusted eventually has to be rebuilt from scratch.
- Confirm the screens and rules before development
- We turn the process into actual screens and rules and get your confirmation before development begins. A gap in understanding costs least to correct at the design stage and most once it has been written into code.
- Delivery in stages
- The step with the greatest impact goes live first, so the benefit arrives early, and the remaining features follow in stages. Every stage delivers something you can actually operate.
- One team from start to finish
- The team does not change from consultation through to post-launch maintenance. Adding a field or adjusting a step does not require someone else to work out how your system fits together.
- Features grow with the business
- A custom system is built once and used for years, and its features can keep growing with the business. It is not held to the fixed logic of packaged software, where the only answer is that it cannot be done.
HOW WE DECIDE
The principles behind our recommendations
The same requirement can be met in several ways. These are the principles we judge by, and in most cases they lower your total spend.
- Keep existing equipment wherever possible
- We audit the specifications and condition of your current equipment and recommend replacement only where performance falls short, expansion is impossible or there is a security concern, always with the reasoning and an estimated cost. We do not replace equipment for its own sake.
- We do not assume an app is the answer
- For bookings and lookups used only occasionally, a LINE LIFF needs no download and no registration and costs less to build and promote than an app. We recommend a native app only where push notifications or device features are genuinely needed.
- AI answers stay within bounds
- Answers come only from the knowledge base you provide, and where there is no match the system replies that it is not sure and hands over to a person. We would rather it say so than give your customers information nobody has verified.
- No move to the cloud for its own sake
- We list the cost and the risk of cloud, your own servers and a mixed setup and decide together with you, rather than assuming that every system should move to the cloud.
TALK TO US
Want to know which approach fits your situation?
Describe your current systems and the step in your operation that is stalling, and we will say directly which approach fits better.