Business app development: where it usually goes wrong
An app that keeps customers waiting, that staff quietly work around, or that knows nothing about your existing systems costs you money every working day. Yet almost every app project starts with the same question: what should the screens look like? It is not a stupid question. It is just the wrong one to open with.
The questions that actually matter later rarely come up in that first session. Where does the data come from? Who updates the integration when the ERP gets replaced? What happens when usage doubles? And who answers the phone when nobody can log in on a Monday morning? That is exactly where the difference lies between an app that works on launch day and an app your organisation is still running on three years from now.
Start with the bottleneck, not the feature list
A business app rarely stands on its own. Usually it is an extension of your planning, your stock, your CRM, your customer portal or a way of working that has been in place for years. The engineer wants to close off a job sheet on site. The account manager wants to see what happened with that client yesterday. The customer wants to know where the order is without having to call.
So the most useful opening question is not which features you want, but where you are losing time, oversight or revenue right now. Once that is clear, you also know who the app is for and what belongs in version one.
Take an app for field service. Uploading photos sounds handy. The real gain sits somewhere else: that the photo automatically attaches to the right job, that the back office receives the data without retyping it, and that nobody fills in the same form twice. Without that integration, the app is one more thing to do. With it, the app replaces work.
Keeping that distinction in mind prevents the classic mistake of neatly digitising a messy process. Software makes a process faster, but it does not invent clear ownership and it does not repair data that is half maintained in four places. Sometimes the way of working has to be cleaned up first. That feels like a delay and it is not, because it saves you months of rework later on.
Native, web or cross-platform?
Only once the bottleneck is clear does the technology question get interesting. A native iOS and Android app generally gives the nicest user experience and the best access to camera, push notifications, location and offline storage. That weighs heavily when people are on the road all day, when speed matters, or when the app is opened dozens of times a day.
A web app is often the smarter option when users are sitting behind a browser anyway, when you want to roll out quickly without app store review, or when the functionality stays reasonably contained. For one organisation a responsive customer portal is enough. For another, a combination makes sense: a web environment for the administrators, a mobile app for the people in the field.
Cross-platform can be a good fit too. You share a large part of the code between iOS and Android, which saves development time and, later on, maintenance. It works particularly well for apps built around forms, data and process steps. With heavy graphics, intensive camera use or tight performance requirements the picture changes. So the choice depends on what the app has to do, not on what happens to be fashionable that year.
A good technical partner explains all of this in plain language, downsides included. Anyone who simply steers towards the cheapest route without making that trade-off pays the difference back later in limitations or in a rebuild.
The integrations decide whether it works
Most business apps only become valuable the moment they reliably talk to other systems: ERP, accounting, planning, CRM, payment providers, warehouse software or your own database. That is also where the biggest risk sits.
An app can look flawless on the surface while the data behind it arrives too late or overwrites itself. If stock levels are off, a status lags behind or a job shows up twice, trust is gone within a week. After that people go back to checking things by hand and the time saving has evaporated.
So before you build, map out which data the app reads, changes and sends back, and agree per data type which system leads. The customer name comes from the CRM, the order status from the ERP, documents from the archive. It sounds technical, but it is mostly a business decision: which information has to be correct, and at what moment?
Think the exceptions through as well. What does an engineer do in a basement with no signal? What happens when an external API is down for half an hour? How do you log changes so that three months later you can see who changed what? This is not work for the final week of testing. This decides whether the app holds up on a busy Thursday.
Starting small is not the same as thinking small
A first version does not have to do everything. Too broad a release mainly produces slow decision making, more dependencies and too little attention for the core. Start with the functionality that solves the biggest problem and that people can actually use tomorrow.
Meanwhile the architecture can absolutely take into account what is coming in two years. It just does not all have to be built now. A planning tool can start with viewing jobs, updating statuses and adding photos. Reporting, route optimisation and a detailed permissions model follow once daily use is established.
Involve users during the build, not on handover day. Someone who runs the process every day will spot within five minutes that a button sits in the wrong place or that a term in the app means something different on the shop floor. Those remarks are more concrete than anything dreamt up in a meeting room.
Test with realistic data and under realistic conditions, too. An app that runs smoothly on ten test orders behaves differently with fifty thousand records, a patchy connection or three people editing the same record at once. The sooner you know that, the cheaper it is.
Who do you call when it stops?
Going live is not the end of it. Operating systems get updates, security needs attention, APIs change without asking you first, and users expect an outage to be resolved within the hour. If development, hosting and technical management sit with different suppliers, every incident starts the same game: the host points at the application, the developer points at the infrastructure, and your team waits.
One point of contact is therefore more than convenience. It shortens the road from report to fix. Someone who knows both the code and the server environment sees faster whether a problem sits in a query, in an integration or in capacity.
Do put in writing who does what. Who watches the updates? Who keeps an eye on performance? Who makes the backups and actually tests whether a restore works? How do you report an outage outside office hours and how quickly does someone respond? A contract is the least of it. What matters more is reachable people who do not pass the responsibility on.
At LJPc, development, infrastructure and support sit under one roof. That saves you the referee role between suppliers, and above all it saves time at the moment something goes wrong.
Questions to ask before you sign
A supplier who offers you a standard package before understanding your situation is one you can comfortably walk away from. Ask how the process runs from analysis through to ongoing management, how decisions are recorded, and who you will genuinely have on the line during and after the build.
Look beyond a portfolio of attractive screens as well. Ask about integrations, security, scalability and incidents. Have them explain what happens if an integration drops out, if usage grows faster than planned, or if a new iOS version breaks something. Concrete answers are worth more than a well-phrased promise.
Price counts, obviously, but do not compare quotes on the number of screens or hours. A cheap app without decent maintenance, documentation and reliable hosting is more expensive within two years than an approach that accounts for continuity from day one.
An app does not have to be big, by the way. If it speeds up one handover, eliminates one type of error or saves customers a phone call, the return is already visible. Start with the bottleneck that hurts right now, pick someone who explains technical choices in language you understand, and make sure there is still a name and a number after go-live. Then your app is not a separate project, but a tool you can build on.