Does your business need a Flutter app or a mobile website?

If most customers find you through Google, read a page and request a quote, start with a mobile website. A Flutter app becomes worth considering when people return to the same task often enough that having it on their phone saves time. The question I’d ask first is simple: what will somebody open this app to do for the tenth time?

When a link is all the customer needs

Think of someone in Southsea who hears about a gig tonight. They want the venue, the start time and a link they can send to a friend. Asking them to visit an app store before they can see those details puts another step between them and the event.

That was a good use case for the web on our Going Out Out events finder. We built the Portsmouth project in Laravel for people using their phones, with progressive web app features. A progressive web app is a website that can offer app-like features in supported browsers. It’s an option worth exploring when you want public pages people can share alongside features for regular users.

The same thinking applies to a restaurant menu, a training course or a first booking. A booking form can ask for a date, take an enquiry and send a confirmation through a website. Start there if customers only need it occasionally.

A booking business can have two different answers

Consider a chauffeur company. A passenger arriving at Southampton Airport needs to check the service area, request a pickup and send the details to a colleague. A booking link works for a first-time visitor, including one using somebody else’s phone. Requiring an installation before showing a price risks losing the enquiry at the exact moment the customer is ready to book.

The drivers have a different job. They may open the schedule several times a shift, receive a revised pickup time and confirm that a passenger is on board. That can justify an app even when the passenger side works perfectly well on the web. Both can use the same booking system. You can commission a customer website first and add the driver app when the office understands which updates would save the most calls.

This is often where an app quote becomes unnecessarily expensive. The brief asks for “an app for our business”, so every feature gets designed twice, once for staff and once for customers. Split those audiences before getting prices. You might need an app for ten employees and a public booking page for everyone else.

When a place on the phone earns its keep

Now picture a driver who starts each shift by checking their jobs, records a vehicle check and returns to the same screen at each collection. Staying signed in and getting straight back to the current job could save time several times a day. The business can train the people using it and see whether it improves the round.

Our work with Southern Electrical Recycling is an example of software built around a recurring job. You can read how the WEEE Manager project began. For a new driver app, we’d want to understand exactly what happens when a collection takes place without a signal. Does the driver need to see the job, enter a weight, capture a signature or do all three? Each answer changes the build.

Be precise about the phone features you need

“Uses the camera” isn’t quite enough to decide between the two. A customer can often attach a picture to a web form using a phone. A surveyor who takes twenty photographs, labels each one against a room and works throughout a building with poor reception has a more demanding requirement. Write down whether the pictures need to be stored on the phone, when the office should see them and what the surveyor sees if an upload fails.

Apply the same test to location. Showing nearby events when someone opens a map is one requirement. Sharing a driver’s location during an active journey with the screen locked is another. Ask the developer to demonstrate the precise behaviour on the phones you intend to support, including what happens when the user declines a permission. Agree who can see the location and when collection stops. That discussion affects what gets built, tested and supported.

What Flutter changes about the quote

Flutter lets us share much of the code for iOS and Android. The quote still needs to cover device testing, permissions, releases and support after launch. Offline working also needs to be designed explicitly. If a driver saves a change offline and the office edits the same job, someone has to decide which change wins when the phone reconnects.

If the first users are employees with company-issued Android phones, tell the developer. Testing that workflow on the actual handsets could be more valuable than funding an iPhone release on day one. If customers use both platforms, allow for both from the start.

What to budget for after the first release

Ask for separate figures for the mobile app, the system behind it and ongoing support. A customer may only see a few screens, while the office needs a dashboard, permissions, a record of changes and a way to correct mistakes. If you already have a booking system, somebody still has to check whether it can exchange the right information with the app and what the provider charges for that access.

Then agree who owns the store accounts, who supplies the listings and screenshots and who handles releases when phone software changes. Hosting, mapping, email and file storage can each have ongoing costs. Ask which bills you pay directly and what usage would make them increase. For a field team uploading photographs, the number and size of the files might matter far more than the number of staff accounts.

A small pilot can help put numbers on the decision. As an illustration, say twelve employees each save five minutes a day, on twenty working days a month. That is twenty staff hours a month. At an assumed £20 per hour that is £400 of time. It only becomes a cash saving if you reduce paid hours or use that capacity for other valuable work. Compare that monthly benefit with the build and support costs, then repeat the calculation using what the pilot actually measured.

A quick way to decide

Try finishing this sentence. “Every [day, week or month], this person opens the app to do this job.” Then describe how they do it today and where time gets lost. If the answer is “they look up our phone number once”, a good contact page is enough. If it’s “they retype every collection ticket back at the depot”, you’ve got a job worth costing.

How to commission a first version you can test

Pick one complete task. For the driver, that might be receiving a job, recording a collection and getting the result back to the office. Build in a test where the signal drops after the driver presses Save, and they press it again. The test is whether the office receives one completed job and the driver can see that it arrived. A polished dashboard won’t answer that question.

Use the phones people actually carry. A demonstration on a developer’s newest handset may miss a small-screen layout problem or a problem with an older work phone. Put the pilot in front of a few real users and ask them to do a normal job with minimal prompting. Where do they fall back to a phone call or a paper note? Those are better candidates for the next release than a long list of features nobody has tried.

If the evidence points to a website, agree what would trigger a second look at an app. Perhaps customers start making repeat bookings every week, or the team begins visiting sites without reliable reception. Keeping a record of those changes gives you a sensible point to revisit the decision. You can invest in the public website now and leave a credible route to an app later.

Creation Web offers Flutter app development for iOS and Android. A sample job sheet or a short description of the current process is plenty for a first conversation.