What is the difference between off-the-shelf and custom software?

Off-the-shelf software is a product made for many companies, which you configure within the limits the vendor offers. A custom system is built for your process, and the company decides what it does and when it changes.

Off-the-shelf arrives fast and spreads the development cost across all customers. In exchange, you adapt your process to it. Custom goes the other way, with the software following the process.

When is off-the-shelf the best choice?

When the process is the same as in any other company. Payroll, accounting, invoicing, email and video calls are good examples. Nobody wins a customer by having a different payroll.

Martin Fowler calls this kind of system utility, as opposed to strategic. For utility systems, the goal is to work well and cost little. Building from scratch something the market already solves is spending money where there is no return.

When is it worth building custom?

It is worth it when the process is what sets your company apart and no product handles it without workarounds. In field operations, that is usually the service itself.

An example from our projects. An industrial tank cleaning company used an ERP for finance, but what its client bought was the service carried out and documented. The report by shift, the photo report, the certificate and the apportioning of idle hours did not exist in any product. That is what became a system.

Which signs show off-the-shelf software is not working?

Five signs come up often.

One sign on its own is solved with configuration or training. Three or more call for a different conversation.

What goes into the cost of each path?

With off-the-shelf software, the visible cost is the license. The hidden cost is the time the team spends working around what the product does not do, plus customizations billed separately and the risk of the vendor changing the product or the price.

With custom, the visible cost is development. The hidden cost is support. A system needs fixes, security updates and adjustments for as long as it is in use. Anyone who budgets only for the build gets a surprise later. We cover that in support and modernization.

There is also the cost of complying with the law. Any system that stores data about employees, visitors or customers has to meet data protection rules, whether off-the-shelf or custom. In Brazil that is the LGPD. With off-the-shelf, you depend on what the vendor offers. With custom, access and retention rules are your decisions.

Can you combine the two?

Yes, and that is the most common setup. The ERP keeps handling what is the same for everyone, and a custom system handles the field process. The two exchange data through integration so nobody retypes anything.

In the port operations case, the platform we built reads the client's warehouse management system straight from the database and shows the warehouse operation on dashboards.

How do you reduce the risk of a custom project?

By starting small. Pick the process that hurts most and put only that into use. A first version that solves a real problem in a few weeks teaches more than months of specification.

Three precautions help.

1. Involve the people who operate from the start. Whoever decides the purchase is rarely the one who uses the system.
2. Ask for deliveries in short cycles, with your team testing with real data.
3. Agree on support before the system goes into production.

That is how we run custom web system projects.

What is a permit to work?

A permit to work is a formal document that authorizes a hazardous activity, in a defined place and period, after safety conditions have been checked. It describes the job, the risks, the control measures and who authorized it.

The UK safety regulator, the HSE, defines a permit-to-work system as a formal written system used to control certain types of work that are potentially hazardous. The permit does not make the activity safe by itself. It records that someone checked the conditions and took responsibility for the authorization.

Which Brazilian standards require a permit to work?

Several regulatory standards (NRs) from Brazil's Ministry of Labor and Employment deal with the subject. These are the ones most cited in port and offshore operations.

This summary is general guidance. The text of each standard changes over time, and the person who defines what applies to your operation is the company's occupational safety lead. Always check the version in force on the Ministry's website.

What are the problems with paper?

Paper fails where time matters. These are the most common problems.

• The form travels around the base collecting signatures while the job waits.
• Nobody knows, at a given moment, how many permits are open and where.
• Revalidation from one shift to the next depends on someone remembering.
• The checklist is generic, the same for activities with different risks.
• An audit means searching folders, and an illegible permit becomes a doubt.

In the port operations case we published, those were exactly the symptoms before the system.

What does a permit to work system need to do?

It needs to reproduce the paper control and add what paper cannot do. These are the essential functions.

