Webvelopment
Development

App Development

Define an application around real customer or staff tasks, with role permissions, prototypes, integrations, device requirements and an agreed first release.

Let’s talk

The problem we help solve

Two colleagues working side by side with laptops and notebooks.
Illustrative photography · Christina @ wocintechchat.com M / Unsplash

Perhaps your staff copy requests between a spreadsheet and an inbox, or customers call to find out what happens next. An application can give them a place to submit information, see its status and take the next action.

We start with the task you need to improve, the people allowed to perform it and the information they need. Someone using a phone between visits may need a different experience from a reviewer at a desk. Those needs help us choose the format.

What we can deliver

  • User roles and journey mapping: who starts a task, who makes decisions and who can see the result.
  • An interactive product prototype to try the proposed screens and sequence before implementation.
  • Application architecture and implementation for the agreed first release.
  • API and account integration where the application needs to exchange information with existing systems.
  • Device and release testing against the tasks and devices agreed for the project.

We will agree which outputs your project needs and which records, account access and business decisions your team will supply. A prototype may be the right starting point if the workflow is still unclear.

How we approach the work

We work through the part most likely to change the design first. That might be an approval involving several people, a connection to an existing account system or a task performed with an unreliable connection. We then compare a browser or mobile experience against that use and choose a first release that completes a useful task.

In reviews, users should try familiar tasks: submit a request, correct a mistake, approve it and find the result. Agreeing what those actions should do gives you something concrete to review.

Who this is for

Service businesses, internal operations teams and businesses with repeat customer interactions. This is useful when several people handle the same request, access depends on a person’s role, or users need to check a record for changes.

If you mainly need to explain a service and receive enquiries, a website may cover the need. Bring the task that feels awkward today, and we can discuss whether it calls for an application.

Boundaries to agree early

Store submissions, offline behaviour, device support and ongoing updates must be explicitly scoped. For example, viewing a saved request without a connection is a different requirement from editing it offline and reconciling those changes later. We need to understand which behaviour your users actually need before estimating it.

An app does not create demand on its own. Agree who in your business will manage access and answer operational questions alongside the first release.

Questions before we start

A few useful answers before you decide.

Should this be a mobile app?
Not always. A responsive web application may solve the task with simpler distribution. We compare how people reach the application, which devices they use and whether they need offline access or particular device functions.
What do you need from us?
Describe one user role and one complete task, including where it happens and what device is used. A blank form, a redacted example record or a walkthrough of the current steps can help. Include what happens when information is missing or someone makes a mistake. We can then discuss a prototype or scoped application release.

Shape a release around a complete task

Imagine a proposed staff application for requesting and approving a service visit. A requester enters the location and requirement; a reviewer can accept, decline or ask a question; the responsible team can see what action follows. This is a planning example, not a description of a delivered client system.

The requester needs to see whether the visit is approved, and the responsible team needs enough detail to act. Decide which statuses exist, who can change them and when a notification is needed.

Consider a corrected location, an absent reviewer or an unfinished request. Should the correction reopen approval? Can another reviewer take over? Can the requester return to a draft? These exceptions reveal requirements a list of screens can hide.

Identify the constraints people will experience

Tell us where the application is used, which devices matter and which systems it must depend on. Describe connection interruptions if they are part of the working environment. If a task is usually done on a shared device, say so: access and signing out need to fit that situation.

For each integration, identify what information must move and in which direction. For example, an application might read a customer number from another tool but keep visit notes in its own records. We need to know which system people should update when a detail is wrong. Bring someone who can confirm those rules and review the information each role may see.

Make the first release complete for one user role

  • Describe what the person starts with, the action they take and the confirmation they receive.
  • Include loss of connectivity, incomplete information and permission errors in the acceptance examples.
  • Separate a clickable prototype from working authentication, data storage and release implementation.

Start with one role, then include any other role needed to finish its task. A requester cannot complete an approval workflow if the reviewer has no way to respond. Optional reporting or additional request types can wait if they are not needed for that first complete flow.

Further application planning questions

A few useful answers before you decide.

How do we decide between a browser application and another format?
Walk through a typical use: how does the person open the application, where are they, what device do they have and what happens if the connection drops? Then consider distribution, maintenance and any essential device functions. We compare formats against those requirements.
What belongs in the first backlog?
Include the steps required to complete the task and the exceptions that would stop it working in normal use. For the service-visit example, that could include submitting, reviewing, correcting and checking a request. Each item needs a clear expected result and someone who can answer business questions about it. Keep later ideas visible so you can decide when to add them.
Who should review permissions?
Someone responsible for the business information should confirm which roles can view, create, change and approve records. Representative users can explain how those rules affect daily work. A job title may not tell us whether a person should see all requests or only their own team’s. Reviews should include attempts that ought to be refused, as well as actions that ought to succeed.
How can a prototype reduce uncertainty?
A prototype lets people try the proposed sequence and language before full implementation. Ask a reviewer to find a request and explain what they would do next; ask a requester to correct a detail. Missing information and confusing decisions are easier to discuss when people can point to a screen. A clickable prototype does not establish how production security, performance or integrations will behave; those need their own implementation and testing.
What if information must be imported from another tool?
Bring a representative export with sensitive information removed, if possible, and identify who understands the records. We need to check field meanings, duplicate records and how old records will match accounts in the application. Agree what happens to information that cannot be mapped or is incomplete. Include those checks and any necessary cleanup in the migration scope.
How should changes be handled during development?
Explain the behaviour you need and why. We can then distinguish a correction to agreed work from an additional feature, and discuss the effect on cost and the release. A new request may justify changing priorities. Keep the agreed release and later ideas visible so everyone knows what is being built.
What happens after the application launches?
Agree who adds and removes users, receives problem reports and approves future releases. Handover should explain account ownership, the responsibilities for running the application and the maintenance arrangement. Explain where users can ask for help or report broken behaviour. Ongoing support coverage is specified separately, including any response hours; development does not imply continuous support across every timezone.

Prepare your next conversation

Bring one user role and one task from start to finish: what the person starts with, where they get stuck and how they know it is complete. Include their device and any system the application must work with. We can use that to discuss a prototype or scoped release.

Clarify the application journey · Resolve platform and integration uncertainty

Discuss this app development brief.

Assessment mystery shopping platforms · 06 mobile app.

Plan the scope and estimate

Mobile App / PWA Estimator. These tools separate known labour from work and supplier costs that need a custom quote.

Keep exploring

Keep the right things connected.

Our expertise

Bespoke Development

Plan business software around the work people need to do: choose an application, eCommerce change, PHP update or integration, with a clear first release.

How we work

Clear decisions. Reviewable progress.

How Webvelopment scopes, designs, builds and hands over digital work with clear ownership at every stage.

Let’s move things forward

Start a conversation

Tell us what you are working towards. We’ll help you find a practical next step.

Let’s talk