Custom software, an iOS app, or a better setup of what you already own?

When a company asks me for an app, the answer might be a native iOS application, a small web portal connected to an existing system, or a feature it already pays for but has not configured well. That choice commits the company’s money, staff time, and a piece of its operations to software somebody will still own years after the build.

I can be interested in building something and still question whether it needs to be built. That judgment is part of the job.

I can be interested in building something and still question whether it needs to be built.

So I want to see the task first. Who performs it? How often? On which device? What fails today? What will need to be maintained after launch?

I want CodeAspen’s recommendation to survive a comparison of all three.

A working day tells me more than a feature list

Consider a hypothetical maintenance company. A coordinator assigns a job. A technician visits the site, records notes and photographs, and requests approval for additional work. Finance needs the final record before invoicing.

It is easy to jump straight to a mobile app for the technician. I would first watch how the job moves between those people.

Are photographs being lost, or are they simply attached to the wrong job? Does approval happen verbally because the current process is inconvenient? Does the technician have a usable connection on site? Which system contains the authoritative job record?

Each answer changes the design.

A better problem statement might be: technicians need to save site evidence against the correct job during poor connectivity so the coordinator can prepare an approval request without reconstructing the visit from messages.

Now we have something to evaluate. We can test whether an existing product does it and whether a custom interface improves it enough to justify ownership.

A vendor demo is only useful on the awkward cases

If a platform already covers the workflow, I would give it a serious look.

But I would bring an interrupted upload, a duplicate customer, an incorrectly assigned job, and a user with limited permissions. The happy path tells us less about daily operation than these cases do.

Check the features included in the actual plan being considered. Ask about supported APIs, export formats, data ownership, and what happens when the subscription ends. A capability on the product’s homepage may require an add-on or a different tier.

Buying software still involves delivery work. Records need migration, permissions need configuration, and staff need a process they can use. The comparison should include that work instead of treating the subscription as the whole price.

I am comfortable recommending configuration when it fits, provided the compromises are understood before the business depends on them.

Sometimes the custom part should stay small

The existing system may handle customers, jobs, and invoices well while making one interaction unnecessarily difficult.

That is a good reason to consider a narrow custom layer. A customer approval portal could write the decision back to the existing job. A field interface could attach evidence to the right record. A dashboard could expose outstanding approvals.

The boundary needs care. I would specify which system owns the job status, where an approval becomes authoritative, and how failed synchronization is resolved.

I would resist making every field editable in both places. Two competing records create a reconciliation problem that somebody will have to own.

A small application with a clear responsibility can be easier to operate than a broad replacement. It still needs reliable permissions, error handling, and a supported integration path.

The customer and the technician may need different interfaces

A customer approving work once a month has a different reason to use software than a technician using it throughout the day.

For the customer, a secure web link may be enough. Requiring an installation and another account can add friction to a task that should be brief.

For an internal team using mixed devices, a responsive web application may also be appropriate. A progressive web app can add installation and selected device capabilities, but those capabilities vary across browsers and operating systems. I would verify the specific requirements on target devices rather than assume parity with native software. Source: web.dev, PWA Capabilities.

Native iOS becomes worth testing when frequent use and platform-specific requirements materially affect the job. A demanding capture workflow, specialized hardware, or a managed device fleet may provide that reason.

The fact that the team uses iPhones is useful context. It is not sufficient justification by itself.

Offline work deserves its own prototype

“Works offline” needs a definition.

Can the technician read an assigned job? Create notes? Capture photographs? Change a status? What happens if another employee changes that job before the device reconnects?

I would distinguish data saved locally from data received by the server. The user should be able to tell whether an upload is pending, transferring, or complete. A success message should not conceal unfinished work.

We also need a rule for conflicts. Two new comments might be appended safely. Two incompatible status changes may need review. Repeated retries must not create repeated approvals or duplicate attachments.

Test an upload interrupted halfway through, a device restart with pending work, and a long period without connectivity. Decide how locally stored information is protected and what happens on logout or device loss.

Native tools may help implement the requirements. They do not make the underlying data problems disappear.

If offline capture is the deciding factor, I would prototype that before polishing the dashboard.

The work nobody sees in the mockup still has to be owned

Someone will need to maintain authentication, permissions, integrations, backups, deployment, and monitoring. Credentials will expire. Employees will leave. Providers will change their APIs.

The business should control its important accounts and have usable documentation. A handoff needs to explain deployment, access, recovery, and support responsibilities. I do not want routine operation to depend on remembering which account the developer used months earlier.

An iOS release also brings signing, distribution, platform compatibility, and review considerations where applicable. Apple’s App Review Guidelines should be checked for the actual product and distribution route before promising a launch plan.

A thin native wrapper around a website needs particular scrutiny. The additional release process should buy the user something meaningful, and the proposed distribution needs to be appropriate.

Compare ownership costs, not just quotes

For a useful planning horizon, perhaps two years, I would compare implementation, migration, subscriptions, hosting, support, training, internal administration, and expected changes.

Include the cost of workarounds in the existing process. Include exit costs, too. Can the business export its data or move providers without rebuilding everything?

Use ranges when assumptions are uncertain. User count, data volume, and required support can change the answer substantially. A precise total based on guesses is not more useful than an honest range.

I would also distinguish capacity from cash savings. Giving coordinators time for more jobs can have value without reducing payroll. Enabling a new service can justify investment without fitting a simple time-saved calculation.

The business case should explain which kind of value is expected and how the pilot will test it.

Test the requirement most likely to change our minds

If the uncertainty is an API, test the required operations. If it is offline work, use the actual devices. If it is customer adoption, put the approval task in front of representative customers.

Write pass conditions before the test. A pending upload survives a restart. A repeated request does not duplicate an approval. A customer completes the task without calling the office. Choose conditions that correspond to the original problem.

Then keep the first release focused. One team and one job type can be enough, but include the full path from creation to final handoff. If parts remain manual, name them and assign ownership.

A pilot should give us grounds to proceed, change direction, or stop. If all it can produce is an attractive demonstration, it is not answering the investment question.

The decision should come with the conditions that would reverse it

I would document the decision, the assumptions, and the conditions that would justify revisiting it.

A platform might be right until a specific limitation becomes expensive. A web portal might remain sufficient unless a tested device requirement demands native work. Technicians might need an iOS app while customers continue using a browser.

There is no obligation to force everyone into the same interface.

Bring the workflow, a few representative records, the current systems, and the devices people actually use. That is enough to begin a serious conversation about what deserves to be built, what should stay where it is, and what the business will be taking responsibility for after launch.