1. Activity types with their own checklist. The requester picks the nature of the activity, and the system shows the checks for that type.
2. Participants and signatures. Requester, workers and issuer sign on screen, with date and time recorded.
3. Validity and revalidation. The permit has a time limit, and continuing on another shift requires a new recorded check.
4. Closure. The job ends with a record that the area was left in a safe condition.
5. A board of open permits. One screen shows what is in progress, by location.
6. Audit. Each permit keeps the history of who did what, and field audits are linked to it.

One technical point matters more than it seems. The rules for who can issue, approve or close have to be checked on the server, and not just hidden on screen. We explain that care in support and modernization.

How do you roll out a digital permit to work?

In steps, starting with one area.

1. Map the current form. List the fields, the activity types and who signs each one. The paper that already exists is the best starting point.
2. Pick a pilot area. A workshop or a quay, with a crew willing to test.
3. Run in parallel for a short time. Paper and system together, only until the crew trusts the system.
4. Expand and switch off paper. Area by area, with checklists reviewed by the safety department.

The system has to work on a phone, because the permit is issued where the work happens. Ours run as an app installed from the browser. See how that differs from a store app in apps.

Is a digital permit valid as a document?

The form of record is a decision for the company with its safety department and, where needed, its legal team. What the system offers is traceability: who signed, when, with which user and from which device. That record is usually easier to audit than a signature on paper.

We do not give legal advice on regulatory standards. We build the system from the procedure your company defines, as in any custom web system project.

What is a PWA?

A PWA, or progressive web app, is a website built to behave like an app. The user opens an address, installs it on the home screen and uses it full screen, with its own icon. Underneath, it is still web technology.

According to MDN's documentation, a PWA is built using web platform technologies but provides a user experience like that of a platform-specific app. In practice, that means one codebase for Android, iPhone and desktop.

What can a PWA do today?

More than many people expect. A modern PWA does the following.

• Uses the camera for photos and to read QR codes.
• Reads GPS location while it is open.
• Receives push notifications, including on iPhone.
• Stores the interface and part of the data on the device to open offline.
• Updates for all users the moment a new version is published.

Notifications on iPhone are recent. Apple enabled the feature for web apps added to the home screen starting with iOS and iPadOS 16.4, as the WebKit blog describes. Before that, this was the main reason to go to the store.

When is a native app necessary?

In four situations.

In the health app we built, store subscriptions and Sign in with Apple decided for native. We used React Native with Expo, which generates the iOS and Android versions from the same base.

How does each one behave offline?

Both can work without signal, but the development work is different. In native, storing data on the device is the natural path. In a PWA, you have to plan what is stored, for how long and how data syncs when the connection returns.

The point to watch is conflict. If two people change the same record offline, the system needs a rule to decide which one stands. That rule is a business rule and should be defined before development, in either technology.

On vessels and in remote areas, this is usually the requirement that weighs most. We deal with it in the vessel inspection case.

Which costs less to maintain?

The PWA. It has one codebase, and there is no old version in circulation, because everyone gets the new one at the same time. There is also no store review and no developer account to manage.

Native means publishing to two stores, keeping up with each one's rule changes and living with users who take time to update. Tools like Expo reduce that work a lot, but it still exists.

What about the security of a PWA?

It is the same as that of a well-built web system. A PWA only works over an encrypted connection, access requires a login and permissions are checked on the server for every action. Camera, location and notifications depend on explicit authorization from the user, requested by the operating system.

The difference from native is in distribution. A store app can be installed by anyone who finds it. An internal PWA is an address only your team knows, and it does not show up in a store search. For operations systems, that is usually an advantage.

What needs attention is the shared device. At gatehouses and on vessels it is common for several people to use the same phone or tablet. The system should end the session after inactivity and record who did each action. The port operations case shows this kind of gatehouse use.

How do you decide for a field team?

Answer three questions.

1. Who will use it? If they are employees and contractors of the operation, a PWA distributes by link or QR code, with no store.
2. Does the app need to work with the screen locked? If continuous tracking is a requirement, go native.
3. Is there a charge inside the app? If so, go native.

If all three answers point to a PWA, start with it. Since the API is the same, a native app can come later and reuse everything that already exists. That is the path we describe in apps, and the base is always a custom web system.